http://morison.biz/technotes/articles/12 I've debugged several linux IRQ problems. More than one has boiled down to erroneous information coming from the motherboard info on PCI/IRQ mapping fed to kernel in mpparse.c. I've debugged a number of linux IRQ problems. This (evolving) article focuses on problems handed down from the motherboard BIOS/mptables (usually the same) Nestled historically between BIOS irq tables and ACPI are MP Tables, Intel's first shot at telling the OS what hardware was running on the motherboard and how to talk to it. If you're not familar, take a look at http://www.intel.com/design/pentium/datashts/242016.htm . The 2.4 kernel is usually dependent on this information. The 2.6 kernel, with a more complete ACPI implementation, doesn't necessarily query this directly. This situation makes some sense, as you would imagine a BIOS/MoBo firmware developer would write one discovery routine and reuse it across the board. However, the current motherboards I'm working with report the same information in all cases (BIOS, MP Tables, ACPI). That is, PCI IRQ assignments given to the OS are the same whether via BIOS calls, MP Tables, or ACPI. Recent work I've done (with the 2.4 kernel) involves debugging the IRQ assignments that get set in stone in mpparse.c. (That's arch/i386/kernel/mpparse.c if you're keeping score.) After writing some very verbose logging in mpparse.c, I found a very useful utility that gives the same information. And, for the life of me, I can't reproduce the google from which I found this utility. It is, nonetheless, tremendously useful; the user mode (root required) utility dumps the MP Table info in a nearly identical fashion as the kernel code in mpparse.c that builds IRQ assignments. Nonetheless, I've got the source mptable source for download. If someone points me at the author's website, (yes, I ... en 2006-2008, Rod Morison Software technotes@morison.biz Thu, 09 Sep 2010 01:20:28 GMT Yet Another Community System http://blogs.law.harvard.edu/tech/rss 70