From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
When booting, eth0 (aliased to tg3) fails to come up via DHCP configuration,
giving the error message "failed; no link present".
However, running ifup eth0 after system has booted successfully configures the
interface with DHCP.
Also, if I boot up in single user mode, load the tg3 module, and run 'ip link
set eth0 up', and then resume booting, configuration succeeds. I also checked
the output of 'ip link show' immediately after setting it as 'up', and the UP
flag was present.
Maybe the time between the module being loaded and the status being checked
should be tunable?
The only thing I can think of causing this is a slight delay in the time taken
for the link to be negotiated.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot system.
Actual Results: Detection of link as down.
Expected Results: Detection of link as UP, and successful network interface
Hardware is an ASUS P4PE motherboard with onboard Broadcom BCM5702 NetXTreme
The DHCP server is a Windows XP internet connection sharing (ICS) system.
What sort of switch do you have it attached to?
Does it appear to wait a full five seconds before printing the 'no link' message?
The two systems are connected with crossover CAT5.
It does appear to take five seconds before printing the no link message. After
booting, the amount of time taken for 'ifup eth0' to retrieve the information
varies, after a cold boot, it takes roughly another five seconds, but it does
eventually get retrieved.
I've worked around the problem by compiling a custom version of 2.4.20-9 with
tg3 statically compiled into the kernel, this seems to fix it for me.
This is the driver autonegotiating really really slowly.
i doubt if this is a red hat kernel problem though, as it happens on all kernels
i've used, vanilla included. is there a way to speed up autonegotiation, or is
it a hardware issue?
I am seeing this same issue on an IBM Xseries 335, tried the tg3 and bcm5700 and
they both are probelmatic. Also saw it on Delll Poweredge 1650. Same issue
occurs with different 10 base T hubs and 2 100base T switches. Stragely enough
on a cheapy HP desktop the bcm5700 works like a champ. RH9 up2date with 2.4.20-20.9.
You have any suggestions for a quad card or dual port that is known to be work?
My draw of old nics is almost out :-)
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/