[lkml]   [2001]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: int. assignment on SMP + ServerWorks chipset

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 (
> 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

- in pcibios_fixup_irqs(), remove the


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

And if anybody else understands pirq routing, speak up. It's a black art.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:17    [W:0.070 / U:4.440 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site