From nobody  Sun Dec 22 21:26:26 1996
Received: (from nobody@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id VAA17402;
          Sun, 22 Dec 1996 21:26:26 -0800 (PST)
Message-Id: <199612230526.VAA17402@freefall.freebsd.org>
Date: Sun, 22 Dec 1996 21:26:26 -0800 (PST)
From: george@cia-g.com
To: freebsd-gnats-submit@freebsd.org
Subject: Hayes ESP serial card locks system as of 12/01 kernel. 
X-Send-Pr-Version: www-1.0

>Number:         2270
>Category:       kern
>Synopsis:       Hayes ESP serial card locks system as of 12/01 kernel.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Dec 22 21:30:02 PST 1996
>Closed-Date:    Sun Feb 25 04:10:57 PST 2001
>Last-Modified:  Sun Feb 25 04:11:29 PST 2001
>Originator:     George Simunovich
>Release:        2.2 Release Branch
>Organization:
>Environment:
FreeBSD 3.0-CURRENT (<-as of right now.  I don't think I'm getting
the versions of the files I'm trying to with cvs after this problem
showed up.)
>Description:
Accessing the serial port device for the Hayes ESP card, /dev/cuaa2,
the system completely locks up and forced to reset.
>How-To-Repeat:
When the line "modem d a 2" in rc.serial is run at start up, the
system locks up tight.  Commenting out that line and after the
system completly boots, running "cu -l /dev/cuaa2" also causes the
system to completly lock up.

This is happening with all the kernels I've compiled using the
kernel sources after and including 12/01, "cvs update -D 12/01/1996".
The kernel of 11/30 apparently works fine.

I noticed a lot of changes to the file "i386/isa/sio.c" dated
11/30, "cvs log sio.c".
>Fix:
Fix unknown, running kernel from sources as of date 11/30.
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: freebsd-gnats-submit@freebsd.org, george@cia-g.com
Cc:  Subject: Re: kern/2270: Hayes ESP serial card locks system as of 12/01 kernel.
Date: Mon, 23 Dec 1996 22:43:24 +1100

 >>Description:
 >Accessing the serial port device for the Hayes ESP card, /dev/cuaa2,
 >the system completely locks up and forced to reset.
 >>How-To-Repeat:
 >When the line "modem d a 2" in rc.serial is run at start up, the
 >system locks up tight.  Commenting out that line and after the
 >system completly boots, running "cu -l /dev/cuaa2" also causes the
 >system to completly lock up.
 
 Someone else reported that there is a problem with the ESP only(?)
 when the port is closed.
 
 >This is happening with all the kernels I've compiled using the
 >kernel sources after and including 12/01, "cvs update -D 12/01/1996".
 >The kernel of 11/30 apparently works fine.
 
 The sio driver now assumes that the Transmitter Holding Register
 Empty (THRE) bit works normally in more cases.  If it doesn't work,
 then sioclose() might hang if there is output in progress.  The system
 shouldn't hang, but if the hang is during early execution of rc.serial,
 then it would be hard to tell the difference.  Try setting a timeout of
 N seconds using `comcontrol /dev/cuaa2 drainwait N' very early (before
 anything else in rc.serial).  I'm not sure if this is the problem -
 /etc/rc.serial shouldn't generate any output.  If it is, then THRE
 might fail because the UART is doing flow control that the driver
 doesn't know about.
 
 Bruce

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: Mon, 23 Dec 1996 12:46:21 -0700 (MST)

 On 24-Dec-96 Bruce Evans wrote:
 >>>>Description:
 >>Accessing the serial port device for the Hayes ESP card, /dev/cuaa2,
 >>the system completely locks up and forced to reset.
 >>>How-To-Repeat:
 >>When the line "modem d a 2" in rc.serial is run at start up, the
 >>system locks up tight.  Commenting out that line and after the
 >>system completly boots, running "cu -l /dev/cuaa2" also causes the
 >>system to completly lock up.
 >
 >Someone else reported that there is a problem with the ESP only(?)
 >when the port is closed.
 >
 
 I tried a couple things and it seems both on the open or the close
 everything locks up.  I booted single-user and ran "cu -l /dev/cuaa2".
 I was able to dial and connect but when I disconnected it locked up.
 I also removed everything accessing /dev/cuaa2 from the start up
 files and booted.  Running "cu -l /dev/cuaa2" immediately locked
 everything up.
 
 >>This is happening with all the kernels I've compiled using the
 >>kernel sources after and including 12/01, "cvs update -D 12/01/1996".
 >>The kernel of 11/30 apparently works fine.
 >
 >The sio driver now assumes that the Transmitter Holding Register
 >Empty (THRE) bit works normally in more cases.  If it doesn't work,
 >then sioclose() might hang if there is output in progress.  The system
 >shouldn't hang, but if the hang is during early execution of rc.serial,
 >then it would be hard to tell the difference.  Try setting a timeout of
 >N seconds using `comcontrol /dev/cuaa2 drainwait N' very early (before
 >anything else in rc.serial).  I'm not sure if this is the problem -
 >/etc/rc.serial shouldn't generate any output.  If it is, then THRE
 >might fail because the UART is doing flow control that the driver
 >doesn't know about.
 
 comcontrol seems to have no effect on the problem.  This is a total
 locking up.  I've had a find / running in the background and when
 it hangs the disk goes completly silent.  I also cann't switch
 virtual ttys or move the mouse.  I also don't have any of the
 debugging options set for the kernel.
 
 BTW, how do you get cvs to get files for a branch and a date?
 "cvs checkout -r RELENG_2_2 -D11/30/1996" gives a usage message.
 "cvs update -r RELENG_2_2 -D11/30/1996" runs but apparently
 gives the HEAD files.
 
 >
 >Bruce
 
 Thanks,
 
 George
 
 ------------------------------------
 George Simunovich <george@cia-g.com>

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: Tue, 24 Dec 1996 21:56:32 +1100

 >BTW, how do you get cvs to get files for a branch and a date?
 >"cvs checkout -r RELENG_2_2 -D11/30/1996" gives a usage message.
 >"cvs update -r RELENG_2_2 -D11/30/1996" runs but apparently
 >gives the HEAD files.
 
 -D is almost unusable with branches (I think there's a hack involving
 -j but I can't remember it).
 
 For single files it's easy enough to check out specific revisions (read
 the cvs log to find the revision numbers), and in this case it's easiest
 to work with the -current version (-current sio.c is identical with -2.2
 sio.c and the changes on 11/30/1996 aren't all together).
 
 Bruce

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: Thu, 26 Dec 1996 21:47:11 -0700 (MST)

 On 25-Dec-96 Bruce Evans wrote:
 >For single files it's easy enough to check out specific revisions (read
 >the cvs log to find the revision numbers), and in this case it's easiest
 >to work with the -current version (-current sio.c is identical with -2.2
 >sio.c and the changes on 11/30/1996 aren't all together).
 >
 >Bruce
 
 I stepped through the sio.c versions from 11/30/1996.  1.152 works,
 1.153 doesn't.  The diff between the these two versions looks simple
 enough.  The logs says "Reset h/w fifos (if any) in siostop(). ...".
 What does this mean with respect to the Hayes ESP?  Is there a
 different way to do this for the ESP?
 
 I've checked out the RELENG_2_2 tagged versions of sio.c and #ifndef
 COM_ESP the two blocks of code that 1.153 added.  The ESP card
 seems to be working fine.
 
 So now what?
 
 George
 
 ------------------------------------
 George Simunovich <george@cia-g.com>

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: Sat, 28 Dec 1996 06:16:42 +1100

 >I stepped through the sio.c versions from 11/30/1996.  1.152 works,
 >1.153 doesn't.  The diff between the these two versions looks simple
 >enough.  The logs says "Reset h/w fifos (if any) in siostop(). ...".
 >What does this mean with respect to the Hayes ESP?  Is there a
 >different way to do this for the ESP?
 
 Good work.
 
 Look at the magic outb for the ESP case near line 902.  This sets the
 FIFO_RCV_RST and FIFO_XMT_RST bits in combination with the FIFO_DMA_MODE
 bit.  I don't know what this does (I don't have any documentation about
 the ESP).  The author of the ESP changes said that the DMA bit doesn't
 have anything to do with DMA.  Apparently the reset bits aren't for reset
 either.
 
 Bruce

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, 27 Dec 1996 21:54:20 -0700 (MST)

 On 28-Dec-96 Bruce Evans wrote:
 >Look at the magic outb for the ESP case near line 902.  This sets the
 >FIFO_RCV_RST and FIFO_XMT_RST bits in combination with the FIFO_DMA_MODE
 >bit.  I don't know what this does (I don't have any documentation about
 >the ESP).  The author of the ESP changes said that the DMA bit doesn't
 >have anything to do with DMA.  Apparently the reset bits aren't for reset
 >either.
 >
 >Bruce
 
 I have found some ESP docs at ftp://ftp.hayes.com/esp/esi.{doc,txt}. A
 choice of MS-WORD or badly formatted ascii.
 
 I glanced through it and noticed a lot of programming information.
 
 George
 
 ------------------------------------
 George Simunovich <george@cia-g.com>

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: Tue, 31 Dec 1996 11:58:07 -0700 (MST)

 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.
 
 
 On 28-Dec-96 Bruce Evans wrote:
 >Look at the magic outb for the ESP case near line 902.  This sets the
 >FIFO_RCV_RST and FIFO_XMT_RST bits in combination with the FIFO_DMA_MODE
 >bit.  I don't know what this does (I don't have any documentation about
 >the ESP).  The author of the ESP changes said that the DMA bit doesn't
 >have anything to do with DMA.  Apparently the reset bits aren't for reset
 >either.
 
 While looking through the ESP information I found at ftp.hayes.com I found
 this:
 
 Operating in UART Compatibility Mode at 115,200 or 230,400 Bit/s
 ------------------------------------------------------------
 To operate in UART Compatibility Mode at 115,200 or 230,400 bit/s, follow these 
 steps:
 
 Step 1: Determine if any of the COM1 through COM4 ports is an ESP Communications
  Accelerator Version 2.0 port. This can be done by searching through the valid M
 aster/Slave I/O addresses as follows:
 
   * Read the Base I/O address and look for the signature
     0F3h. If the value is found, issue the Get Self Test
     Results (01h) command and mask off all bits except for 
     bits 4, 5, and 6 (the hardware type bits). The first 
     version of the COM-bic chip will have a value of 010. 
 
   * Issue the Get Compatibility Mode DIP Switch (02h)
     command. Bits 0 and 1 to identify the COM designation.
 
 Step 2: Repeat the above steps for all master I/O addresses and any slaves that 
 are associated with a found master. 
 
 Step 3: Do the 'normal' 16550 initialization.
 
 Step 4: Enable the FIFOs at the UART FIFO Control Register, FCR, bit 0. 
 
 Note: Due to a problem with the receive trigger level enable in UART mode the DM
 A mode select bit (bit 3) should also be set when enabling the FIFO's.
 
 Step 5: Scale the UART trigger levels using the Set Mode (10h) command CMD2, bit
  7. You can significantly reduce the number of interrupts by scaling the trigger
  levels to 1, 64, 256, and 512 bytes. While issuing the Set Mode command, CMD2 b
 it 1 should be set to ensure that the Compatibility Mode UART FIFOs are enabled.
 
 Step 6: Issue the Set Flow Control Type (08h) command for the type of flow contr
 ol desired.
 
 Step 7: Issue the Set Rx Flow Control (0Ah) command to set the flow control leve
 ls.
 
 Step 8: For Hardware Flow Control, set the appropriate bits (0 and 1) in the UAR
 T Modem Control Register (MCR) to turn on RTS and DTR.
 
 Step 9: Set the bit/s rate. If 230,400 bit/s is desired, set the bit/s to 115,20
 0 and issue the Set UART Clock ESI Prescaler (23h) command with a value of 01.
 
 Step 10: The interrupt service routine should probably be altered to take advant
 age of transmit and receive buffers that are 1KB each.
 
 Note: For software flow control, there are two ESI commands available that flow 
 on and off the local transmitter.
 
 
 The note for Step 4 is interresting and explains setting the DMA bit for the
 magic outb???
 
 Back to my random changes to sio.c....
 
 George
 
 
 ------------------------------------
 George Simunovich <george@cia-g.com>

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,

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>
State-Changed-From-To: open->closed 
State-Changed-By: mpp 
State-Changed-When: Sun Feb 23 10:19:18 PST 1997 
State-Changed-Why:  
Duplicate of PR# 2270. 
State-Changed-From-To: closed->open 
State-Changed-By: mpp 
State-Changed-When: Sun Feb 23 10:20:12 PST 1997 
State-Changed-Why:  
Oops, PR# 2611 is a duplicate of this one and I closed this 
one by mistake. 
State-Changed-From-To: open->closed 
State-Changed-By: steve 
State-Changed-When: Sun May 31 12:15:34 PDT 1998 
State-Changed-Why:  
My mail ping was greeted with a "who are you?", so I think 
it's safe to assume that either this problem has been fixed 
or the originator no longer uses FreeBSD. :) 
State-Changed-From-To: closed->open 
State-Changed-By: steve 
State-Changed-When: Sun May 31 19:40:54 PDT 1998 
State-Changed-Why:  
I messed up and closed this one before its time as pointed 
out by Bruce. :( 
State-Changed-From-To: open->feedback 
State-Changed-By: johan 
State-Changed-When: Wed Aug 16 11:32:18 PDT 2000 
State-Changed-Why:  
Is there still this problem with the sio driver for the ESP card 
in more recent releases of FreeBSD? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=2270 
State-Changed-From-To: feedback->closed 
State-Changed-By: johan 
State-Changed-When: Sun Feb 25 04:10:57 PST 2001 
State-Changed-Why:  
Feedback timed-out. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=2270 
>Unformatted:
