[lkml]   [1998]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ncr53c8xx + tulip IRQ sharing

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) 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

- 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
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

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();


#if 0

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:41    [W:0.073 / U:1.208 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site