This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0240C.CF642C30
Content-Type: text/plain;
charset="iso-8859-1"
Hi,
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).
> -----Original Message-----
> From: Donald Becker [mailto:becker@scyld.com]
>
> On Wed, 13 Sep 2000, Jonathan Earle wrote:
>
> > > The INT-to-IRQ mapping is unique to the specific motherboard.
> > > Only the motherboard BIOS can set up the mapping,
> including configuring
> > the PCI
> > > bridge on the multiport card.
> >
> > What do you mean by INT to IRQ mapping? I thought that an
> INT(errupt?) and
> > an IRQ were the same thing, yes?
>
> 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?
> > 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).
>
> The de4x5 driver supports EISA cards.
> 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.
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,
lp->adapter_name, dev)) {
printk("de4x5_open(): Requested IRQ%d is busy - attemping
FAST/SHARE...", dev->irq);
if (request_irq(dev->irq, de4x5_interrupt, SA_INTERRUPT | SA_SHIRQ,
lp->adapter_name, dev)) {
printk("\n Cannot get IRQ- reconfigure your
hardware.\n");
disable_ast(dev);
de4x5_free_rx_buffs(dev);
de4x5_free_tx_buffs(dev);
yawn(dev, SLEEP);
lp->state = CLOSED;
return -EAGAIN;
} else {
printk("\n Succeeded, but you should reconfigure
your hardware to avoid this\n");
printk("WARNING: there may be IRQ related problems in heavily
loaded systems.\n");
}
}
which at first glance, appears to allow one to request an IRQ. Is this an
incorrect interpretation?
> > > Verify that the interrupt count is increasing for each port.
> > > It may be that only eth0 is generating interrupts.
> >
> Send traffic only on eth1.
> Verify that the interrupt count increases proportional to
> the packet count.
> Send traffic only on eth2.
> Verify that the interrupt count increases proportional to
> the packet count.
> etc.
Just did that, and the counts appear to be increasing properly.
Cheers!
Jon
------_=_NextPart_001_01C0240C.CF642C30
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: [tulip] Problems with IRQs on multiport cards
Hi,
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).
> -----Original Message-----
> From: Donald Becker [mailto:becker@scyld.com]
>
> On Wed, 13 Sep 2000, Jonathan Earle =
wrote:
>
> > > The INT-to-IRQ mapping is unique to =
the specific motherboard.
> > > Only the motherboard BIOS can =
set up the mapping,
> including configuring
> > the PCI
> > > bridge on the multiport card.
> >
> > What do you mean by INT to IRQ =
mapping? I thought that an
> INT(errupt?) and
> > an IRQ were the same thing, yes?
>
> 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?
> > 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).
>
> The de4x5 driver supports EISA cards.
> 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.
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, lp->adapter_name, dev)) {
=
printk("de4x5_open(): Requested IRQ%d is busy - attemping =
FAST/SHARE...", dev->irq);
if =
(request_irq(dev->irq, de4x5_interrupt, SA_INTERRUPT | SA_SHIRQ, =
lp->adapter_name, dev)) {
&nb=
sp; =
printk("\n &nb=
sp; Cannot get IRQ- reconfigure your =
hardware.\n");
&nb=
sp; disable_ast(dev);
&nb=
sp; de4x5_free_rx_buffs(dev);
&nb=
sp; de4x5_free_tx_buffs(dev);
&nb=
sp; yawn(dev, SLEEP);
&nb=
sp; lp->state =3D CLOSED;
&nb=
sp; return -EAGAIN;
} else =
{
&nb=
sp; =
printk("\n &nb=
sp; Succeeded, but you should reconfigure your =
hardware to avoid this\n");
&nb=
sp; printk("WARNING: there may be IRQ related problems in heavily =
loaded systems.\n");
}
}
which at first glance, appears to allow one to =
request an IRQ. Is this an incorrect interpretation?
> > > Verify that the interrupt count is =
increasing for each port.
> > > It may be that only eth0 is =
generating interrupts.
> >
> Send traffic only on eth1.
> Verify that the interrupt count =
increases proportional to
> the packet count.
> Send traffic only on eth2.
> Verify that the interrupt count =
increases proportional to
> the packet count.
> etc.
Just did that, and the counts appear to be increasing =
properly.
Cheers!
Jon
------_=_NextPart_001_01C0240C.CF642C30--