I've played a bit with runtime PM and found that ethernet card can't detect link anymore just after enablink runtime PM 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Initially: Runtime PM enabled, link is down. Then plug cable in and "ifup" interface: [158575.112239] r8169 0000:05:00.0: PME# disabled [158575.117610] r8169 0000:05:00.0: eth0: link down [158575.117632] r8169 0000:05:00.0: eth0: link down [158575.117945] ADDRCONF(NETDEV_UP): eth0: link is not ready Then disable Runtime PM in powertop for ethernet: [158671.844410] r8169 0000:05:00.0: PME# enabled [158731.840293] r8169 0000:05:00.0: PME# disabled [158731.860574] r8169 0000:05:00.0: eth0: link down [158733.773350] r8169 0000:05:00.0: eth0: link up [158733.773699] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Is this a regression? Were earlier kernels OK? If so, which version? Thanks.
No, it isn't a regression AFAICS. It's a new feature (disabled by default) not working correctly.
Also I'm going to handle it.
This is first time I'm playing with runtime PM. So I don't know.
A bit detailed steps: 1. Initial state: cable unplugged, iface down, PME disabled 2. Enable PME: [162215.444448] r8169 0000:05:00.0: PME# enabled 3. Plug cable. dmesg not changed 4. ifconfig eth0 up: [162307.024203] r8169 0000:05:00.0: PME# disabled [162307.029392] r8169 0000:05:00.0: eth0: link down [162307.029403] r8169 0000:05:00.0: eth0: link down [162307.029760] ADDRCONF(NETDEV_UP): eth0: link is not ready [162307.128563] r8169 0000:05:00.0: PME# enabled 5. ifconfig eth0 down [162371.500280] r8169 0000:05:00.0: PME# disabled [162371.524675] r8169 0000:05:00.0: PME# enabled 6. ifconfig eth0 up again [162390.316369] r8169 0000:05:00.0: PME# disabled [162390.321586] r8169 0000:05:00.0: eth0: link down [162390.321609] r8169 0000:05:00.0: eth0: link down [162390.321931] ADDRCONF(NETDEV_UP): eth0: link is not ready [162390.420463] r8169 0000:05:00.0: PME# enabled 7. disable PME: [162484.264315] r8169 0000:05:00.0: PME# disabled [162484.284576] r8169 0000:05:00.0: eth0: link down [162485.987480] r8169 0000:05:00.0: eth0: link up [162485.992177] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Well, I can't reproduce the issue with my hardware (MSI Wind U100). It seems to require some more debugging and is almost certainly related to your hardware/firmware configuration and probably is not even related to the r8169 driver (reassigning to Drivers->PCI).
Please attach full dmesg, preferably from 2.6.38-rc7 (or -rc8 when it's out).
Created attachment 50142 [details] dmesg from 2.6.38-rc7 Attaching dmesg from 2.6.38-rc7.
Thanks. Please also attach the output of "lspci -vv" (generated as root) after you've done step 4 in comment #5.
Created attachment 50152 [details] lspci -vv as root after step 4
OK, your adapter appears to signal PME, but that doesn't seem to trigger platform events. Can you please test with the patch from: https://patchwork.kernel.org/patch/612171/ applied?
Hi, I've built same 2.6.38-rc7 kernel with your patch and it works! ... plug cable ... [ 211.016249] r8169 0000:05:00.0: PME# disabled [ 211.021383] r8169 0000:05:00.0: eth0: link down [ 211.021398] r8169 0000:05:00.0: eth0: link down [ 211.021765] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 211.120471] r8169 0000:05:00.0: PME# enabled [ 213.428249] r8169 0000:05:00.0: PME# disabled [ 213.448510] r8169 0000:05:00.0: eth0: link down [ 215.152314] r8169 0000:05:00.0: eth0: link up [ 215.152632] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready It detects link after ~3 sec after cable plug.
This means that the native PCI Express wakeup signaling works with your network adapter, while the ACPI-based wakeup signaling doesn't. We might debug further to figure out why the ACPI-based wakeup signaling doesn't work for you, but https://patchwork.kernel.org/patch/612171/ has been submitted for merging, so I don't really see the point.
Hi, I'm having related problem, but it seems it is not cured by your patch. It still exists at least in 2.6.38.5. Steps to reproduce: 1. Cable all time plugged in. Start network normally. 2. Enable PME. 3. Wait some days, I suspect it happens when there is not much network traffic for some time. 4. Network is down, dmesg is filled with many instances of: .... [1451656.134121] r8169 0000:03:00.0: PME# disabled [1451656.134988] r8169 0000:03:00.0: eth0: link down [1451656.143224] r8169 0000:03:00.0: eth0: link down [1451656.234131] r8169 0000:03:00.0: PME# enabled [1451659.990634] r8169 0000:03:00.0: eth0: link up [1451660.002142] r8169 0000:03:00.0: PME# disabled [1451660.003025] r8169 0000:03:00.0: eth0: link down [1451660.010397] r8169 0000:03:00.0: eth0: link down [1451660.103126] r8169 0000:03:00.0: PME# enabled [1451662.825160] r8169 0000:03:00.0: PME# disabled [1451662.834810] r8169 0000:03:00.0: PME# enabled [1451662.926498] r8169 0000:03:00.0: PME# disabled [1451662.928631] r8169 0000:03:00.0: eth0: link down .... 5. Without enabling PME it does not happen. 6. Manually restarting network solves the problem (i.e. /etc/init.d/net.eth0 restart)
(In reply to comment #14) [...] > I'm having related problem, but it seems it is not cured by your patch. It > still exists at least in 2.6.38.5. Your chipset is identified as 8168e in bug 33782. 2.6.38.5 lacks support for it and I doubt that adding it would be appropriate for a -stable serie. -- Ueimor
Created attachment 67632 [details] dmesg 3.0.0
unfortunately the bug described in #14 is still present in 3.0.0, although I had to wait for a week should I open a new bug since this one is flagged "resolved" ?