Message-ID: <421A6426.6020802@nortel.com>
Date: Mon, 21 Feb 2005 16:43:50 -0600
From: Chris Friesen <cfriesen@nortel.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115
MIME-Version: 1.0
To: Anthony DiSante <theant@nodivisions.com>
CC: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: uninterruptible sleep lockups
References: <421A3414.2020508@nodivisions.com> <200502211945.j1LJjgbZ029643@turing-police.cc.vt.edu>            <421A4375.9040108@nodivisions.com> <200502212054.j1LKs3xi032658@turing-police.cc.vt.edu> <421A5E28.1030409@nodivisions.com>
In-Reply-To: <421A5E28.1030409@nodivisions.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 911
Lines: 22

Anthony DiSante wrote:

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

Think of the overhead required to track every single resource ever 
aquired by the process/thread/entity in question.  Then if/when it 
hangs, you'd have to properly clean up every last one of them.

Much safer/simpler to leave it hung, and force an eventual reboot.

If you have been given code that causes D states, bitch to the supplier 
until they fix it.  Kernel bugs are not acceptable.

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