[LAU] Interrupt routing hell

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm the guy with the ASUS Z96F that, by default, puts nearly *everything* onto one IRQ line.

I've been reading up on pirq, mainly here:
http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-HOWTO-4.html
and here:
http://old.lwn.net/1998/0205/io-apic.html

I've also got my annotated output from dump_pirq, here:
http://www.restivo.org/projects/asus/pirq.txt

And system details here:
http://www.restivo.org/projects/asus/system-details/

dump_pirq mostly jibes with what's in /proc/interrupts-- "link 0x60" is what dump_pirq reports as "irq 5" and shows up on my machine as irq 16: the one with everything (disk drive, video controller, audio chip, and firewire) on it.

The ideal thing would be if the BIOS allowed me to route some of these devices onto different INT lines (A,B,C,D), so that they'd end up on different "link" lines, as I am told is the case on ThinkPads. Or even better if they let me route the INTs to different "link" lines (if that's even possible). However, ASUS basically uses the stock AMI BIOS and doesn't seem to have a whole lot of interest and/or expertise in messing with it much. Adding a user interface for a new bit of functionality is a big job-- the kind of thing that IBM would invest the time to do--, but I can't see ASUS being able to justify that amount of work. It would bloat their BIOS and create a whole new set of bugs and support nightmares.

But I've seen hints that it may be possible to do this with Linux, outside of the BIOS.

I'm not clear on exactly what pirq does. It seems to me that all it does is define which "link" line gets assigned to which IRQ number (i.e. 11, 5, 7, etc.) which is pretty useless. I can't imagine caring about which *number* a shared interrupt line gets assigned to. If there are only 5 "link" lines, as is the case on my machine, It seems what I need is to move specific subdevices from one link to another (if that's all that is possible to do). Then again, it'd also be nice if that "unrouted" link 0x68 could get routed to an actual interrupt-- and if pirq can do that, then that would make 6 interrupts to spread things out among, instead of 5. Again, only if it's possible to assign an INT to a "link" via software-- it might be hard-wired in some cases.

I read a tantalizing fragment of information that implies that there are setpci commands which will move devices onto different INT lines. However, I can't seem to find that reference, nor any more details on it, or instructions on how to use it for that purpose. But the setpci docs have reference to "INTERRUPT_LINE", and "INTERRUPT_PIN" constants... ooh cool. It'd also be nice to know if the operations are reversible, i.e. if they persist through the boot process. Otherwise I suppose I can create an initrd with a script that'll run at boot time to set all these things. I'm assuming I have to move the interrupts before the driver for that device is loaded, so I'd essentially turn the initrd into a secondary BIOS. It's also be nice to know that if I hose it up, I can just reboot to get everything back the way it was.

It would be super spiffy if pirq, or setpci, or something else (grub?), would let me override these very poor default BIOS assignments of routes between each devices's INT line and its "link" line, which is apparently what the BIOS's on ThinkPads are doing.

The ASUS people have been very nice, but I've reached point at which they shrug and go, "Hmm, well it works fine on Windows.". I'm guessing that the interrupts are clumped up on Windows just as badly as on Linux, but, who knows, maybe Windows does pirq/setpci or similar magick to space the interrupts out a bit better.

- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGMXEle8HF+6xeOIcRAoI+AJ4/agf+wKbYSKyhB+YaNshJhJAftACgn2mG
5GLQ/y6JPrD0zR6So+Vl5yc=
=MZ+S
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
Received on Fri Apr 27 08:15:02 2007