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.
Regards,
Dave
------------------------------
owner-linux-kernel-digest@vger.rutgers.edu wrote:
>
> From: Brian Ristuccia <brianr@osiris.978.org>
> Date: Tue, 20 Apr 1999 23:54:42 -0400
> Subject: de4x5 hangs aic7xxx, tulip misses port on multiport card
>
> The de4x5 driver when loaded to support my 4 port DEC DC21140 based ethernet
> card hoses my second SCSI controller. After loading the driver and bringing
> up the interfaces, the SCSI card goes into a permenantly hosed condition
> where every attempt to access devices connected to it results in timeouts
> like this one: "scsi : aborting command due to timeout : pid 21989, scsi1,
> channel 0, id 0, lun 0 Read (10) 00 00 92 2d 1b 00 00 08 00" Even after
> unloading the de4x5 driver, the SCSI controller is still hosed. Another
> aic7xxx controller shares the same IRQ and is not affected.
>
> CPU0 CPU1
> 0: 47642 0 XT-PIC timer
> 1: 1346 1359 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 7: 12058 0 IO-APIC-edge Crystal audio controller
> 12: 1042 1128 IO-APIC-edge PS/2 Mouse
> 13: 1 0 XT-PIC fpu
> 14: 6 1 IO-APIC-edge ide0
> 16: 13122 13133 IO-APIC-level bttv, DC21140 (eth2)
> 17: 3072461 3072630 IO-APIC-level aic7xxx, aic7xxx, DC21140 (eth1)
> 18: 977 994 IO-APIC-level Intel EtherExpress Pro 10/100 Ethernet, DC21140 (eth4)
> 19: 12 8 IO-APIC-level DC21140 (eth3)
> NMI: 0
> ERR: 0
>
> The card _must_ share at least one IRQ with at least one of the aic7xxx
> cards because there's only 4 physical IRQ pins on this Intel pr440fx board
> and they're shared between the PCI slots and the onboard components. I've
> upgraded to the latest BIOS, but aside from making my second cpu #12 instead
> of #4, this had no noticable effect on anything.
>
> The 4 port ethernet board uses a DEC DC21052 PCI bridge and 4 DEC DC21140
> PCI 10/100 ethernet chips.
>
> The tulip driver does strange things and refuses to recognise the first one
> of the four ports on my card. It shows a bogus MAC address in the log file
> and says things like "EEPROM not present" and "eth1: Old style EEPROM -- no
> media selection information." I can not use ifconfig to bring up the
> interface the error messages and bogus MAC refer to. The affected port also
> happens to share IRQ 17 with my aic7xxx cards.
>
> After loading and unloading the de4x5 driver, the tulip driver works
> correctly, but my second SCSI card is still hosed. Only a reboot will fix
> the affected SCSI card. After the reboot, the tulip driver will refuses to
> use the first port ethernet again.
>
> Any clues?
>
> - --
> Brian Ristuccia
> brianr@osiris.978.org
> bristucc@baynetworks.com
> bristucc@cs.uml.edu
>
> Please read the FAQ at http://www.tux.org/lkml/
>
-- --------------------------------The Rich Tapestry of Life is Fraying . . .
- 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/