Oh, well.. The problem is that I don't think any of the main developers
have access to such a motherboard, so getting it to work with multiple
APIC's is nontrivial.
>2. Once I got the APIC problem solved, I found that both my eepro100
> and my scsi1 were sharing the same interrupt. / is on scsi1, so
> that interrupt was causing lots of activity. A kernel complile
> resulted in more "scsi: aborting command due to timeout..."
This should _not_ matter, but the problem seems to be that not only were
the interrupts shared, they also seem to be edge-triggered:
>Some system info:
> CPU0 CPU1 CPU2 CPU3
> 0: 18424 30176 149440 30416 IO-APIC-edge timer
> 1: 404 759 3781 761 IO-APIC-edge keyboard
> 2: 0 0 0 0 XT-PIC cascade
> 9: 8907 17891 88969 17802 IO-APIC-edge Intel EtherExpress Pro 10/100 Ethernet
> 10: 2284 3206 16302 3345 IO-APIC-edge aic7xxx
> 11: 45 3 3 8 IO-APIC-edge aic7xxx
> 12: 1257 2539 12729 2487 IO-APIC-edge PS/2 Mouse
> 13: 1 0 0 0 XT-PIC fpu
> 14: 3 0 0 0 IO-APIC-edge ide0
>NMI: 0
>IPI: 0
and having shared edge-triggered interrupts is something that is very
obviously not ever going to work reliably (Linux could try harder to
make it work, but that would just make the problems happen less often
rather than go away completely).
I'd be interested to know if you can move the card back to a shared irq,
if you can also get the BIOS to mark the interrupt as level-sensitive (I
don't know if you even have such a BIOS option, but it's worth looking
around in the "advanced chipset" settings etc for something like that).
I understand that it seems to work for you as-is, but I'd appreciate you
trying out the above alternate setup, just to get some additional
information..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu