I don't see where this is really relevant if bios32.c does the following:
#ifdef __SMP__
/*
* Recalculate IRQ numbers if we use the I/O APIC
*
* NOTE! If the "original" interrupt is marked as an old-fashioned
* irq, we have to keep it old-fashioned even if it's a PCI device
* and we could have found it in the MP-table transform.
*/
No matter what, bios32.c will assign the Ethernet card to IRQ 9 if it is marked
as an old-fashioned irq (which it is), even though it is a PCI device and we
can't assign anything to IRQ 9 on the DK440LX (as per docs).
I think that this contradicts the whole idea of APIC IO IRQ reassignment.
Why does this have this assignment? Shouldn't APIC IO have the final say in
IRQ reassignment when we use SMP? This make more sense to me when an SMP
system's MP-table to transform irqs that we should be using and not relying
upon how the "original" interrupt is marked.
Or am I missing a key 'hack' to disable IRQ 9 from being assigned by bios32.c?
>>Matthew G. Marsh wrote:
>>
>> Perhaps this snippet from the Intel MB site may help -
>>
>> IRQ9 cannot be re-assigned
>>
>> IRQ9 is not available to assign to
>> ISA add-in cards because it is
>> dedicated to the power
>> management function of the PIIX4
>> controller on the motherboard.
>> This is true for other motherboards
>> which use the 82371AB PIIX4
>> component.
>
>this looks promising. We can safely detect the PCI ID of the 82371AB PIIX4
>runtime, instead of querying the ACPI BIOS about the status of IRQ9 (which
>we cant do currently) ... thus the horrible hack of disabling IRQ9 on all
>boards can go away.
>
>-- mingo
>
-- Thanks, Troy---------------------------------------------------------------- email: tmuller@agora.rdrop.com PGP 5.0 key: hkp://pgp.ai.mit.edu web: http://www.eecs.wsu.edu/~tmuller helpful suggestion: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ----------------------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html