[ Left all the quotes intact, because I would like Ingo to give this a
quick look. Sorry about the noise.. ]
On Thu, 21 Sep 2000, M.H.VanLeeuwen wrote:
>
> Legacy would be just fine, but ISAPNP is attempting to assign an IRQ that is
> unavailable on my system. In otherwords, the BIOS has assigned it to some
> other function and thus the IRQ doesn't appear to Linux as even existing.
> In my case IRQ5 was assigned to "DISPLAY CONTROLLER" and IRQ5 isn't available
> to the system, excerpts from dmesg:
> ...
> Bus #2 is ISA
> I/O APIC #2 Version 17 at 0xFEC00000.
> Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 *** NO ISA IRQ 5 ***
> Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06
> ...
> ENABLING IO-APIC IRQs
> ...changing IO-APIC physical APIC ID to 2 ... ok.
> Synchronizing Arb IDs.
> init IO_APIC IRQs
> IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-17, 2-20, 2-21, 2-22, 2-23 not connected.
> ^ no IRQ 5 ?
> ...
> IRQ redirection table:
> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
> 04 003 03 0 0 0 0 0 1 1 49
> 05 000 00 1 0 0 0 0 0 0 00 *** IRQ 5 ??? ***
> 06 003 03 0 0 0 0 0 1 1 51
>
> Yet ISAPNP decided to assign that IRQ5 to my NIC. ne.c fails to operate
> when there are plenty of other IRQs still available.
Hmm..
The legacy side should still work. The fact that it isn't routed to the
IO-APIC probably means that it is routed directly to the legacy stuff,
like the timer normally is.
However:
> The difference is in this logic between _no_ IO-APIC and _yes_ IO_APIC
> in isapnp.c
>
> isapnp_for_each_dev(dev) {
> if (dev->active) {
> if (dev->irq_resource[0].start == irq ||
> dev->irq_resource[1].start == irq)
> return 1;
>
> }
> }
>
> since w/o IO_APIC no PIC->APIC IRQ transform is done and this returns 1
> and IRQ 5 is not used. With IO_APIC no match occurs and the system attempt
> to use IRQ 5, thus a hung system.
I have this suspicion that the correct interrupt mapping would be found in
the MP table.
The same way PCI interrupts get mapped by the MP table to their "real"
mapping, any other irq numbers probably should too - we've mapped the
legacy irq 5 away to another interrupt, and nobody told ISA-PnP, so irq 5
is probably _really_ somewhere on irq 18 or similar with the IO-APIC
enabled.
> Hence, my attempt to rule out APIC IRQs that were unavailable to the system,
> also assuming the legacy IRQs would also not be available. This may not be
> globally true, but seems to be on my system. Abit BP6, nu Bios.
>
> This entire problem would not have bothered me too badly, had the system
> come up and run, but w/o explicitly telling the BIOS to reserve an ISA
> IRQ ISAPNP eventually decides to try IRQ 12. IRQ sharing with PS/2 mouse
> and ne.c fail miserably. On 2.2.X I had been using IRQ9 for ne.c card.
> With 2.4 IRQ 9 is listed after IRQ 12 in xtab[16] (isapnp.c) so the system
> fails to boot.
>
> > Especially as they seem to be acceptable if there are _no_ IO-APIC irq's.
>
> Only if they work. ;)
The irq is still there, it's just that it's mapped somewhere else. The MP
table should give the mapping.
Please find the "mptable" program, and run it. If you don't already have
it on your system, search for it on google or something.. It will print
out your whole MP table, and that might give a better clue about where irq
5 has gone, and what we should do inside the ISA PnP code to find the
right irq..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:26 EST