Ingo Molnar <mingo@xxxxxxx> writes: > * Jon Masters <jcm@xxxxxxxxxx> wrote: > >> On Mon, 2009-01-12 at 15:36 -0800, Eric W. Biederman wrote: >> >> > This hardware behavior is not specific to boot interrupts or Intel. >> >> It's not specific to Intel, but it is a specific compatibility behavior. >> >> > Is this case really so interesting and compelling that we want to >> > fight through and figure what we need to do to make this work reliably >> > on every x86 chipset? >> >> How else do you propose implementing IRQ handling in e.g. the RT kernel? >> We get a hardware interrupt, we can't FastEOI, we can't process >> synchronously, we can't do all of those things you might expect. >> Implementing RT requires that we delay handling of the IRQ until >> arbitrarily later in the future when we get around to it. > > a number of mainline drivers also mask/unmask irqs from within the IRQ > handler. It's not particularly smart in a native driver, but can happen - > and if we get an active line after that point (and this can happen because > the driver is active), we are in trouble. Yep. Right now it might be simpler to fix the mainline drivers. If we can sit down and write some nice clean obviously correct patches I am all for fixing this bug, possibly even a chipset at a time. However this is a really weird case and people seem to be really struggling to understand what is going on and to write those patches. We are outside the descriptions provided by ACPI so it requires chipset specific knowledge, and a general understanding of how chipsets work to actually even comprehend the problem. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
