this seems really poor bios design: @mini rminnich]# lspci -v -v | grep Interrupt Interrupt: pin A routed to IRQ 11 Interrupt: pin B routed to IRQ 11 Interrupt: pin C routed to IRQ 11 Interrupt: pin A routed to IRQ 11 Interrupt: pin B routed to IRQ 11 Interrupt: pin B routed to IRQ 11 Interrupt: pin B routed to IRQ 11 Interrupt: pin A routed to IRQ 11 Interrupt: pin A routed to IRQ 11 Interrupt: pin B routed to IRQ 11 Interrupt: pin A routed to IRQ 11 Interrupt: pin A routed to IRQ 11
Pretty much everyone goes to IRQ 11.
And a bunch of Interrupts go unused:
CPU0
0: 3381694 XT-PIC timer 1: 13873 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 11: 77842 XT-PIC usb-uhci, usb-uhci, usb-uhci, eth0, wlan0, Ricoh Co Ltd RL5c476 II, Ricoh Co Ltd RL5c476 II (#2) 12: 360259 XT-PIC PS/2 Mouse 14: 85559 XT-PIC ide0 NMI: 0 ERR: 0
Is there any reason a BIOS would do this?
ron
...
You can go into your laptops bios and reassign them if you don't like that setup, I had the same setting in my tpx20.
Is there anyone who knows if that setup is bad or not? Does it do any difference?
The things I can think of is:
. drivers don't like to share interrupts, possible resulting in errors I have seen this previously, but not tested it resently
. I have heard something like: "to use the irq 0-15 you have to access the interrupt controller (8259) and to that end you have to access the ISA bus, which means slow access" Is that true?
The only hint I can find is:
$ grep -A3 'Interrupt ReQuest' /usr/src/kernel-source-2.4.20/Documentation/Configure.help (there is a small number of Interrupt ReQuest lines in your computer that are used by the attached devices to gain the CPU's attention -- often a source of trouble if two devices are mistakenly configured to use the same IRQ). The program procinfo to display some
$ grep -A2 distributing /usr/src/kernel-source-2.4.20/Documentation/i386/IO-APIC.txt between the PIRQ lines. (distributing IRQ sources properly is not a necessity, PCI IRQs can be shared at will, but it's a good for performance to have non shared interrupts). Slot5 should be used for videocards, they
$ grep -A16 'Level-Triggered Interrupts' /usr/src/kernel-source-2.4.20/Documentation/mca.txt Level-Triggered Interrupts ==========================
Because MCA uses level-triggered interrupts, a few problems arise with what might best be described as the ISA mindset and its effects on drivers. These sorts of problems are expected to become less common as more people use shared IRQs on PCI machines.
In general, an interrupt must be acknowledged not only at the ICU (which is done automagically by the kernel), but at the device level. In particular, IRQ 0 must be reset after a timer interrupt (now done in arch/i386/kernel/time.c) or the first timer interrupt hangs the system. There were also problems with the 1.3.x floppy drivers, but that seems to have been fixed.
IRQs are also shareable, and most MCA-specific devices should be coded with shared IRQs in mind.
$ grep -A1 'SA_SHIRQ' /usr/src/kernel-source-2.4.20/Documentation/pci.txt All interrupt handlers should be registered with SA_SHIRQ and use the devid to map IRQs to devices (remember that all PCI interrupts are shared).
$ grep -A1 'Switching between' /usr/src/kernel-source-2.4.20/arch/i386/kernel/i8259.c * This function assumes to be called rarely. Switching between * 8259A registers is slow.
$ grep -A1 'interr' /usr/src/kernel-source-2.4.20/arch/i386/kernel/io_apic.c | grep pola /* EISA interrupts are always polarity zero and can be edge or level /* ISA interrupts are always polarity zero edge triggered, /* PCI interrupts are always polarity one level triggered, /* MCA interrupts are always polarity zero level triggered,
Are there any other issues abut irq assignments?
BTW, does things crash on you, do you get worse performance, can't different drivers function with the same irq, or what?
Regards, /Karl
----------------------------------------------------------------------- Karl Hammar Aspö Data karl@kalle.csb.ki.se Lilla Aspö 2340 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------