Hello!
> > o PCI interrupt assignments are avoided if IO-APIC is really found,
> > not if it's only configured.
>
> This is still wrong, I bet.
>
> This must an IO-APIC routing bug, not a PCI routing bug. The test that
> disables the PCI router table when IO-APIC is enabled has always been
> buggy, it's no good re-introducing it under a different guise.
>
> If we find the PCI interrupt routing information in the MP tables, we will
> use it, and the PCI router entry for that device gets ignored because
> "dev->irq" will already be set. So the PCI router entry should not clash
> with IO-APIC anyway.
>
> If the MP-table doesn't have the routing, then the PCI router entry is
> valid and interesting, so we don't want to ignore it.
>
> At least this is my "obvious opinion". Which may be wrong. But I'd like to
> know why this test was introduced, and why it isn't considered a problem
> in the IO-APIC code but considered a PCI router problem..
I doubt such IRQ sharing could ever work. Let's look at the most usual
case -- IO-APIC together with PIIX. PIIX routes PCI interrupts to inputs
of its embedded interrupt controller, but they are disabled by io_apic.c
when the IO-APIC interrupts are being initialized. Except for PIRQ#D, no
interrupt pins of the PIIX are I/O, so there is no chance for the IO-APIC
to know about the IRQ. Also, we were leaving the interrupt enabled on the
i8259, it would lead to _two_ interrupts raised simultaneously for the
same IRQ (the sole fact that we don't have the interrupt listed in the
MP-table doesn't mean that it isn't routed to the IO-APIC) and if the
IO-APIC one would be serviced first, it would lead to a lockup.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> <mj@suse.cz> http://atrey.karlin.mff.cuni.cz/~mj/ "Linux vs. Windows is a no-WIN situation."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:23 EST