From owner-freebsd-bugs Mon Dec 23 12:10:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA20130 for bugs-outgoing; Mon, 23 Dec 1996 12:10:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA20123; Mon, 23 Dec 1996 12:10:01 -0800 (PST) Date: Mon, 23 Dec 1996 12:10:01 -0800 (PST) Message-Id: <199612232010.MAA20123@freefall.freebsd.org> To: freebsd-bugs Cc: From: George Simunovich Subject: Re: kern/2270: Hayes ESP serial card locks system as of 12/01 ke Reply-To: George Simunovich 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: George Simunovich To: Bruce Evans 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