IntraServer Quad Ethernet

Rick Kiessig rick@kiessig.com
Wed Feb 23 02:07:19 2000


Hi,

> Interesting. So Rick have you tested the other ports?
> Is it only the port with the conflict with the Intel NIC that
> is giving the problems with collisions? Are the other ports
> working OK?

I tried all of the other ports, and they fail in the same way.

> Why don't we try loading a kernel without the Intel NIC
> driver and see if that fixes the problem.

This doesn't have any effect, either.

> You may want to try using a reverse probe. Do a modular compile with:
> -DREVERSE_PROBE
>
> Or do a insmod with:
> reverse_probe=1

This also has no effect (I used the module method).

Other things I tried today:

-- moving the card from PCI Slot 1 to PCI Slot 2.  Still fails.  IRQ
assignments were unchanged.
-- enabled "Plug-and-Play" in the CMOS Setup (Linux was built with PnP
enabled).  Still fails.  IRQ assignments were unchanged.
-- enabled PCI/APIC interrupt mapping in the CMOS Setup.  This changed the
IRQ assignments to something more sane (SCSI=19, IntraServer=17,22,23,21).
But it didn't fix the performance problem.
-- I tried to force full duplex mode, using "insmod tulip full_duplex=1",
but tulip-diag didn't report it being forced, as I expected it would.  I
suspect I have the wrong argument for full_duplex.
-- With the SCSI IRQ conflict resolved, I decided to try the de4x5 driver
again.  I didn't see a repeat of the SCSI resets that I saw before.  A short
transfer (10MB) went through at full speed.  On a long transfer (100MB), the
collision light on the switch started blinking (but *only* for the
IntraServer port, *not* for the port going to the other machine -- which
still reports zero collisions), and the transfer rate dropped by about a
factor of 3 (from 8MB/sec to 2.7MB/sec).  The ifconfig collision counter is
still incrementing wildly.  The throughput number could well be an artifact
of the way FTP measures transfer rates.
-- Replacing the switch with a crossover cable caused the transfer rate to
drop by yet another factor of 3 (to 870KB/s, compared to appx 220KB/s in the
tulip failure mode).

Any other pointers/suggestions would be appreciated.

In case I can't resolve this soon, ideas for alternative Quad-Port (or even
dual-port) cards that are known to work reliably at full speed with the
current drivers would also be great.

Thanks,

Rick

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org