lkml.org 
[lkml]   [2005]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: uninterruptible sleep lockups
Valdis.Kletnieks@vt.edu wrote:
> See the thread rooted here:
>
> Date: Wed, 03 Nov 2004 07:51:39 -0500
> From: Gene Heskett <gene.heskett@verizon.net>
> Subject: is killing zombies possible w/o a reboot?
> Sender: linux-kernel-owner@vger.kernel.org
> To: linux-kernel@vger.kernel.org
> Reply-to: gene.heskett@verizon.net
> Message-id: <200411030751.39578.gene.heskett@verizon.net>

OK, there are two different opinions expressed at various places in that
thread: they are that automatically killing processes hung in D state would
be either 1) difficult/nonideal, or 2) impossible.

If it's truly impossible, then that settles it.

But if it's just difficult/nonideal, then here are my thoughts. Again
referencing that thread, there are a bunch of comments saying "that's an NFS
bug, fix the bug" and "that's a samba bug, fix the bug" and "that's a driver
bug, fix the driver."

It's indisputable that there will always be driver bugs and faulty hardware.
Of course these should be fixed, but if it's possible for the kernel to
gracefully deal with the bugs until they get fixed, then why shouldn't it do
so? I understand the goal of making the common (non-buggy) case fast, but
in my experience (and I can't be the only one) buggy hardware/drivers are
becoming more and more common, and with the computer industry getting
ever-bigger and people doing ever-more with their computers, this trend will
only continue (the more hardware on the market the more bugs there will be).

As I stated in my original post, on the 3 different systems I administer, I
need to reboot ~weekly because of the permanent D state. These 3 systems
are completely different, and the processes that hang are different --
digital camera software/drivers, a CDROM, and a printer are among the
sources that have recently caused the permanent D state. Maybe the
non-buggy case is the most common one, but the buggy case is certainly not
UNcommon. If it's possible to wipe out this whole class of problem with
some (admittedly difficult) extra work in the kernel, then I don't see how
that isn't preferable to guaranteeing that people will always need to reboot
their linux systems when they get new hardware that puts processes into the
D state permanently.

-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/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.146 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site