Bug 98499 - tg3 with bcm5703x doesn't negotiate correctly
tg3 with bcm5703x doesn't negotiate correctly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
2.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
:
Depends On:
Blocks: 122776 123573
  Show dependency treegraph
 
Reported: 2003-07-02 15:54 EDT by Kevin Krafthefer
Modified: 2008-10-06 12:25 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-06 12:25:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin Krafthefer 2003-07-02 15:54:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
background: we disable n-way autonegotiation on our FE switch ports, and we
force the interface to 100FD from the host. When we first boot up with the
Broadcom 5701 interfaces, the interface links at 100HD until we use ethtool to
force it to 100FD. This is fine, since we get link even with the duplex
mismatch, so we can login to the box and fix the problem.

However, with the Broadcom 5703X chipset (on the motherboard on the HP ML370G3),
the interface tries to come up at 10HD. Since the switchport is 100FD, we don't
get any link at all. We then have to login to local console and force 100FD
manually before we can apply our server management tools to the machine.

It would be cool if the BCM5703X would act like the 5701 and come up at 100HD at
least.

post-install modules.conf options don't get taken.

Version-Release number of selected component (if applicable):
negotiates to 10HD when it should find 100FD (driver behaves differently on 5701
chipset)

How reproducible:
Always

Steps to Reproduce:
1. configure tg3 to come up as 100FD in modules.conf
2. reboot
3.
    

Actual Results:  bcm5703x comes up as 10HD
bcm5701 comes up as 100HD

Expected Results:  both come up at 100FD

Additional info:

post-install lines in modules.conf don't get taken.
Comment 1 Nick (Gunnar) Bluth 2003-12-12 07:25:32 EST
We're really suffering from this, too.  
The tg3 module is unreliable like Starfighters (if you still know 
them ;-). 
See Service requests #267715 and #265063 for this... 
Just two days ago I had another box not getting the primary interface 
up, equal what I tried.... 
 
They even tend to not even give a status on driver initialization: 
tg3.c:v1.2e4 (Feb 20, 2003) 
eth0: Tigon3 [partno(NA) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 
10/100/1000BaseT Ethernet 00:0b:cd:b1:45:cf 
eth1: Tigon3 [partno(NA) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 
10/100/1000BaseT Ethernet 00:0b:cd:b1:45:df 
tg3: eth1: Link is up at 100 Mbps, half duplex. 
tg3: eth1: Flow control is off for TX and off for RX. 
 
Sometimes the driver even tells you everything's fine, but you get no 
connection... 
Sometimes the switches don't see a MAC address although you have a 
running ssh session on the interface... 
... 
 
This is crap especially because all our (accepted) vendors (HP & IBM) 
provide these as onboard chipsets now... 
 
Who decided to write a driver without any options (like 
"speed_duplex" for the e100(0) or "line_speed" etc. for bcm5700? 
 
BTW: I think this is kind of a duplicate of #111250 
 
Regards, 
Nick (Gunnar) Bluth 
DrKW Linux team 
 
Comment 3 Don Howard 2004-02-19 18:49:19 EST

*** This bug has been marked as a duplicate of 111250 ***
Comment 4 Don Howard 2004-02-27 13:18:35 EST
111250 is opened against RHEL3.  Reopening this ticket in order to 
track tg3 issues separatly for AS2.1. 
 
Comment 14 Nick (Gunnar) Bluth 2004-09-10 11:57:14 EDT
Almost forgat this ;-)

It showed up in the meantime that Linux boxes with tg3 cards are the 
only ones that negotiate correctly with Cisco switches set to 
autonegotiation... (which no U**X host here ever managed to).

It's normally ok to just leave the switchport set to "Auto".
In some cases we do a
ethtool -s ethX speed 100 duplex full autoneg on
which works fine.

Cheers,

Nick
Comment 24 Jason Baron 2004-10-14 14:00:15 EDT
included in U6 beta
Comment 27 Tony Fu 2008-10-05 21:48:19 EDT
User krafthef@redhat.com's account has been closed

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