[tulip-bug] Fixed 100BaseT full duplex casues 1-2% loss

Mon Jan 7 12:58:01 2002

Hi there tulip hackers,

I seem to be having a problem with the Tulip driver and a Intel DEC 21143 based card. The gist of the problem is that although the card works fine in auto-negotiate (100BaseT full duplex), when I try to force 100BaseT full duplex (and same on the other end of course) I get 1-2% loss. The loss is "on the card", not counted in the Linux counters. It is visible only if you count received vs. transmitted packets (used a Shumiti Surveyor for this).

The card in question is a custom made and it's got two ports. However, the very same condition seems to occur also with a Kingston and D-link (quad ports) Tulip chipsets based cards, and does not occur with the standard tulip drivers for Windows with the custom card and therefore I assume the problem might be driver related.

The problem was first noticed when using modified tulip driver derived from the original tulip.c:v0.91g-ppc 7/16/99 (the changes done were moving to a polling mode from interrupt mode and enlarging the ring buffers, same stuff the Click modular router guys did if you're familiar with their work) but we duplicated the very same behavior with the current driver offered on the web page.

As mentioned above, the standard Windows tulip drivers works and does not exhibit this behavior. I also tried the "alternative" de4x5 driver and discovered that if set to a forced  100BaseT full-duplex it does not detect a link at all (it does work with auto-neg.).

An interesting tidbit that may or may not be related: The Intel Tulip errata state that the tulip chipset has a bug which results in the condition that when the you set the chipset to forced 100baseT FD, carrier will not be sent up, causing a false carrier error interrupt on each transmit (and the running of the handler of that error that restarts RX and TX of the card). Our adapted driver doesn't do this (because we disabled interrupts) but as I said, the same behavior described still happens in "our" and in the latest driver from the web page so this may not be related to the problem at hand, but might be of interest for other reasons.

>From scanning some questions on the list and on other forums, I suspect that some people have stumbled on this bug before, but it seems that none of them seemed to focus it enough to get a clear answer. Then again, this might have been answered before and I missed it - if so please accept my apologies.

Any help (pointers, ideas, FAQ) will be greatly appreciated. More info request will be happily answered.
Explaining why I am stupid is also considered help if you also show me how to fix the problem ;-)

Many tanks,
Gilad.

Parameters used are:

insmod tulip.o options=0x5 full_duplex=1
(we also tried many other combinations).

Thus spake tulip-diag:

tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a Digital DS21143 Tulip adapter at 0xdc00.
Digital DS21143 Tulip chip registers at 0xdc00:
 0x00: f8a08000 ffffffff ffffffff 00214010 00215010 f0660045 320ca202 fbfffb3a
 0x40: e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 ffffffff 8ffd0000
 Port selection is MII, full-duplex.
 Transmit started, Receive started, full-duplex.
  The Rx process state is 'Waiting for packets'.
  The Tx process state is 'Idle'.
  The transmit threshold is 512.
  The NWay status register is 000000c6.
  Internal autonegotiation state is 'Autonegotiation disabled'.
Index #2: Found a Digital DS21143 Tulip adapter at 0xd880.
Digital DS21143 Tulip chip registers at 0xd880:
 0x00: f8a08000 ffffffff ffffffff 00210010 00211010 f0660045 320ca202 fbfffb3a
 0x40: e0000000 fffd83ff ffffffff 00000000 000000c6 ffff0000 ffffffff 8ffd0000
 Port selection is MII, full-duplex.
 Transmit started, Receive started, full-duplex.
  The Rx process state is 'Waiting for packets'.
  The Tx process state is 'Idle'.
  The transmit threshold is 512.
  The NWay status register is 000000c6.
  Internal autonegotiation state is 'Autonegotiation disabled'.

mii-diag had this to say on the first port (eth2):

Basic registers of MII PHY #0:  2100 780d 0013 78e2 01e1 0081 0004 2001.
 Basic mode control register 0x2100: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, full-duplex.
 You have link beat, and everything is working OK.
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.

mii-diag said this on the second port (eth3):

Basic registers of MII PHY #0:  2100 780d 0013 78e2 01e1 0081 0004 2001.
 Basic mode control register 0x2100: Auto-negotiation disabled, with
 Speed fixed at 100 mbps, full-duplex.
 You have link beat, and everything is working OK.
 Your link partner is generating 100baseTx link beat  (no autonegotiation).
   End of basic transceiver information.

-- 
Gilad Ben-Yossef <gby@kagoor.com>
Tel: +972(9)9717330 | Fax: +972(9)9717334   | Cel: +972(54)756701
Kagoor Networks ltd | http://www.kagoor.com | 