Bug 88361 - DHCP configuration of tg3 network interface fails at boot, but works manually
DHCP configuration of tg3 network interface fails at boot, but works manually
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-09 09:14 EDT by leon j. breedt
Modified: 2013-07-02 22:10 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:46 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 leon j. breedt 2003-04-09 09:14:13 EDT
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.
Comment 1 Bill Nottingham 2003-04-09 12:40:13 EDT
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?
Comment 2 leon j. breedt 2003-04-09 16:14:35 EDT
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.
Comment 3 leon j. breedt 2003-04-11 06:06:02 EDT
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.
Comment 4 Bill Nottingham 2003-09-03 21:17:38 EDT
This is the driver autonegotiating really really slowly.
Comment 5 leon j. breedt 2003-09-04 16:42:32 EDT
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?
Comment 6 Ted Kaczmarek 2003-10-08 23:33:23 EDT
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 :-)
Comment 7 Bugzilla owner 2004-09-30 11:40:46 EDT
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/

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