From owner-freebsd-bugs  Fri Jan  3 01:00:04 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id BAA08252
          for bugs-outgoing; Fri, 3 Jan 1997 01:00:04 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id BAA08241;
          Fri, 3 Jan 1997 01:00:02 -0800 (PST)
Date: Fri, 3 Jan 1997 01:00:02 -0800 (PST)
Message-Id: <199701030900.BAA08241@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bruce Evans <bde@zeta.org.au>
Subject: Re: kern/2270: Hayes ESP serial card locks system as of 12/01 ke
Reply-To: Bruce Evans <bde@zeta.org.au>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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,