Date: Fri, 3 Jan 1997 01:00:02 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs Subject: Re: kern/2270: Hayes ESP serial card locks system as of 12/01 ke Message-ID: <199701030900.BAA08241@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: Bruce Evans <bde@zeta.org.au>
To: bde@zeta.org.au, george@cia-g.com
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: kern/2270: Hayes ESP serial card locks system as of 12/01 ke
Date: Fri, 3 Jan 1997 19:48:32 +1100
>Ok, here is new "development". I recompiled a kernel, without any changes
>to the code, and included the kernel debugger, "DDB". I then booted the
>new kernel with the switches "-sd". I think I'll show you what I did...
>
>db>break siostop
>db>c
><kernel boots, probes, etc. Then in single user mode>
>#cat > /dev/cuaa2
>^D
><debugger breaks at siostop>
>db>c
><debugger again breaks at siostop>
>db>c
><debugger breaks at siostop a third time>
>db>c
>
>It doesn't lock up. I can do this over and over again without any
>problems. Unfortunatly, going back into the debugger and deleteing
>the breakpoint at siostop and trying the cat again, it completely
>locks up again.
>
>I'm very confused.
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.
>While looking through the ESP information I found at ftp.hayes.com I found
>this:
I fetched it too. It doesn't seem to say anything about resetting
the UART's fifos.
>The note for Step 4 is interresting and explains setting the DMA bit for the
>magic outb???
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.
>Back to my random changes to sio.c....
I'll commit a change something like the following if we can't find a
proper fix.
Bruce
diff -c2 sio.c~ sio.c
*** sio.c~ Tue Dec 24 20:44:53 1996
--- sio.c Fri Jan 3 19:20:22 1997
***************
*** 2129,2132 ****
--- 2169,2176 ----
if (rw & FWRITE) {
if (com->hasfifo)
+ #ifdef COM_ESP
+ /* XXX the outb causes ESPs to hang for some reason. */
+ if (!com->esp)
+ #endif
/* XXX does this flush everything? */
outb(com->iobase + com_fifo,
***************
*** 2141,2144 ****
--- 2185,2191 ----
if (rw & FREAD) {
if (com->hasfifo)
+ #ifdef COM_ESP
+ if (!com->esp)
+ #endif
/* XXX does this flush everything? */
outb(com->iobase + com_fifo,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701030900.BAA08241>