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): How reproducible: Always Steps to Reproduce: 1. Boot system. Actual Results: Detection of link as down. Expected Results: Detection of link as UP, and successful network interface configuration. Additional info: Hardware is an ASUS P4PE motherboard with onboard Broadcom BCM5702 NetXTreme Gigabit Ethernet. 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 persists. 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/