Bug 112287 - "tg3" driver fails to work with Broadcom BCM5704 GigE (AMD64)
Summary: "tg3" driver fails to work with Broadcom BCM5704 GigE (AMD64)
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: David Miller
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-17 03:24 UTC by Ed Hill
Modified: 2007-11-30 22:06 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-11 01:17:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ed Hill 2003-12-17 03:24:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
Using RHEL AS v3 on a dual-Opteron system with dual on-board Broadcom
NetXtreme BCM5704 Gigabit Ethernet adapters, the "tg3.o" module is
loaded, but network connections fail to work (eg. no DHCP).  Other
ethernet adapters (eg. a cheap-o Realtek PCI card) work just fine, so
it isn't my cabling or other network mis-configuration.  Something is
certainly the matter with the "tg3" module and the BCM5704's.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. configure the network adapter
2. "ifup eth0"
3. no network connection can be established -- also, the lighting
pattern on a 10/100 switch suggests a 10Mb connection rather than
100Mb link

Additional info:

An "ifconfig -a" will load the "tg3" driver modules but no network
connections can be established.  Other network cards seem to work just
fine, so its not a cabling or network setup issue.  Please feel free
to contact me at eh3@mit.edu if you need/want more details -- I'll be
happy to provide them.

Comment 1 Jeff Garzik 2004-01-12 18:48:08 UTC
Does ifdown + ifup, or unplugging then replugging the cable, make
things work?

Comment 5 Jason Tibbitts 2004-04-29 21:48:13 UTC
I'm having a problem that seems similar to this during kickstart.  The
nic does autonegotiation just fine, with the happy traffic light
blinking, up until the moment when Anaconds loads the tg3 driver.  At
that point the link drops and stays off.  Obviously the ksdevice=link
directive doesn't work.  When I choose the appropriate port, it just
barely completes autonegotiation in time for the DHCP request to go
through.  But during operation things are fine.  I have Tyan S2882
boards with two BCM5704s and one eepro100.  I'm only running at
100mbit at the moment.

I have tested with FC1 and FC2t3; the behavior is the same (although
the two kernels order the three nics on the board differently).

Comment 6 Robert Perkins 2004-05-13 20:39:11 UTC
David, what info do you need?

Comment 7 Robert Perkins 2004-05-18 12:54:47 UTC
Can you please confirm that this problem is also present when using
the 2.6 kernel?  I think that is what the statement above says.

Comment 8 Jason Tibbitts 2004-05-19 21:55:30 UTC
If that question was put to me, then yes, the problem did happen under
2.6 (running FC2T3).  However, FC2 release didn't seem to have the
problem at all.  At least, I was able to boot a machine using
ksdevice=link without having to manually specify an interface.  I will
be doing a few more installations on this type of hardware so I will
report back if I see any further problems.

Comment 9 JoAnne K. Halligan 2004-09-10 14:16:26 UTC
Can someone update where this ended up? Was support added for the
Broadcom BCM5721 chipset added in the tg3 driver and in what RHEL? 

(U3 or U4?) See FZ - for the tg3 driver #106886. Looks like support
may have been added and confirmed in U3, but I need to verify this for
FSC asap. 

Thanks, JoAnne

Comment 10 JoAnne K. Halligan 2004-09-10 14:30:14 UTC
FSC IT_35225

Comment 11 Ernie Petrides 2004-09-10 19:57:57 UTC
John Linville, was any of this resolved in the tg3 driver
upgrade that was just committed to U4?

Comment 12 John W. Linville 2004-09-10 20:05:28 UTC
Current tg3 in RHEL3 U4 should be latter than what was in FC2. 
tibbs@math.uh.edu indicated that version of the driver was working, so
I'm guessing what is in U4 should be working too.

Support for the BCM5721 should be included as well...

Comment 13 David Miller 2004-09-10 20:53:14 UTC
Yes 5721 support is in there too.

Comment 14 Ernie Petrides 2004-09-10 22:13:25 UTC
Ed Hill, could you please verify whether the problem you originally
reported is resolved with the U3 kernel (2.4.21-20.EL)?  The erratum
is RHBA-2004:433 (which was released a week ago), and that included
an update to the tg3 driver (to version 3.6RH).

If you still have the same problem, then we could potentially make
a U4-in-progress kernel available to you for testing purposes (but
that hasn't yet gotten any Q/A, so we'd rather not do that if it's
not really necessary).

Thanks.  -ernie

Comment 15 Ed Hill 2004-09-11 01:13:57 UTC
Hi Ernie,

I wish I could!  The board that I originally complained about (an
MSI-9131) was recently decomissioned since it refused to POST.  And we
don't have any other MSI-9131 MBs.  My notes show that the original
RHEL 3AS tg3 driver did not work but the tg3 driver included in Fedora
Core 2 for x86_64 did work and ran reliably for a few months.

We now have two nearly identical dual-Opteron systems both using Tyan
2885 motherboards with the following on-board GigE adapters:

02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X
Gigabit Ethernet (rev 02)
        Subsystem: Tyan Computer: Unknown device 2885
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 24
        Memory at fc6f0000 (64-bit, non-prefetchable) [size=fc6e0000]
        Expansion ROM at 00010000 [disabled]

One of these systems is running RHEL 3AS U2 and the other is running
FC2 with all updates applied.  On both systems, the tg3 drivers are
working nicely.

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