Description of problem: I have a Realtek RTL8111/8168 Ethernet card (kernel module: r8169). If I boot, then the Ethernet link doesn't come up at all: I get "link down" errors, and no connectivity (Network Manager reports that there is no connection, and ifcfg p2p1 shows "flags=4099<UP,BROADCAST,MULTICAST> ...", and ip link shows "p2p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> ..."). However, if I manually disable auto-negotiation, it starts working. The following fixes the problem: rmmod r8619; /sbin/modprobe --ignore-install r8169; ethtool -s p2p1 autoneg off After I issue that command, the network link comes up immediately. The bug: This work-around (manually disabling auto-negotiation) should not be necessary -- it ought to work right, out of the box. Here is my Ethernet card: # lspci -vv ... 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06) Subsystem: Biostar Microtech Int'l Corp Device 230a ... Kernel driver in use: r8169 # ethtool p2p1 Settings for p2p1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Speed: 10Mb/s Duplex: Half Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes This is after I turned off auto-negotiation. Before turning off auto-negotiation, it looked like this: # ethtool p2p1 Settings for p2p1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: no Some excerpts from dmesg: [ 1.992636] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 1.993051] r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0xffffc90001834000 , b8:97:5a:13:83:b6, XID 0c900800 IRQ 46 [ 1.993053] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 2.042276] systemd-udevd[395]: renamed network interface eth0 to p2p1 [ 2.900144] IPv6: ADDRCONF(NETDEV_UP): p2p1: link is not ready Version-Release number of selected component (if applicable): kernel-3.9.11-200.fc18.x86_64 /usr/lib/modules/3.9.11-200.fc18.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko
By the way, I learned about the workaround (disable auto-negotiation) at the following forum thread, which suggests that I'm not the only one who has experienced this: http://forums.fedoraforum.org/showthread.php?t=250807 I've since found a few other people recommending the same workaround, e.g., http://adam.rosi-kessel.org/weblog/2008/06/21/a-much-simpler-fix-for-the-r8169-link-down-problem https://bbs.archlinux.org/viewtopic.php?pid=901718#p901718
This problem still exists in Fedora 19. Every time my computer goes to sleep, when it wakes up, the Ethernet card gets killed and I have to re-run "ethtool -s p2p1 autoneg off" by hand to get the network card to come back alive.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.