Hardware: Thinkpad Edge E420s Distribution: Arch Linux If ifconfig eth0 down and ifconfig eth0 up are not ran within miliseconds of each other no link/carrier will be detected. skynet:~ $ (sudo ifconfig eth0 down; sleep 1; sudo ifconfig eth0 up); sleep 5; cat /sys/class/net/eth0/carrier 0 With a pause of 1 second between the two commands the link/carrier is not detected. /sys/class/net/eth0/carrier remains 0 even after waiting extended periods of time. skynet:~ $ (sudo ifconfig eth0 down; sudo ifconfig eth0 up); sleep 5; cat /sys/class/net/eth0/carrier 1 To further complicate issues, sometimes the opposite is true: skynet:~ $ (sudo ifconfig eth0 down; sleep 1; sudo ifconfig eth0 up); sleep 5; cat /sys/class/net/eth0/carrier 1 skynet:~ $ (sudo ifconfig eth0 down; sudo ifconfig eth0 up); sleep 5; cat /sys/class/net/eth0/carrier 0 Let me know what other information is needed.
I have a similar issue on my acer travelmate with a realtek r8169. (Also Archlinux, both 2.6.38.3 and 2.6.39-rc4-20110422-00149-g91e8549 (from linus tree)). On my system this made ethernet unusable even before I first run ifconfig down (well maybe something is in the startup scripts). The first time a kernel update actually broke ethernet! Enough ranting: now to the details: 1. Booting the system with kernel 2.6.38.3 or 2.6.39-rc4... : NO_CARRIER. (No LOWER_UP). 2. Run 'ifconfig down && ifconfig up': As explained above: link becomes ready. 3. Turning acpi=off fixes the problem. (Though I"d rather want acpi on.) dmesg output: r8169 0000:02:00.0: PME# disabled r8169 0000:02:00.0: eth0: link down r8169 0000:02:00.0: eth0: link down ADDRCONF(NETDEV_UP): eth0: link is not ready ADDRCONF(NETDEV_UP): wlan0: link is not ready r8169 0000:02:00.0: PME# enabled r8169 0000:02:00.0: PME# disabled r8169 0000:02:00.0: PME# enabled r8169 0000:02:00.0: PME# disabled r8169 0000:02:00.0: eth0: link down ADDRCONF(NETDEV_UP): eth0: link is not ready r8169 0000:02:00.0: eth0: link up ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Notice the PME# messages: disabling acpi (acpi=off in boot parameters) fixes the problem. (Archlinux is the only system running on this computer). About this issue on the netdev list: (Francois Romieu): > Well, as luck would have it, my system will boot today's upstream > kernel (39-rc4+). And, I no longer see the problem in that release, > so it seems it is fixed (or harder to reproduce that I thought). I vote for harder to reproduce. It is not fixed in 39-rc4+.
It may be related to runtime power management, see my last comment on bug https://bugzilla.kernel.org/show_bug.cgi?id=30452 the problem also goes away when I do: echo on > /sys/devices/pci0000:00/0000:00:0a.0/0000:03:00.0/power/control so no need to switch off the whole acpi and I see the problem on 2.6.39 also, running gentoo x86_64
Can you send complete dmesg, including r8169 XID line ? -- Ueimor
dmesg | grep r8169: [ 1.516081] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 1.516100] r8169 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 1.516129] r8169 0000:03:00.0: setting latency timer to 64 [ 1.516162] r8169 0000:03:00.0: irq 42 for MSI/MSI-X [ 1.516300] r8169 0000:03:00.0: eth0: RTL8168e/8111e at 0xffffc90000022000, bc:ae:c5:28:61:95, XID 0c200000 IRQ 42 [ 16.749777] r8169 0000:03:00.0: eth0: link down [ 16.749785] r8169 0000:03:00.0: eth0: link down [ 19.743193] r8169 0000:03:00.0: eth0: link up [304028.067257] r8169 0000:03:00.0: eth0: link down [304031.723550] r8169 0000:03:00.0: eth0: link up [521754.093821] r8169 0000:03:00.0: eth0: link down [521757.674233] r8169 0000:03:00.0: eth0: link up
(In reply to comment #4) > dmesg | grep r8169: Please don't. It removes a lot of information, including the kernel version. > [ 1.516081] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > [ 1.516100] r8169 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > [ 1.516129] r8169 0000:03:00.0: setting latency timer to 64 > [ 1.516162] r8169 0000:03:00.0: irq 42 for MSI/MSI-X > [ 1.516300] r8169 0000:03:00.0: eth0: RTL8168e/8111e at > 0xffffc90000022000, > bc:ae:c5:28:61:95, XID 0c200000 IRQ 42 8168e support is post 2.6.39 (included). Which firmware version - if any - does it run ? You should see the specific fw version with ethtool -i once the device is up. -- Ueimor
I'm sorry I forgot to mention that meanwhile I upgraded to 3.0.0, so maybe PME works now? I can try to turn it on next week. ethtool -i eth0 driver: r8169 version: 2.3LK-NAPI firmware-version: rtl_nic/rtl8168e-2.fw bus-info: 0000:03:00.0
Created attachment 67642 [details] dmesg 3.0.0
Been using 3.0.0 since 2011-07-24 without any problems. For me, this issue is resolved. Thanks!
For me 3.0.0 still shows the bug: https://bugzilla.kernel.org/show_bug.cgi?id=30452
I retract my statement. I'm still having problems using 3.0.3. Would really love to get this solved.
(In reply to comment #9) > For me 3.0.0 still shows the bug: > https://bugzilla.kernel.org/show_bug.cgi?id=30452 The up-down cycle in https://bugzilla.kernel.org/show_bug.cgi?id=30452#c14 suggests that you could be helped by 10953db8e1a278742ef7e64a3d1491802bcfa98b ("r8169: increase the delay parameter of pm_schedule_suspend"). It was added between v3.1 and v3.2. -- Ueimor
> The up-down cycle in https://bugzilla.kernel.org/show_bug.cgi?id=30452#c14 > suggests that you could be helped by 10953db8e1a278742ef7e64a3d1491802bcfa98b > ("r8169: increase the delay parameter of pm_schedule_suspend"). > > It was added between v3.1 and v3.2. I can confirm, running 3.5.1 now and the problem is gone.
(In reply to comment #12) [...] > I can confirm, running 3.5.1 now and the problem is gone. Thanks. Matthew, any update ? -- Ueimor
Sadly, I can not provide any updates as I am no longer in possession of the machine this was happening on. However, thank you for looking into this.