3C509 EL3 in 1.3.73 - One step forward, one step backward.

Kris Karas (ktk@enterprise.bih.harvard.edu)
Wed, 13 Mar 1996 23:45:36 -0500


Probably due to vger being slow, I haven't seen any mention of the 3c509
problems since the driver was patched in 1.3.73; my observations:

The "status then 2011, now 2011" printk'ed warning is no longer
generated; however, the code to generate it no longer exists. :-/

The bad news is that, despite code that looks cleaner (indeed, I
couldn't see anything blatently wrong with the el3_interrupt logic),
performance is worse; this is due to momentary, complete wedge-ups of
the interface. With two identical pentium+3c509 setups on the same
cable, `ncftp otherbox:/big-file` performs thusly:
kernel 1.2.13 sending to 1.2.13 - 600 KB/sec.
kernel 1.2.13 sending to 1.3.72 - 400 KB/sec, "then 2011 now 2011".
kernel 1.2.13 sending to 1.3.73 - 300 KB/sec (varies greatly).
When sending to the new 3c509 in 1.3.73, the driver seems to wedge up
completely, usually when back-to-back packets are sent/received,
sometimes for upwards of 1 minutes. This is easily reproduced.
A flood ping (100+ icmp-echo packets/sec) from the 1.2.13 box usually
un-wedges the 1.3.73 driver, but not always; in any case, it usually
un-wedges itself in a few minutes.

Analysis, such as it is: Again, the logic in the el3_interrupt routine
looks solid algorithmically; however, I don't have any access to 3c509
technical manuals, so I'm not sure about subtleties. One possible
problem is that, though the el3_tx routine acknowledges its own
interrupt (AckIntr | 0x08), the el3_rx routine does not; whether or not
el3_rx is ever called, el3_interrupt always does an (AckIntr | 0x41).
Since the read-status-and-dispatch-until-nothing-to-do algorithm loops
until the status is quiescent, this double-ack should be harmless;
however, I don't know enough about the hardware to say if this
assumption is true. Anybody know the real scoop? Russ?