Re: linux-kernel-digest V1 #3701
Brian Ristuccia (brianr@osiris.978.org)
Mon, 26 Apr 1999 00:18:08 -0400
On Sun, Apr 25, 1999 at 09:46:18PM -0400, David C. Davies wrote:
> Brian,
>
> The SCSI cards have to be doing something funny with the interrupt,
> because the de4x5 driver only tries to attach as SA_INTERRUPT if the
> attempt with SA_SHIRQ fails. If the sharing is being done properly,
> de4x5 should be able to attach to that interrupt too. It's place in the
> /proc/interrupts list shows that it registered *after* the scsi cards:
> have you checked that they BOTH register _just_ SA_SHIRQ or that one
> registers as SA_INTERRUPT|SA_SHIRQ ?
>
> The SA_INTERRRUPT "hack" was put in de4x5 2 years ago as a fix for
> another system and I've had no complaints until now. You will note in
> aic7xxx.c the same "hack" when the driver fails to attach with SA_SHIRQ
> (around line 7916 in 2.2.6).
>
> The deeper question that remains unanswered is why the interrupt appears
> unsharable. You don't mention your kernel version nor de4x5 version, so
> perhaps you'd let me know.
Linux kernel 2.2.6 with the stock de4x5 driver.
It appears that the de4x5 shares nicely with the first aic7xxx on that IRQ,
but somehow "disconnects" the IRQ handler for the second one. As a result,
every request pending on that SCSI card times out almost exactly as if the
card has been rocked out of its socket. Just FYI, the two aic7xxx's are on
IRQ 17, an IO-APIC IRQ.
Also, the tulip driver works fine in this situation (if I do
-DREVERSE_PROBE_ORDER), despite the fact that it assigns IRQ's to the card's
ports very weirdly (and totally different than what /proc/pci says). Also,
if I load and unload the tulip driver, it will reassign IRQ's as per
/proc/pci. Odd.
--
Brian Ristuccia
brianr@osiris.978.org
bristucc@nortelnetworks.com
bristucc@cs.uml.edu
-
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.tux.org/lkml/