system command hangs (unkillable); ps shows 'sbwait' state?

[Rob]

Robert Watson wrote:
> On Wed, 19 May 2004, Rob wrote:
> 
> 
>>1. I had a 2.5 Gb disk mounted on /home/software.
>>    As root, I overloaded the filesystem, with negative percentage left
>>    on the device (from df command). So as root, I did a 'rm -rf' in
>>    /home/software, followed by a 'df -h'. But the df command gave no
>>    response and became unkillable by any means (ctrl-C, kill -9 <pid>).
>>    Using 'ps', I found the df command in the 'sbwait' state.
>>
>>2. I had a usb device mounted as /dev/da0s1 on /mnt. Mounting (as root)
>>    went all well, but when I unmounted it, as root, the umount command
>>    hanged, again the umount command was in sbwait state.
>>    In this case it was even worse: when I killed the xterminal
>>    where the umount command was hanging, the whole system froze.
>>    Only power off/on helped me out here.
>>
>>I don't know what happened; don't know how to further investigate this. 
>>Has somebody else similar experiences? Is stability going down for
>>Stable kernel? 
> 
> 
> Could you take a look at the instructions in the Handbook on setting up
> for kernel debugging, compile the kernel with DDB, and generate stack
> traces for the hung processes + the output of "show lockedvnodes"?  Also,
> if you can get a core dump, it might be interesting to see the output of
> netstat -mb on the core.  Finally, are you using any features like NIS or
> NFS?  Having umount stuck in sbwait sounds like a fairly unusual failure
> mode unless you're using NFS.

Thanks. Indeed, stability of Stable is still OK.

For 1) above, that happened on an NFS server. So you could have
a point here, though the 'overloaded' filesystem was not NFS-mounted,
but local. Is NFS known to cause problems of this kind?

For 2), there seem to be a problem with USB, if there's a VIA
chipset on the motherboard. I have received one more confirmation of
the same problem with the same hardware. No other response on this
issue from the list though.

Regards,
Rob.