I'm currently using two Symbios cards and a network card on the same
interrupt without any problems. And no special patches.
I'm using the de4x5 driver with a Kingston card using a DEC chip. I tried
the Tulip driver when I originally installed but it didn't like interrupt
sharing so tried the de4x5 driver and have been using that now for about 9
months. I did get the Symbios cards onto an interrupt on their own for a
while but have now moved them back to the same interrupt as the network
card.
The system is not heavily loaded as there are only two systems on my network
but my last tests involved flood pinging the other system while running
bonnie disk tests on a disk on each of the Symbios cards. This was with the
latest 2.6f version of the Symbios ncr53c8xx driver.
The de4x5 driver has given no problems although there is a warning
about sharing interrupts as the system boots. As PCI is designed to share
interrupts this warning seems out of place.
If there is nothing special in the Tulip driver that your card needs then
maybe you could use the de4x5 driver.
PCI devices found:
Bus 0, device 11, function 0:
SCSI storage controller: NCR 53c810 (rev 17).
Medium devsel. IRQ 12. Master Capable. Latency=64. Min Gnt=8.Max Lat=64.
I/O at 0x6300.
Non-prefetchable 32 bit memory at 0xe1007000.
Bus 0, device 10, function 0:
SCSI storage controller: NCR 53c875 (rev 3).
Medium devsel. IRQ 12. Master Capable. Latency=72. Min Gnt=17.Max Lat=64.
I/O at 0x6200.
Non-prefetchable 32 bit memory at 0xe1005000.
Non-prefetchable 32 bit memory at 0xe1006000.
Bus 0, device 9, function 0:
Ethernet controller: DEC DC21041 (rev 33).
Medium devsel. Fast back-to-back capable. IRQ 12. Master Capable. Latency=32.
I/O at 0x6100.
Non-prefetchable 32 bit memory at 0xe1004000.
Bus 0, device 8, function 0:
VGA compatible controller: Matrox Mystique (rev 2).
Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32.
Non-prefetchable 32 bit memory at 0xe1000000.
Prefetchable 32 bit memory at 0xe0000000.
Non-prefetchable 32 bit memory at 0xe0800000.
Bus 0, device 7, function 1:
IDE interface: Intel 82371SB Natoma/Triton II PIIX3 (rev 0).
Medium devsel. Fast back-to-back capable. Master Capable. Latency=32.
I/O at 0xf000.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371SB Natoma/Triton II PIIX3 (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable. No bursts.
Bus 0, device 0, function 0:
Host bridge: Intel 82439HX Triton II (rev 1).
Medium devsel. Master Capable. Latency=32.
Bye for now
Richard
Gerard Roudier wrote:
>
>
>
> On Sun, 15 Feb 1998, Jon Lewis wrote:
>
> > I've got a couple of brain damaged AIR P90 boards that won't let me assign
> > IRQ's to individual PCI slots. When I use multiple NCR SCSI cards,
> > sharing IRQs between them isn't a problem. When I recently tried
> > upgrading from an ISA ethernet card to a PCI (SMC 8432), the ethernet card
> > wanted to share with the SCSI cards, and ethernet did not work.
> >
> > I found in one of Don Becker's web pages the following:
> >
> > ---
> > My other PCI board always uses the same IRQ as an Adaptec 2940
> >
> > The preferred solution is to put each device on its own IRQ line. But some
> > motherboards, notably the Intel PR440FX, don't permit this. To use both at
> > the same time requires a slight modification of the 2940 driver: remove
> > the SA_INTERRUPT flag to the request_irq() call. This is required whenever
> > the 2940 driver must share an IRQ with any other device driver.
> >
> > - if (request_irq(config->irq, aic7xxx_isr, SA_INTERRUPT | SA_SHIRQ,
> > + if (request_irq(config->irq, aic7xxx_isr, SA_SHIRQ, "aic7xxx",NULL))
> > ---
> >
> > I notice the NCR driver does the same thing (use of SA_INTERRUPT |
> > SA_SHIRQ)...so is it safe to apply the same sort of patch to the NCR
> > driver...removing SA_INTERRUPT? Does doing so introduce any sorts of
> > performance or stability problems?
>
> I am not familiar with the IRQ stuff. Here is what I understood of these
> flags:
>
> - Interrupts requested with the SA_INTERRUPT flag are assumed to be FAST.
> The kernel call the corresponding handlers with interrupts disabled.
>
> - Interrupts requested without the SA_INTERRUPT flag are assumed to be
> less FAST. The kernel call the handlers with interrupts enabled.
>
> - In order to be fully shareable, an interrupt must be requested with the
> SHIRQ flag and must be flagged the same way regarding SA_INTERRUPT by
> all requesters. Mixing (SHIRQ) and (SHIRQ | SA_INTERRUPT) only works
> for the first requester and all those that request the interrupt with
> the same flags as the first requester.
>
> It seems that all scsi interrupts are requested using (SHIRQ |
> SA_INTERRUPT) flags (assumed to be fast), and that all network
> interrupts are requested using (SHIRQ) (assumed to be less fast).
> So, an IRQ cannot be shared by scsi and network.
>
> IMHO, this is not an hardware limitation, but a Linux limitation,
> probably for some performances considerations.
>
> If you hack a SCSI driver regarding request_interrupt flags, you
> just break some assumption on interrupts state for this
> drivers.
> It will be at least required to add some code to disable interrupts
> at interrupt routine entry point and to restore them on exit from this
> routine.
>
> In the ncr53c8xx-2.4X series, the corresponding code is '#ifed 0' in
> the ncr53c8xx_intr() routine, as follows:
>
> #if 0
> u_long flags;
>
> save_flags(flags); cli();
> #endif
>
> ...
>
> #if 0
> restore_flags(flags);
> #endif
>
> If you use a 2.5X version, you will have to restore this code.
>
> This is not guaranteed to take into account any assumption by the
> middle and lower level scsi code. However, since the driver calls
> scsi_done() without restoring the initial interrupt state, this should
> not introduce stability problems IMHO.
>
>
> Gerard.
>
-- Richard Waltham | Work: richard@digtalinterface.demon.co.uk At home in | Home: dormouse@farsrobt.demon.co.uk Southampton UK | 100421.1276@compuserve.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu