Red Hat Bugzilla – Bug 58211
Autonegotiate flaky with certain 3c905c chipsets
Last modified: 2007-04-18 12:38:57 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-12 i686) Description of problem: The 3c59x.o module sometimes mis-negotiates Half/Full Duplex with certain versions of the 3c905c chip sets. Donald Becker says this is fixed in a more recent version of the alternate driver. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. Buy 100 Dell GX150's like we did. 2. Trace the bad network performance to mis-negotiated duplex. 3. Additional info: I see that the 3c59x.o module in the updated 7.1 system we are running reports Vers LK1.1.16, as does the module shipped with the kernel RPM of Red Hat 7.2. The alternate driver that Becker says works around these early, and flaky chips says, "3c59x.c:v0.99U 7/30/2001 Donald Becker, becker@scyld.com\n" for the version string. When was the last time the 3c59x driver was updated for RedHat? Am I looking at the wrong component of the version string? Will upgrading to 7.2 get me a more recent 3c59x.o module?
I am disappointed that, after 2 weeks, there has been no reply or acknowledgement of any kind for this bug. I was made mindful that this is a problem when, at MIT I stumbled into a whole room of systems exhibiting this bug. Could someone PLEASE look at this problem, and and take a stab at saying how it ranks relative to other work? Ideally, someone would be able to at least say definitively whether or not I am right in observing that the 3c59x driver has or has not been updated between Red Hat 7.1 and 7.2.
It occurrs to me that I should provide a better repeat-by. Using vortex-diag ftp://ftp.scyld.com/pub/diag/vortex-diag.c with the -a flag, observe the Manufacture date to be around June 2000. Notice bogus MII flags. This helps identify whether a system will or will not require additional code to properly perform autonegotiation.
The latest 7.1 kernel and 7.2 kernel are identical (2.4.9-21) These have minor updates relative to the original 2.4.2-2 kernel but not many. Donald Becker's drivers are generally not mergable in the 2.4 series and Andrew Morton is the 3c59x maintainer for the 2.4 and 2.5 kernel series... I'll talk to him to see if he has any idea what's going on, as 3c59x's seem very good for just about everybody.
Thank you! That investigation would be most welcome. At MIT, would be willing to test candidate changes that would remedy this auto-negotiation problem. I understand about the difficulty in merging in changes from Becker's alternate driver development line. (I witnessed the "discussion" about the divergence a year or two ago, and was hoping that it had become less of an issue in the fullness of time. Oh well. :-( )
We found that Etherboot was setting EEPROM values that are required for correct 3c905b NICs, but which cause problems with eveybody else. We investigated many possible alternatives, but at this point further effort on the 3c59x driver seems inappropriate. MUCH thanks to Andy Morton, Bogdan Costescu, and Donald Becker for helping in the process of isolating this fault and understanding it.