Date: Fri, 3 Jan 1997 13:40:02 -0800 (PST) From: George Simunovich <george@cia-g.com> To: freebsd-bugs Subject: Re: kern/2270: Hayes ESP serial card locks system as of 12/01 ke Message-ID: <199701032140.NAA16005@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/2270; it has been noted by GNATS. From: George Simunovich <george@cia-g.com> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/2270: Hayes ESP serial card locks system as of 12/01 ke Date: Fri, 03 Jan 1997 13:55:11 -0700 (MST) On 04-Jan-97 Bruce Evans wrote: >DDB distorts the enviroment an many ways. There is the obvious >unavoidable problem that it changes the timing. Less obviously, DDB >doesn't mask interrupts unless they are already masked, so an sio >interrupt may occur and happen to clean things up while you're >stoipped at the breakpoint at siostop. Try putting a breakpoint a >little later, after the "cli" instruction, and single stepping until >the "sti" instruction (use "x/ia" to display instructions and "s" >to single step). If this prevents the lockup, then the lockup is >almost certain to be caused by timing problems. I set the breakpoint at siostop+0x22: testb $0x2,%bl, which is immediately after the cli instruction. I then stepped through it until the sti instruction the three times it hit the breakpoint after a close. No look ups with that breakpoint either. After delete the breakpoint the look ups continued. >Try adding this to all the outb's to com->fifo. According to the docs, >it is necessary to prevent excessive input interrupts that would reduce >input efficiency to that of a 16450 (i.e., about 1/4 as efficient as an >ordinary 16550). The easiest way to tell if there are too many interrupts >iis to look at the sio interrupt count displayed by `systat -vmstat' while >input is arriving at a constant rate. I watched the "systat -vmstat" display while ftping a file from a computer on the other side of a user-mode ppp modem link. While using sio2 it showed around 3800 interrupts. While using sio1 it showed around 300. Both transfer times, as reported by ftp, where around 3.66 Kbytes/s. I then added the FIFO_DMA_MODE bit to each outb( iobase+com_fifo,...). I then did the same ftp and watched "systat -vmstat". The interrupts went down to around 100. On the other hand the transfer speed went down to 3.15 Kbytes/s. I also got an syslog error message while using "cu -l /dev/cuaa2" with the modified sio.c kernel, "sio2: 264 more interrupt-level buffer overflows (total 264)". I had to use 2400 baud, "cu -l /dev/cuaa2 -s 2400" to get rid of the error messages. I also added the FIFO_DMA_MODE bit to a version of sio.c that used the FIFO-reset outb() in siostop (original RELENG_2_2 version). No change to the lockup problem. Why would the transfer rate decrease while the number of interrupts decrease? Is it because of the buffer overflows? Why would I then only get the error messages while using cu? >I'll commit a change something like the following if we can't find a >proper fix. > >Bruce I'm wondering how hard it would be to work the ESP enhanced mode, instead of the compatibility mode, into the sio driver? Are we talking about a new driver to do this? I've been thinking about trying it, but I don't know too much about the details of architecture of the "PC" or kernel drivers. George ------------------------------------ George Simunovich <george@cia-g.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701032140.NAA16005>