Bug 58211

Summary:	Autonegotiate flaky with certain 3c905c chipsets
Product:	[Retired] Red Hat Linux	Reporter:	wdc
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-01-25 18:06:51 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description wdc 2002-01-11 01:32:17 UTC

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\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 17:52:43 UTC

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 17:59:45 UTC

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.

Comment 3 Arjan van de Ven 2002-01-25 18:02:31 UTC

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 18:06:46 UTC

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 05:13:26 UTC

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.