[tulip] Osicom 4 port card and problem with TX
Sun Dec 22 12:56:01 2002
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
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
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
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 email@example.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993