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):
Steps to Reproduce:
1. Buy 100 Dell GX150's like we did.
2. Trace the bad network performance to mis-negotiated duplex.
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,
firstname.lastname@example.org\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.
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
MUCH thanks to Andy Morton, Bogdan Costescu, and Donald Becker for helping
in the process of isolating this fault and understanding it.