Bug 248948 - tg3: "no link present"
tg3: "no link present"
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-19 15:15 EDT by Andrew McNabb
Modified: 2009-01-09 02:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 02:10:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andrew McNabb 2007-07-19 15:15:57 EDT
Description of problem:

ifup fails for the tg3 network driver because the script thinks that no link is
present.  Setting PERSISTENT_DHCLIENT is a workaround.


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


How reproducible:

Try doing ifup under the normal configuration:

root# ifup eth0
Determining IP information for eth0... failed; no link present.  Check cable?


Workaround: try doing ifup with PERSISTENT_DHCLIENT set (which makes it so it
doesn't check the link status):

root# echo "PERSISTENT_DHCLIENT=yes" >>/etc/sysconfig/network-scripts/ifcfg-eth0
root# ifup eth0
Determining IP information for eth0... done.


Additional info:

Note that the link light only goes on a few seconds after dhclient starts.  It's
not on automatically on boot.

Also note that when I install by PXE booting and installing from network media,
there are no problems anywhere with network detection.

From lspci:

02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit
Ethernet (rev 02)
Comment 1 Radek Vokal 2007-07-20 02:40:47 EDT
I guess this is more initscripts issue, reassigning for further comments.
Comment 2 Bill Nottingham 2007-07-20 16:43:32 EDT
If link detection is not working, that is a driver issue.
Comment 3 Christopher Brown 2007-09-20 06:46:33 EDT
Hello Andrew,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris
Comment 4 Andrew McNabb 2007-09-20 11:15:12 EDT
I'm in the process of checking.  I'll have to disable the workaround I described
before I will know for sure.
Comment 5 Andrew McNabb 2007-10-08 02:05:15 EDT
I checked a week or two ago with kernel-2.6.22.5-76.fc7 (the latest kernel), and
verified that the problem was still present.  Thanks.
Comment 6 Chuck Ebbert 2007-10-08 17:38:07 EDT
(In reply to comment #5)
> I checked a week or two ago with kernel-2.6.22.5-76.fc7 (the latest kernel), and
> verified that the problem was still present.  Thanks.

Can you post the contents of /var/log/dmesg from the time after link detection
fails?
Comment 7 Orion Poplawski 2007-10-17 14:01:12 EDT
I think I may be seeing something similar, but it this case it just takes a long
time for link to be detected:

Oct  9 13:25:03 localhost kernel: tg3.c:v3.77 (May 31, 2007)
Oct  9 13:25:03 localhost kernel: ACPI: PCI Interrupt 0000:02:05.0[A] -> Link
[LNKD] -> GS
I 11 (level, low) -> IRQ 11
Oct  9 13:25:03 localhost kernel: eth0: Tigon3 [partno(BCM95705A50) rev 3001
PHY(5705)] (P
CI:33MHz:32-bit) 10/100/1000Base-T Ethernet 00:0f:1f:43:3d:48
Oct  9 13:25:03 localhost kernel: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0]
WireSpeed
[1] TSOcap[1]
Oct  9 13:25:03 localhost kernel: eth0: dma_rwctrl[763f0000] dma_mask[64-bit]
Oct  9 13:25:03 localhost kernel: NET: Registered protocol family 23
...
During ifup:
Oct  9 13:25:03 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
...
During NetworkManager start:
Oct  9 13:25:21 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
...
Finally:
Oct  9 13:25:40 localhost kernel: tg3: eth0: Link is up at 100 Mbps, full duplex.
Oct  9 13:25:40 localhost kernel: tg3: eth0: Flow control is off for TX and off
for RX.
Oct  9 13:25:40 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

So, takes about 40 seconds here.
Comment 8 Andrew McNabb 2007-11-16 14:23:28 EST
I just installed Fedora 8 on this box (with 2.6.23.1-49.fc8).  I'm still getting
exactly the same problem as in the past.  I'm including some excerpts from dmesg
in case it helps.


Initialization of tg3:

tg3.c:v3.81 (September 5, 2007)
ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 24 (level, low) -> IRQ 24
eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit)
10/100/1000Base-T Ethernet 00:e0:81:2d:a2:e9
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[769c4000] dma_mask[64-bit]


I believe the following happens when the initscripts try to initialize eth0:

ADDRCONF(NETDEV_UP): eth0: link is not ready


If I do "dhclient eth0" manually, the following appears in dmesg:

ADDRCONF(NETDEV_UP): eth0: link is not ready
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready


I have several machines that are nearly identical.  This problem never happens
on one of them, always happens on another, and happens intermittently on a
third.  However, setting PERSISTENT_DHCLIENT always works because then the
initscripts don't check for a link before initializing.  Note again that the
link light on the back of the machine does not turn on until a few seconds after
dhclient has started.
Comment 9 Christopher Brown 2008-01-16 18:13:32 EST
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
Comment 10 Andrew McNabb 2008-01-17 10:04:35 EST
I have not noticed any changes recently.
Comment 11 Christopher Brown 2008-01-17 10:59:11 EST
Okay, thanks for the update Andrew. I've had a look at the 2.6.24 changelog (as
it currently stands) and whilst there aren't any changes particularly relevant
to your bug that I can immediately see, there have been quite a few updates so
it may be worth testing with one if you can from the development repository:

# yum update kernel --enablerepo=development

If you're still having problems then we know the issue hasn't been resolved and
I'll re-assign to the relevant maintainer. It might also be a good candidate for
filing at the upstream kernel.org bugzilla.
Comment 12 Andrew McNabb 2008-04-14 11:27:32 EDT
This problem is still occurring in current rawhide.  It's now worse because
rawhide uses NetworkManager by default instead of the normal network init
script.    As a result, the PERSISTENT_DHCLIENT workaround doesn't work anymore.
Comment 13 Bug Zapper 2008-11-26 02:35:21 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Bug Zapper 2009-01-09 02:10:46 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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