[tulip] Problems with IRQs on multiport cards

[Donald Becker]

On Thu, 21 Sep 2000, Jonathan Earle wrote:

> My test boxes are mine again, and so I can now continue to work on this.
> We're using kernel 2.4.0-test9-pre4 (the oopses we were having have been
> repaired and so we can now increment the kernel revision).
...
> > No.  An INT (INTA..INTD) is a PCI interrupt pin.
> > An IRQ is an interrupt request level.
> > ISA interrupt pins mapped directly to processor IRQs.
> > A motherboard has an arbitrary mapping from INT pins to logical IRQs.
> 
> So, a PCI motherboard arbitrarily maps PCI INT pins (by pins, you are
> referring to one of the physical traces on the card edge?) to (do you say
> 'logical' due to PCI IRQ sharing?) IRQs?

Correct.  The INTA..INTD are physical signals on the PCI bus.
IRQs are now virtual concepts within the processor and support chipset.

For instance "SBLink" is a way for a sound card to raise use multiple IRQs
and DMA requests on a single wire by using a serial protocol.

> > > The reason I asked was that the code for the de4x5 driver 
> > had a function to
> > > request an IRQ (called from the init code), and perhaps I read it
> > > incorrectly, but it appeared as though one could pick an 
> > IRQ (say 4) and
> > > then request that from the BIOS (essentially determining 
> > via the BIOS, if
> > > the IRQ was free).  I tried hacking around in there, but it 
> > didn't work (I
> > > didn't get the IRQ I specifically wanted).
...
> > Perhaps you were looking at the EISA support code.
> 
> That driver also supports the PCI cards too, and seems to work better (at
> least, in earlier 2.4.0-testx kernels, we haven't switched back to the tulip
> driver) with the Zynx cards than did the tulip driver.

That's because the 2.4.0-test kernels were using an old tulip driver.

> The function I was referring to was de4x5_open(), and what twigged me onto
> trying to allocate IRQs myself was the following section from that function:
> 
>     if (request_irq(dev->irq, (void *)de4x5_interrupt, SA_SHIRQ,
...
>         if (request_irq(dev->irq, de4x5_interrupt, SA_INTERRUPT | SA_SHIRQ,

No, what this is doing is attempting to work around a bug driver in other
drivers.  The SA_INTERRUPT flag should never be used with shared interrupts,
but some driver writes mistakenly thought that it was faster because that
mode used to be called "fast interrupts".  What that name meant was the
interrupt handler had to be very fast, not that using SA_INTERRUPT was
faster.

See the warning with using SA_INTERRUPT:

>             printk("WARNING: there may be IRQ related problems in heavily
> loaded systems.\n");
....
>             printk("\n              Succeeded, but you should reconfigure
> your hardware to avoid this\n");

> which at first glance, appears to allow one to request an IRQ.  Is this an
> incorrect interpretation?

This is the driver requesting to register an interrupt handler.  It is not
requesting the remapping of an IRQ.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403