Re: NE2000 PCI problems FIXED!

Kurt Garloff (
Fri, 22 May 1998 00:21:07 +0200

On Thu, May 21, 1998 at 05:47:01PM +0200, Hubert Tonneau wrote:
> Sorry for beeing the bad guy, but i still have cosmetic ones ...
> * 2 90Mhz pentiums
> * AMD PCnet32+PCscsi ethernet+SCSI controler ON THE MOTHERBOARD
> * 3Com 3C900 PCI ethernet controler
> The box is very stable under 2.0.33 (AM53C974 driver for SCSI and
> PCnet32 driver for the network), but was hard to get running on
> the 2.1.x serie (it started to work properly only since 2.1.101 +
> Ingo io-apic.c J patch)

> So I now basicaly have 4 possible configurations since:
> - for the SCSI part, i can use ether the AM53C974 driver or
> the new DC390 1.20g driver written by Kurt Garloff)
> - for the ethernet part, i can use ether the PCnet32 controler
> on the mother board or the 3C900 PCI ethernet card.
> The results are the following (with the 2.1.103 kernel):
> 1) AM53C974 (irq 10) + PCnet32 (irq 9)
> Works fine. Yes, you got it :-)
> 2) DC390 (irq 10) + PCnet32 (irq 9)
> Also works fine, but displays hundreds of so messages:
> eth0: Bus master arbitration failure, status 88f3
> These messages appear when the disk used (IRQ 10 very active)
> witch seems to generate a few unexpected interrupts on IRQ9
> (according to /proc/interrupts report)
> Ok, we can suspect the DC390 1.20g driver since it is very
> new (not yet included in the general kernel tree), but why
> would a bug in a driver handling irq 10 would generate
> interrupts on irq 9 ?

Hmm. I don't think we have spurious IRQs 9. Isn't it possible, that the
AM53C974 chip transfers data on the PCI bus (Busmastering) while the PCnet32
chip tries to do the same but looses. What happens to your network data? Are
the packets OK? Just a little bit slower? Or is network almost stalled when
doing heavy disk IO?

BTW: Did you enable Disconnection, Synchronous transfers and TagQueueing?
(Don't know, if this will save PCI bus allocation time.)

> 3) DC390 (irq 10) + 3C900 (irq 10)
> Dead locks.
> the messages ares:
> scsi: aborting command due to timeout: pid 3939,
> scsi 0, chanel 0, id 0, lun 0 0x00 10 28 24 02 00
> SCSI disk error: kost 0 chanel 0 id 0 lun 0 return code = 26030000
> and:
> eth0: transmit timed out, tx_status 00 status c601
> eth0: Interrupt posted but not handled -- IRQ blocked by another
> device ?
> Flags; bus_master 1, full 0; dirty 149 current 149.
> Transmit list 00000000 vs. c009aa60.
> 0: 0c009aa10 length 8000002a status 0000002a
> ...
> 15: ...

I don't like this ....

The tmscsim driver is able to share IRQs. If I understand correctly what a
driver has to do to support shared IRQs, then it should be working. The
driver checks, if the IRQ is coming from its device and if not it just
returns. This should be OK, shoulnd't it?

The dc390-1.20g driver will do a printk on each IRQ not caused by the
am53c974 chip. This might cause problems. I changed this in 1.20i.
(Please, don't try 1.20h: As soon as your turn on TagQueuing, you will loose
data due to a stupid bug.)

> 4) AM53C974 (irq 10) + 3C900 (irq 10)
> Dead locks.
> In order to run that way, i have to patch irq.c in order to
> enable irq sharing because the AM53C974 does not defaultly
> allow irq sharing.

Add | SA_SHIRQ to the request_irq() call in the am53c974 driver.

At least, my driver is not the only one to fail. ;-(

> >From the many tests i made during this long way to a stable
> 2.1.x kernel, i concluded that what makes my SMP box harder to
> get reliable that many other ones is:
> 1) It is old and so the bios does not provide very accurate informations
> (this seams to have been finaly solved by Ingo patches)
> 2) It is slow, so it is more likely to get overloaded.
> About this point, i would suggest to Ingo and Linus to slow down their
> processors if they can.

It should be working regardlessly of the CPU speed. (OK, if the CPU is too
slow to serve the timer interrupt, it's not possible to work.)

Kurt Garloff, Dortmund 
PGP key on

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