Bug 875145

Summary: tg3 link drops on boot
Product: [Fedora] Fedora Reporter: Orion Poplawski <orion>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 18CC: davidplz, gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-27 19:12:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log/messages none

Description Orion Poplawski 2012-11-09 16:14:05 UTC 
Description of problem:

Testing out F18 on a new (for me) Dell Precision T3500.  Often during boot the network link (as shown by lights on the nic) will drop, presumably when the driver is loaded, and not come back up.  Pulling the cable and re-inserting it will bring link up.
 
Version-Release number of selected component (if applicable):
3.6.6-3.fc18.x86_64

How reproducible:
~25-50%?

[    6.589638] tg3.c:v3.124 (March 21, 2012)
[    6.608278] tg3 0000:05:00.0: eth0: Tigon3 [partno(BCM95761) rev 5761100] (PCI Express) MAC address 00:22:19:34:72:40
[    6.608282] tg3 0000:05:00.0: eth0: attached PHY is 5761 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[    6.608285] tg3 0000:05:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    6.608288] tg3 0000:05:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]

[   15.940238] tg3 0000:05:00.0: irq 69 for MSI/MSI-X
[   16.018764] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

pull and re-insert:

[  118.936551] tg3 0000:05:00.0: eth0: Link is up at 1000 Mbps, full duplex
[  118.936555] tg3 0000:05:00.0: eth0: Flow control is on for TX and on for RX
[  118.936578] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Tried different cables/switch port but still see the problem.
Comment 1 Josh Boyer 2012-11-13 14:42:17 UTC 
I have a a Dell XPS 8300 machine here running f18 that uses tg3.  I've not seen similar issues.

If you're still having issues with this, can you attach /var/log/messages from the machine?
Comment 2 David 2013-03-13 10:45:05 UTC 
Created attachment 709478 [details]
/var/log/messages
Comment 3 David 2013-03-13 10:54:39 UTC 
I know this is a 2012 bug report, but I'm having the same issue after the kernel update to 3.8.2.206 in F18.

When I booted the PC there was no ethernet connection. Reloading tg3 kernel module (#modprobe tg3) and NetworkManager made it work.

I thought about it and added "tg3" to dracut.conf as workaround and now when I log in my ethernet connection it's up and working ok without reloading.
I don't now what has happened because I have never forced dracut to include anything before and having no issues up until now.
Comment 4 Josh Boyer 2013-03-13 14:21:26 UTC 
(In reply to comment #3)
> I know this is a 2012 bug report, but I'm having the same issue after the
> kernel update to 3.8.2.206 in F18.
> 
> When I booted the PC there was no ethernet connection. Reloading tg3 kernel
> module (#modprobe tg3) and NetworkManager made it work.
> 
> I thought about it and added "tg3" to dracut.conf as workaround and now when
> I log in my ethernet connection it's up and working ok without reloading.
> I don't now what has happened because I have never forced dracut to include
> anything before and having no issues up until now.

All of the boots show tg3 working fine.  In the last few, it gets brought up as rename3 instead of em1.  I have no idea why that would be, but I don't see any tg3 errors.  I'd suggest opening a new bug against NM.
Comment 5 Justin M. Forbes 2013-03-27 19:12:41 UTC 
Closing this bug as it has been more than 2 weeks without a response. I assume the issue is no longer occurring. Please feel free to reopen if this is not the case.