[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/x86/x86
On Mon, 12 Jan 2009, Bernd Ernesti wrote:
On Mon, Jan 12, 2009 at 08:36:36AM +0000, Stephen Borrill wrote:
Module Name: src
Committed By: sborrill
Date: Mon Jan 12 08:36:36 UTC 2009
Return ENOENT instead of panicking when irq doesn't equal line
(mpacpi_findintr_linkdev: irq mismatch). This doesn't fix the cause of
kern/38540, but stops the bogus panic. It's pretty definite that the device
with the mismatched irq will not function.
But it is not obvious why it doesn't work for non technical persons.
Thats what the panic will 'fix'.
This is a philosophical issue (and an important one). If
there is a serious failure in a driver which does not imply
data structure corruption, should the system panic to
generate the 'highest visibility' alert, or log something
to the kernel mesglog and continue, disabling that driver.
Personally I'm very much in the latter camp: the kernel
should only panic() if its unable to continue, or has
detected data structure corruption.
I might go so far as to say NetBSD should have a consistent
policy on this - and one that core should decide.
David/absolute -- www.NetBSD.org: No hype required --
Main Index |
Thread Index |