Re: PCI, ACPI, IRQ, IOAPIC: reroute PCI interrupt to legacy boot interrupt equivalent

[Eric W. Biederman]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/