From: Anthony DiSante <theant@nodivisions.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: uninterruptible sleep lockups
Date: Mon, 21 Feb 2005 17:18:16 -0500 [thread overview]
Message-ID: <421A5E28.1030409@nodivisions.com> (raw)
In-Reply-To: <200502212054.j1LKs3xi032658@turing-police.cc.vt.edu>
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/
next prev parent reply other threads:[~2005-02-21 22:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-21 19:18 uninterruptible sleep lockups Anthony DiSante
2005-02-21 19:45 ` Valdis.Kletnieks
2005-02-21 20:24 ` Anthony DiSante
2005-02-21 20:54 ` Valdis.Kletnieks
2005-02-21 22:18 ` Anthony DiSante [this message]
2005-02-21 22:43 ` Chris Friesen
2005-02-22 0:06 ` Anthony DiSante
2005-02-22 0:36 ` Valdis.Kletnieks
2005-02-21 22:44 ` Anthony DiSante
2005-02-21 23:11 ` Nish Aravamudan
[not found] ` <421B12DB.70603@aitel.hist.no>
2005-02-22 11:16 ` Anthony DiSante
2005-02-22 12:26 ` Denis Vlasenko
2005-02-22 12:35 ` Anthony DiSante
2005-02-22 13:47 ` linux-os
2005-02-22 20:03 ` Anthony DiSante
2005-02-22 20:16 ` Chris Friesen
2005-02-22 20:29 ` Anthony DiSante
2005-02-22 20:24 ` Horst von Brand
2005-02-22 20:56 ` Chris Friesen
2005-02-22 21:40 ` linux-os
2005-02-22 23:17 ` Chris Friesen
2005-02-22 23:42 ` linux-os
2005-02-23 0:25 ` Chris Friesen
2005-02-23 1:05 ` Horst von Brand
2005-02-23 10:04 ` Bernd Petrovitsch
2005-02-22 21:31 ` Olaf Titz
2005-02-23 16:34 ` Nish Aravamudan
[not found] <fa.duv6ag6.p5mth0@ifi.uio.no>
[not found] ` <fa.irk349q.1c3si2o@ifi.uio.no>
2005-02-23 0:59 ` Bodo Eggert
2005-02-23 13:50 ` linux-os
2005-02-24 2:05 ` Bodo Eggert
-- strict thread matches above, loose matches on Subject: below --
2005-02-23 16:55 Parag Warudkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=421A5E28.1030409@nodivisions.com \
--to=theant@nodivisions.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox