freebsd stable - Jan 2006 - RELENG_6 devfs problem

Hi,
I just installed the latest mgetty and ran it, then found it wasn't talking
to
my modem so I disabled it in /etc/ttys and killed the process.

I ran fstat /dev/cuad0 to check it was dead and fstat got stuck in the devfs 
state. It seems that everything else was stuck too and now the machine is 
alive but not very functional.

What can I do to try and debug it?

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060105/3561f770/attachment.bin

On Thu, 5 Jan 2006, Daniel O'Connor wrote:
> I just installed the latest mgetty and ran it, then found it wasn't
talking
> to my modem so I disabled it in /etc/ttys and killed the process.
>
> I ran fstat /dev/cuad0 to check it was dead and fstat got stuck in the
devfs
> state. It seems that everything else was stuck too and now the machine is 
> alive but not very functional.
>
> What can I do to try and debug it?
Do you use devfs rule sets?  I fixed a bug a week or so ago in devfs_rule.c in 
HEAD, and MFC'd the fix today.  The symptoms are much what you describe, and
occur when an invalid rule is proposed -- the right error is returned, but a 
lock is not released resulting in it being unavailable when processes try to 
access device nodes, resulting in eventual deadlock.  It's devfs_rule.c:1.21
in HEAD, and devfs_rule.c:1.14.2.3 in RELENG_6.  I belive the bug does not 
exist in RELENG_5, as there were significant changes in devfs locking for 6.0, 
and those haven't been merged to RELENG_5.

If this doesn't fix it, the normal debugging steps apply -- compile in DDB, 
BREAK_TO_DEBUGGER, and WITNESS.  When the wedge occurs, dump the lock state 
(show alllocks), and we'll see if we can track down the problem.

Robert N M Watson