[SGVLUG] More laptop fun--IRQ assignments

[David Lawyer]

On Sat, Nov 26, 2005 at 10:58:23PM -0800, Dustin wrote:
[snip]
> I'd like to be able to reassign IRQs.  
[snip]

> Funny thing about laptops, though: the BIOS appears intentionally crippled
> and omits critical capability...like the ability to manually assign IRQs.  
> (Gee, nobody ever needed to do that, right?)  I guess I've never really
> seen how to reassign IRQs in the OS itself, so I'm in new territory again.  
> Some research suggests that reassigning IRQs may be possible but didn't
> turn up anything more definite than the existence of an obsolete and
> unmaintained patch to the APIC kernel code that actually sets up the
> vector.  I did build an APIC kernel which works fine, but doesn't solve
> the conflict--it just moves the overloaded IRQ to #16.

You must be using PCI which allows sharing IRQs.  When a device issues
such an interrupt, all the drivers that share the IRQ have to run
sequentially.  Each driver has to check to see if it's device issued
the IRQ and this isn't too easy since there is generally no register
in the device to tell the driver that the device just issued an IRQ
and the driver hasn't serviced it yet.  Instead, each driver must go thru
a long checklist to see if it's driver issued the IRQ and if so, then
take appropriate action (like taking a bunch of bytes out of a queue in
the device's registers (buffer) and transferring them to memory).
---------------Next 2 pars. probably of no help, but---------------
Now about IRQ assignments.  They may be restricted by a limited number
of traces on the MB and by the way these traces (perhaps only 4) are
hardwired to PCI interrupts.  Each PCI card has only 4 possible
interrupts: A, B, C, and D but each card can have several devices
(called functions) on the card.  The BIOS is supposed to map PCI IRQs
such as 14B (B is not a hex. digit) to ISA IRQs such as 10 used by your
PC.  The BIOS does this mapping by programing a "programmable
interrupt router" the functionality of which is provided by an APIC.
Inputs to this router could include the 4 traces mentioned above.  ISA IRQs
are the result even though there aren't any ISA slots anymore.

Now an "idiot" hardwiring scheme for bonding 4 interrupt traces to all
the PCI slots is to just connect all pci-interrupts A (for all slots) to
trace1, all B to trace2, etc.  Then if all PCI cards have only one
function, they all use interrupt A and trace1.  Trace1 can only be
mapped to only one IRQ.  So no matter how one maps this design,
everything gets the same IRQ unless a card contains more than one
function (device).  This is because PCI specs require one-function
cards to use interrupt A.  Normally one bonds (like soldering) say 11A
to trace1, 11B to trace2, ..., 12A to trace2, 12B to trace3, ...   11,
12, etc. are the PCI slot numbers, perhaps labeled just 1, 2, etc. on
the MB.  This would avoid the above problem.  So the problem may be
due to the scheme of connecting traces to interrupts and no software
can solve this hardwiring.  The BIOS knows this scheme.
---------------------------------------------------------------------------

<asm/io_apic.h> has a function: io_apic_set_pci_routing which can
attempt routing (redirecting) irqs.  Some call it a pin-to-irq map
with the pin being a PCI interrupt pin.  asm may be asm-386 in newer
kernels.  The io_apic.c kernel code is what may need to be patched. I
noticed on the Internet that someone who had a similar problem
(everything on one irq) patched io_apic.c and submitted the fix.  So
perhaps you should try the latest kernel.  Provided of course that its
not due to a poor layout of the interrupt traces on the MB.  Note that
the io in io_apic means it's the part of apic that is not built into
the cpu so io_apic can be thought of as what most people mean by just
apic.  The apic functions are a part of the ACPI system (ACPI != APIC).

OT: ACPI is supposed to deal with the LPC bus which is used on many
laptops as a substitute for the ISA bus.  There might be some activity
in the kernel mailing list to improve support for LPC rather than
trust the BIOS-ACPI to handle it.

So you may just have a buggy PCI-BIOS (actually ACPI) and someone else
may have devised a patch to fix it.  Linux maps the irq's via the ACPI
and if it's buggy then the mapping may not work right.  You could
search the patches to io_apic.c.  There are a lot of them.  Or you
could just try linux-image-2.6.14 in Debian.

			David Lawyer