RE: int. assignment on SMP + ServerWorks chipset

[Linus Torvalds]

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 ([e-mail])
> 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