Message-ID: <421A3414.2020508@nodivisions.com>
Date: Mon, 21 Feb 2005 14:18:44 -0500
From: Anthony DiSante <theant@nodivisions.com>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
MIME-Version: 1.0
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: uninterruptible sleep lockups
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1625
Lines: 33

Processes that get permanently stuck in "uninterruptible sleep" (the D state 
as indicated by "ps aux") are such a pain.  Of course they've always 
existed, but at least on the 3 systems that I administer, they are far more 
frequent with udev than they ever were before.  I'm constantly upgrading 
udev, hal, etc on these 3 different systems, but still not a week goes by 
that one of them doesn't need a reboot because some hardware-related process 
is hung.

The most recent one was yesterday: I had run lsusb in the morning and had no 
problems, but at the end of the day I ran it again, and after outputting 3 
lines of data, it hung, stuck in D-state.  So now I have this:

[/home/user]$ ps aux|grep D
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root        92  0.0  0.0     0    0 ?        D    Feb19   0:00 [khubd]
root       845  0.0  0.0     0    0 ?        D    Feb19   0:00 [knodemgrd_0]
root     29016  0.0  0.1  1512  592 ?        D    00:28   0:00 lsusb

It seems like this problem is always going to exist, because some hardware 
and some drivers will always be buggy.  So shouldn't we have some sort of 
watchdog higher up in the kernel, that watches for hung processes like this 
and kills them?

Don't get me wrong, I love rebooting every couple days... but I have a 
Windows system for that.

-Anthony DiSante
http://nodivisions.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/