[tulip] Osicom 4 port card and problem with TX

[Donald Becker]

On Sat, 21 Dec 2002, Edmond E. Shwayri wrote:

> First off, I would appreciate it if someone could explain and/or point me 
> in the right direction as to why all 4 ports should get assigned the same 
> interrupt?

Because that's the way most four port boards are wired.

Four port NICs put four PCI devices behind a bus bridge.  There are two
ways to handle the interrupts, route all to the same IRQ, or put each on
its own INT line.

The Osicom board apparently uses latter.
Most other boards use the former. 

A PCI board that wants to work on all motherboards can only assume that
INTA works.  The INTB, INTC and INTD outputs should work, but don't always.
(It's the usual circular capability testing: since they are rarely used,
they are rarely tested, and thus are rarely used.)

But the buggy BIOSes all use same generic PCI code.  That code assumes a
bus bridge connects INTA..INTD and assigns four separate IRQs to the
devices behind the bridge.

> Why is this a problem?  If it makes any difference, I am 
> running on a Tyan Tomcat IV dual P233MMX which has an Intel HX chipset 
> motherboard.

A board of that era is 100% certain to have the bug.  It was known to be
a bug, but the PCI assignment BIOS code was provided by Intel and the
BIOS providers were not going to touch it to fix a relatively obscure case.

The driver treats the Osicom board differently than other four port
boards.  The Osicom has a configuration EEPROM per NIC, rather than
just one for the "first" NIC.  Thus the driver uses the absence of the
EEPROM to trigger the copying of the IRQ information.

> There are 3 active connections to this card.  eth0 is a Cisco switch 
> (TX-100 Full Duplex), eth1 is a cable modem (standard 10 Half Duplex), eth 
> 2 is not used, and eth3 is another Cisco switch (TX-100 Full Duplex).  I 
> have to force duplex because the Cisco and the card don't negotiate it 
> correctly.

Read 
   http://www.cisco.com/warp/public/473/46.html
for Cisco's changed recommendation on this.

> porenn:/proc# cat interrupts
>             CPU0       CPU1
>   10:      49761      49441   IO-APIC-level  aic7xxx, eth1
>   11:         79         52   IO-APIC-level  aic7xxx, eth0
>   12:     152738     153145   IO-APIC-level  eth3
>   15:       4803       4951   IO-APIC-level  ide2, ide3, aic7xxx

All ports seem to be generating interrupts, although it's difficult to
confirm when mixed with the SCSI controller.

> What doesn't work :
> Copying large files (> 20 Megs) from the computer with the Osicom.
...
> transferring the second file.  It makes it almost look like a software 
> error.  The fact that ftpd and Samba are both doing this is what is giving 
> me pause.  While the transfer is frozen I can still ping the machines and 
> they still route packets between them.  It is only the transfer that
> is frozen.

That shows that the device driver is still transferring packets.

> So in short, my Osicom card has no problem with the RX in any 
> quantity.  Its problem seems to be when the Linux computer is TXing a large 
> amount of data (streaming) on any of the Osicom's ports.  Its almost like a 
> buffer gets full and then things just FUBAR.  I don't know what to look for 
> to determine if this is in the tulip or if my libc is broken.

This sounds like a kernel protocol-level problem, not a driver problem.
Are you seeing any warning messages in the kernel logs, or non-zero error
counts in /proc/net/dev.

-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993