On Mon, 15 Jan 2001, Dunlap, Randy wrote:
>
> Thanks for looking into this. I'll be out of touch for
> the rest of this week, but Petr ([EMAIL PROTECTED])
> should be able to test patches that Ingo comes up with.
>
> > Ok. That means that the problem is that we _should_ look at
> > the pirq table even if we use the IO-APIC.
>
> How do we know when to do this?
It's kind of nasty. The IO-APIC detection will disable the pirq table
stuff, see pci-irq.c:
/* If we're using the I/O APIC, avoid using the PCI IRQ routing table
*/
if (io_apic_assign_pci_irqs)
pirq_table = NULL;
now, you could just remove that logic, but I suspect that you'd get
problems simply because the interrupt will then get routing information,
but either the IO-APIC re-naming logic has already moved the irq and it
will be routed to the wrong entry.
So what I _think_ is the correct change is to do roughly this in
arch/i386/kernel/pci-irq.c:
- in pcibios_fixup_irqs(), remove the
#idef CONFIG_X86_IO_APIC
...
#endif
section entirely.
- in pcibios_enable_irq(), at the _end_ (after having enabled the irq
with "pcibios_lookup_irq(dev, 1)", do something like
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
if (irq > 0)
dev->irq = irq;
and add a LOT of debug printk's, and enable DEBUG in pci-i386.h.
It probably won't work on the first try (even if I explained the above
well enough), so send me and Ingo dmesg output, and maybe we'll figure out
something.
And if anybody else understands pirq routing, speak up. It's a black art.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
