Skip site navigation (1)Skip section navigation (2)
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>