Source-Changes archive

[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

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       -- No hype required --

Home | Main Index | Thread Index | Old Index