Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 58211 - Autonegotiate flaky with certain 3c905c chipsets
Autonegotiate flaky with certain 3c905c chipsets
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-01-10 20:32 EST by wdc
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-25 13:06:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description wdc 2002-01-10 20:32:17 EST
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:

Steps to Reproduce:
1. Buy 100 Dell GX150's like we did.
2. Trace the bad network performance to mis-negotiated duplex.

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?
Comment 1 wdc 2002-01-25 12:52:43 EST
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.
Comment 2 wdc 2002-01-25 12:59:45 EST
It occurrs to me that I should provide a better repeat-by.

Using vortex-diag

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.
Comment 3 Arjan van de Ven 2002-01-25 13:02:31 EST
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.
Comment 4 wdc 2002-01-25 13:06:46 EST
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.  :-(  )
Comment 5 wdc 2002-03-27 00:13:26 EST
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.

Note You need to log in before you can comment on or make changes to this bug.