Date: Mon, 22 May 2006 20:11:24 -0400 From: Miles Nordin <carton@Ivy.NET> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/97665: hang in sio driver Message-ID: <oqejyl8us3.fsf@castrovalva.Ivy.NET> Resent-Message-ID: <200605230020.k4N0K9Ga088187@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 97665 >Category: kern >Synopsis: hang in sio driver >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 23 00:20:09 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Miles Nordin >Release: FreeBSD 6.0-RELEASE i386 >Organization: Ivy Ministries >Environment: System: FreeBSD pizarro 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Tue Nov 8 20:23:54 UTC 2005 carton@cortez:/usr/src/sys/i386/compile/CORTEZ i386 >Description: >How-To-Repeat: freebsd's serial driver seems to hang up a lot. processes get stuck in uninterruptible sleep (don't respond to 'kill -9'), and i can release them by, say, power-cycling a modem. try this: first, get a serial device that holds CTS low. # stty crtscts < /dev/ttyd0.lock # stty crtscts < /dev/ttyd0.init # cu -l ttyd0 -s 9600 Connected. asdfasd;ljk;bouns;douahf ~. [EOT] ^T load: 0.00 cmd: cu 42104 [ttywai] 0.00u 0.03s 0% 752k now, open another window, and try 'kill -9 42104'. doesn't work. now for real fun try this: # ls -l /dev/cuad0 provided you type that command for the first time while the serial port is hung, you will hang devfs which will pretty soon hang the whole goddamned machine. once cuad0 node is instantiated, that vulnerability no longer exists. after some very long timeout on the order of minutes, the system may recover itself. Fix: IMHO, a process should always respond to 'kill -9' no matter _what_ SIO is doing, waiting for carrier, with data in the output buffer waiting for CTS to assert itself, whatever, period. I shouldn't have the process table cluttered with anything that can be removed only by changing the logic state of some serial port pin. serial is not a SCSI port---it's highly public. definitely sio activity should not be able to hang devfs. >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?oqejyl8us3.fsf>