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 Modified Files: src/sys/arch/x86/x86: mpacpi.c Log Message: 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 --