> EXTREMELY unlikely. Under a 2.2 no-apic kernel, the aic7xxx card uses IRQ 11
> and works. Under a 2.2 ioapic kernel, it uses high interrupts and works.
non SMP that is clueless ignorance mode, SMP that is MP table mode
> situation. Specifically, if the eepro100 or e100 drivers are not loaded, then
> IRQ 10 is not enabled by any device driver and loading the aic7xxx driver
> simply results in infinite SCSI bus timeouts with nary a single interrupt on
> pin 11. However, if the eepro100 or e100 driver is loaded, then IRQ 10 will
> have an active interrupt handler on it (which implies the interrupt is enabled
> in the PIC) and loading the aic7xxx driver will hard lock the machine (which
Which is exactly why I think it is an IRQ routing table bug. It is wired
to IRQ 10 and claims to be on IRQ 11.
There are two things at work here
PCI_INTERRUPT_LINE - random gunge for the OS
PCI_INTERRUPT_PIN - INTA/INTB/INTC/INTD wiring
The tables are then described by the $PIRQ table in the BIOS. We use that to
load the mapping registers in the PCI bridge (and also to read them). If the
tables are wrong then we will mismap interrupt INTA-D lines to IRQ lines.
IRQ11 appearing on IRQ10 sounds exactly like the INTA-D line setting for IRQ
11 is wrong and we connected it to IRQ 10
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 15 2001 - 21:00:19 EST