Bug 9512
| Summary: | Wake on LAN (WOL) not working with r8169 driver | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Pierre-Yves Bretécher (py.bretecher) |
| Component: | Network | Assignee: | Francois Romieu (romieu) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | akpm, Andreas.Matthus, bonbons, bunk, cypheon, darius, empx, hwt, jieryn, linuxkernel, lucas, mithro, pachoramos1, richard, romieu, tavvva, ucelsanicin |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.22 (ubuntu) | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
Hardcoded wol hack
add PCI device shutdown handler multicast register update for the 8168 Bring the device down more gently Bring the device down more gently r8169-wol.patch - enables the receiver in the rtl_shutdown Reset the chipset before going down Enable Rx when WoL is required .config used for testing .config of my current kernel dmesg lspci -vv lspci -t |
||
|
Description
Pierre-Yves Bretécher
2007-12-06 14:02:07 UTC
> Most recent kernel where this bug did not occur:2.6.22 (also a brief test
> with
> 2.6.24)
Eh? You say this bug is present in 2.6.22 and is also not present in 2.6.22 and 2.6.24.
Wanna try again?
Thanks.
OK, you're completely right, there's a flaw in my report : The bug DID occur in 2.6.22 (Gutsy) and 2.6.24 (Hardy alpha) and I haven't found until now any configuration that works. Sorry for this inconsistency. Thanks. Pierre Yves:
[...]
> - using the Realtek official driver ( r8168 ) in place of the Gutsy provided
> r8169
It made no difference, right ?
--
Ueimor
Created attachment 13898 [details]
Hardcoded wol hack
Completely untested. I'll rework it if it kinda works.
--
Ueimor
Yes, using r8168 from Realtek (r8168-8.003.00) does not work better. I'll try your patch this WE. Thanks a lot. PY When I apply the patch to the r8169.c of my 2.6.22 source tree revision (patch warns me about a fuzz but it seems to work), I can compile the module and it loads without any problem... but when I shutdown, I cannot wake my machine through the magic packet method (which always works when I shutdown from XP). If I try to compile the r8169.c from git (head) after apply your patch (no warning), I have an error when compiling the module : py@PC-FIXE2:/usr/src/linux-source-2.6.22$ sudo make modules CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CC [M] drivers/net/r8169.o drivers/net/r8169.c:392: erreur: field «napi" has incomplete type drivers/net/r8169.c:1090: erreur: unknown field «get_sset_count" specified in initializer drivers/net/r8169.c:1090: attention : initialization from incompatible pointer type drivers/net/r8169.c: In function «rtl8169_down": drivers/net/r8169.c:2906: attention : implicit declaration of function «napi_disable" make[2]: *** [drivers/net/r8169.o] Erreur 1 make[1]: *** [drivers/net] Erreur 2 make: *** [drivers] Erreur 2 Obviously the newer version of the driver does not fit older kernel API (my guess since I do not pretend to understand much about kernel programming). Regards Well, I was wrong thinking your patch doesn't produce any effect because of initramfs. After rebuilding initrd I noticed that when shutting down the machine results in a reboot within less than one second. I also noticed that the ethtool output now indicates :
py@PC-FIXE2:~$ sudo ethtool eth0
[sudo] password for py:
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: pg
Current message level: 0x00000033 (51)
Link detected: yes
So, since it is supposed to wake up on PHY activity it is not completely a surprise.
I tried to manually set wol to "g" only (ethtool -s eth0 wol g). Invoking ethtool again indicates "Wake-on : g" but when I sut down again the machine, it reboots within the next second after shutdown. I tried to setup a starup script that sets "ethtool -s eth0 wol g" in each runlevel but with the same result.
In advance, thank you for your help.
PYB
py.bretecher@free.fr: [...] > So, since it is supposed to wake up on PHY activity it is not completely a > surprise. > > I tried to manually set wol to "g" only (ethtool -s eth0 wol g). Invoking > ethtool again indicates "Wake-on : g" but when I sut down again the machine, > it > reboots within the next second after shutdown. I tried to setup a starup > script > that sets "ethtool -s eth0 wol g" in each runlevel but with the same result. Actually that's good news: the patch does not try to obey the exact wake-up event set through ethtool but enables all possible wake-up events before shutting down. I need to polish the patch a bit but it goes in the right direction. Created attachment 14013 [details]
add PCI device shutdown handler
Pierre-Yves, can you try this new patch on top of any recent kernel ?
--
Ueimor
Francois, I tried the patch on the stock Gutsy r8169 module and I got these errors (maybe you're working on a more recent version of the module, but when I used the head version from git I also got errors): py@PC-FIXE2:/usr/src/linux-source-2.6.22$ sudo make modules CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CC [M] drivers/net/r8169.o drivers/net/r8169.c: In function «rtl8169_shutdown": drivers/net/r8169.c:3060: erreur: «struct rtl8169_private" has no member named «features" drivers/net/r8169.c:3060: erreur: «RTL_FEATURE_WOL" undeclared (first use in this function) drivers/net/r8169.c:3060: erreur: (Each undeclared identifier is reported only once drivers/net/r8169.c:3060: erreur: for each function it appears in.) make[2]: *** [drivers/net/r8169.o] Erreur 1 make[1]: *** [drivers/net] Erreur 2 make: *** [drivers] Erreur 2 Thanks a lot PY py.bretecher@free.fr 2007-12-14 11:58: > Francois, I tried the patch on the stock Gutsy r8169 module and I got these > errors (maybe you're working on a more recent version of the module, but > when I used the head version from git I also got errors): Which error did you got ? I am working with 2.6.24-rc/git. Well, to answer your previous question, the errors I get when using the latest version (I'am not very familiar with git) of the source (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/net/r8169.c;hb=HEAD): py@PC-FIXE2:/usr/src/linux-source-2.6.22$ sudo make modules CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CC [M] drivers/net/r8169.o drivers/net/r8169.c:392: erreur: field «napi" has incomplete type drivers/net/r8169.c:1084: erreur: unknown field «get_sset_count" specified in initializer drivers/net/r8169.c:1084: attention : initialization from incompatible pointer type drivers/net/r8169.c: In function «rtl8169_down": drivers/net/r8169.c:2900: attention : implicit declaration of function «napi_disable" make[2]: *** [drivers/net/r8169.o] Erreur 1 make[1]: *** [drivers/net] Erreur 2 make: *** [drivers] Erreur 2 I also spent few minutes examining the errors I got when using your patch with 2.6.22 revision of the module. Adding few lines to the r8169.c solved the compilations errors :
added :
************
enum features {
RTL_FEATURE_WOL = (1 << 0),
};
************
and in the definition of struct rtl8169_private :
************
unsigned features;
************
Then the module compile perfectly and as far I could test it, it doesn't improve the WOL behaviour.
I will do some deeper testing in order to get sure that I'm using the newly compiled module (I consider using some additional printk to insure that my module -your module- is the one that the kernel actually loads)
PY
py.bretecher@free.fr: [...] > py@PC-FIXE2:/usr/src/linux-source-2.6.22$ sudo make modules > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CALL scripts/checksyscalls.sh > CC [M] drivers/net/r8169.o > drivers/net/r8169.c:392: erreur: field py.bretecher@free.fr: > I also spent few minutes examining the errors I got when using your patch > with > 2.6.22 revision of the module. Adding few lines to the r8169.c solved the > compilations errors : [...] > Then the module compile perfectly and as far I could test it, it doesn't > improve the WOL behaviour. 2.6.22 lacks the basic r8169 WOL ethtool support which appeared in later version of the driver/kernel so it is not a surprise. > I will do some deeper testing in order to get sure that I'm using the newly > compiled module (I consider using some additional printk to insure that my > module -your module- is the one that the kernel actually loads) 2.6.22 is a dead way. Do you need help recompiling a newer kernel ? OK, I was completely wrong with 2.6.22, I will try to setup a 2.6.24 test environment and come back here as soon as I have fresh news. PY Hello François, I have had some unexpected troubles to setup the test environment but know I have a partition with the new alpha ubuntu distrib (hardy heron) with 2.6.24 kernel (uname -a : Linux pc-fixe2 2.6.24-1-generic #1 SMP Fri Dec 7 22:06:43 GMT 2007 x86_64 GNU/Linux) I have patched the r8169.c and recompiled modules, regenerated initrd (and verified the the modified module was actually used by the kernel through a syslog message and tested WOL : magic packet WOL is still not working (and again I have checked that the next boot on the XP partition enables the WOL through magic packet). I have only applied the second patch (not the first one). PY py.bretecher@free.fr : [...] > I have only applied the second patch (not the first one). That's fine. Just to be sure: you did enable WOL with ethtool, didn't you ? I just checked that WOL was set to "g" with ethtool : sudo ethtool eth0 [sudo] password for py: Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes I have not explicitely enable WOL but I can try. py.bretecher@free.fr : [...] > I have not explicitely enable WOL but I can try. Please try it (otherwise tp->features & RTL_FEATURE_WOL will be false :o/). I have just tried the following command : ethtool -s eth0 wol g and the shutdown the computer but still no wake up. Is it the right command ? PY I found this kind of warning in the log, if it make sense for you ... py@pc-fixe2:~$ dmesg|grep r8169 [ 30.461846] r8169: no version for "struct_module" found: kernel tainted. [ 31.163669] r8169 Gigabit Ethernet driver 2.2LKPYB2 loaded [ 54.520889] r8169: eth0: link up [ 54.520897] r8169: eth0: link up py.bretecher@free.fr 2007-12-18 15:24 : > I have just tried the following command : > ethtool -s eth0 wol g > > and the shutdown the computer but still no wake up. > > Is it the right command ? Yes. I have reproduced the problem at home but it is even worse: my 8168 does not WOL, be it submitted to link events or WoL packets. A 8169 in the same box works correctly with a stock kernel though. Wonderful. :o/ In my previous attempts, I'm quite sure I could set manually WOL to "p" and wakeup the box on PHY activity (i.e. quite immediately). I will double check this point tonight. I just checked that setting wol to PHY activity works great with my NIC (ethtool -s eth0 wol gp) : if I unplug ethernet cable before shutting down, the box shuts down completely and wakes up as soon as I replug it. My NIC seems to be the same as yours : 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01) Weird... I too have this problem, what is the best way to help fix it? I'm seeing same issue on LE-365 board (VIA CX700M chipset) and: 02:08.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10) I'm trying to trigger WoL when the board is powered-off or in S3 state but no success. (trying ether-wake with and without '-b' option) While testing/debugging S3 I noticed that r8169 does not seem to tell PCI that it can wakeup the system. ... [ 375.126182] pci 0000:80:01.0: suspend [ 375.126236] r8169 0000:02:08.0: suspend [ 375.126300] ACPI handle has no context! [ 375.126330] ACPI handle has no context! [ 375.143695] pci 0000:02:04.0: suspend [ 375.143753] pci 0000:01:00.0: suspend [ 375.143813] pci 0000:00:13.1: suspend [ 375.143856] pci 0000:00:13.0: suspend [ 375.143899] pci 0000:00:11.7: suspend [ 375.143952] pci 0000:00:11.0: suspend ... [ 375.434269] pci 0000:80:01.0: LATE suspend [ 375.434286] r8169 0000:02:08.0: LATE suspend [ 375.434302] pci 0000:02:04.0: LATE suspend ... [ 3.425473] pci 0000:02:04.0: EARLY resume [ 3.425489] r8169 0000:02:08.0: EARLY resume [ 3.425505] pci 0000:80:01.0: EARLY resume ... [ 3.524319] pci 0000:02:04.0: resuming [ 3.524376] r8169 0000:02:08.0: resuming [ 3.543953] pci 0000:80:01.0: resuming I would have expected to see suspend lines like [ 375.126236] r8169 0000:02:08.0: suspend, may wakeup and [ 375.434286] r8169 0000:02:08.0: LATE suspend, may wakeup Looking at the driver code the wakeup ability is only setup in suspend() hook and removed in resume() hook. Wouldn't it make sense to move this to NIC initialization and when changing WoL settings? (this way wakeup ability should show up in sysfs under power/wakup) Note that the switch my board is connected to sees the link as up (with a glitch to down when the board switches to S3). Hi Bruno, interesting findings ! I don't know where or how you could get this log information : could you tell me how check this on my box ? On my side, I have had look to the "acpitool -w" output that seems strange to me : py@pc-fixe2:/var/log$ acpitool -w Device S-state Status Sysfs node --------------------------------------- 1. PCI0 S5 disabled no-bus:pci0000:00 2. PEX0 S5 disabled pci:0000:00:1c.0 3. PEX1 S5 disabled 4. PEX2 S5 disabled 5. PEX3 S5 disabled 6. PEX4 S5 disabled pci:0000:00:1c.4 7. PEX5 S5 disabled pci:0000:00:1c.5 8. HUB0 S5 disabled pci:0000:00:1e.0 9. UAR1 S3 disabled pnp:00:07 10. USB0 S3 disabled pci:0000:00:1d.0 11. USB1 S3 disabled pci:0000:00:1d.1 12. USB2 S3 disabled pci:0000:00:1d.2 13. USB3 S3 disabled 14. US31 S3 disabled pci:0000:00:1a.0 15. USB4 S3 disabled pci:0000:00:1a.1 16. USB5 S3 disabled pci:0000:00:1a.2 17. USBE S3 disabled pci:0000:00:1d.7 18. USE2 S3 disabled pci:0000:00:1a.7 19. AZAL S5 disabled pci:0000:00:1b.0 my NIC is not listed (04:00.0) here. I wondering if this log dosen't tell more or less the same thing that what you've found. (In reply to comment #28) > I don't know where or how you could get this log information : could you > tell me how check this on my box ? I was following Rafael Wysocki's suggestions on debugging suspend to RAM in http://lkml.org/lkml/2008/1/27/292 - using the patches mentionned at the end (should be in 2.6.25 as well) and enabling CONFIG_PM_DEBUG and CONFIG_PM_VERBOSE. > On my side, I have had look to the "acpitool -w" output that seems strange > to me : > py@pc-fixe2:/var/log$ acpitool -w > Device S-state Status Sysfs node > --------------------------------------- > 1. PCI0 S5 disabled no-bus:pci0000:00 > 2. PEX0 S5 disabled pci:0000:00:1c.0 > 3. PEX1 S5 disabled > 4. PEX2 S5 disabled > 5. PEX3 S5 disabled > 6. PEX4 S5 disabled pci:0000:00:1c.4 > 7. PEX5 S5 disabled pci:0000:00:1c.5 > 8. HUB0 S5 disabled pci:0000:00:1e.0 > 9. UAR1 S3 disabled pnp:00:07 > 10. USB0 S3 disabled pci:0000:00:1d.0 > 11. USB1 S3 disabled pci:0000:00:1d.1 > 12. USB2 S3 disabled pci:0000:00:1d.2 > 13. USB3 S3 disabled > 14. US31 S3 disabled pci:0000:00:1a.0 > 15. USB4 S3 disabled pci:0000:00:1a.1 > 16. USB5 S3 disabled pci:0000:00:1a.2 > 17. USBE S3 disabled pci:0000:00:1d.7 > 18. USE2 S3 disabled pci:0000:00:1a.7 > 19. AZAL S5 disabled pci:0000:00:1b.0 > > my NIC is not listed (04:00.0) here. I wondering if this log dosen't tell > more or less the same thing that what you've found. acpitool -w does not list the network chip for me either... (02:08.0): Device S-state Status Sysfs node --------------------------------------- 1. SLPB S5 *enabled 2. PCI0 S5 disabled no-bus:pci0000:00 3. USB1 S3 disabled pci:0000:00:10.0 4. USB2 S3 disabled pci:0000:00:10.1 5. USB3 S3 disabled pci:0000:00:10.2 6. EHCI S3 disabled pci:0000:00:10.4 7. P2PB S5 disabled pci:0000:00:13.1 8. UAR1 S5 disabled pnp:00:07 9. PS2K S5 disabled pnp:00:09 10. AZAC S5 disabled pci:0000:80:01.0 I found out more: I need to toggle the wol state using ethtool AND enable item 7 (PCI2PCI bridge which enables root PCI node) using acpitool to get WoL working. Device S-state Status Sysfs node --------------------------------------- 1. SLPB S5 *enabled 2. PCI0 S5 enabled no-bus:pci0000:00 3. USB1 S3 disabled pci:0000:00:10.0 4. USB2 S3 disabled pci:0000:00:10.1 5. USB3 S3 disabled pci:0000:00:10.2 6. EHCI S3 disabled pci:0000:00:10.4 7. P2PB S5 enabled pci:0000:00:13.1 8. UAR1 S5 disabled pnp:00:07 9. PS2K S5 disabled pnp:00:09 10. AZAC S5 disabled pci:0000:80:01.0 In this case WoL works in S3 (multiple S3 cycles work) or after shutdown. After reboot configuration MUST happen once again as it gets forgotten! (on both ACPI and RTL8169 sides - even though ethtool still shows previous WoL config) A solution possibly would be to do all of the following: - r8169 driver explicitely reconfigures WoL config it read during initialization - r8169 enables ACPI wakeup for all PCI bridges above its card in PCI hierarchy if WoL is enabled PS: forgot to mention in previous post, I'm running vanilla 2.6.24 with Rafael's patches 1-11 (ref in http://lkml.org/lkml/2008/1/27/292 ) and squashfs. I have no P2PB listed in my case. Even enabling all PCI or PEX devices have not improved the WOL behaviour. I will try with the vanilla kernel and your suggested patch. Anyway I think you are very close to the solution. Thanks a lot. PY Pierre-Yves, could you show the output of lspci on your machine so it's possible to map your PCI ACPI devices and heave an idea on the PCI hierarchy? For the record, mine is: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:0324] (rev 03) 00:00.1 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:1324] 00:00.2 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:2324] 00:00.3 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:3324] 00:00.4 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:4324] 00:00.7 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:7324] 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237 PCI Bridge [1106:b198] 00:0f.0 IDE interface [0101]: VIA Technologies, Inc. Unknown device [1106:0581] 00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90) 00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90) 00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 90) 00:10.4 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 90) 00:11.0 ISA bridge [0601]: VIA Technologies, Inc. CX700 PCI to ISA Bridge [1106:8324] 00:11.7 Host bridge [0600]: VIA Technologies, Inc. CX700 Internal Module Bus [1106:324e] 00:13.0 Host bridge [0600]: VIA Technologies, Inc. CX700 Host Bridge [1106:324b] 00:13.1 PCI bridge [0604]: VIA Technologies, Inc. CX700 PCI to PCI Bridge [1106:324a] 01:00.0 VGA compatible controller [0300]: VIA Technologies, Inc. CX700M2 UniChrome PRO II Graphics [1106:3157] (rev 03) 02:04.0 Network controller [0280]: Intersil Corporation ISL3886 [Prism Javelin/Prism Xbow] [1260:3886] (rev 01) 02:08.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10) 80:01.0 Audio device [0403]: VIA Technologies, Inc. VIA High Definition Audio Controller [1106:3288] (rev 10) Hi again, Thanks for your help Here are the lspci output and acpitool output : py@pc-fixe2:~$ lspci 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 02) 00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port (rev 02) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02) 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) 00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) 00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8500 GT (rev a1) 03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02) 03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) 05:06.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) py@pc-fixe2:~$ acpitool -w Device S-state Status Sysfs node --------------------------------------- 1. PCI0 S5 disabled no-bus:pci0000:00 2. PEX0 S5 disabled pci:0000:00:1c.0 3. PEX1 S5 disabled 4. PEX2 S5 disabled 5. PEX3 S5 disabled 6. PEX4 S5 disabled pci:0000:00:1c.4 7. PEX5 S5 disabled pci:0000:00:1c.5 8. HUB0 S5 disabled pci:0000:00:1e.0 9. UAR1 S3 disabled pnp:00:07 10. USB0 S3 disabled pci:0000:00:1d.0 11. USB1 S3 disabled pci:0000:00:1d.1 12. USB2 S3 disabled pci:0000:00:1d.2 13. USB3 S3 disabled 14. US31 S3 disabled pci:0000:00:1a.0 15. USB4 S3 disabled pci:0000:00:1a.1 16. USB5 S3 disabled pci:0000:00:1a.2 17. USBE S3 disabled pci:0000:00:1d.7 18. USE2 S3 disabled pci:0000:00:1a.7 19. AZAL S5 disabled pci:0000:00:1b.0 Pierre-Yves, so according to you comment #31 for you switching 6, 7 and 8 to enabled with acpitool and also cycling your rtl8169's WoL settings does not make WoL succeed? acpitool -W 6 acpitool -W 7 acpitool -W 8 (make sure all 3 are enabled, on my box enabling one eventually enables some other items - and a second call to acpitool -W # disables the item again) ethtool -s eth0 wol d ethtool -s eth0 wol g Then try shutdown or s2ram (beware s2ram may not resume propertly - so unless you know s2ram works, avoid having too much software running) and send the magic packet (e.g. with ether-wake) from local subnet. Don't forget to check wether the PHY is active (switch sees active link) If none works, take a look at your bios in the area of power management, might be there are intresting options regarding PCI or PCI-Express wakeup events Bruno, I have done what you advised to me : py@pc-fixe2:~$ acpitool -w Device S-state Status Sysfs node --------------------------------------- 1. PCI0 S5 enabled no-bus:pci0000:00 2. PEX0 S5 enabled pci:0000:00:1c.0 3. PEX1 S5 enabled 4. PEX2 S5 enabled 5. PEX3 S5 enabled 6. PEX4 S5 enabled pci:0000:00:1c.4 7. PEX5 S5 enabled pci:0000:00:1c.5 8. HUB0 S5 enabled pci:0000:00:1e.0 9. UAR1 S3 disabled pnp:00:07 10. USB0 S3 disabled pci:0000:00:1d.0 11. USB1 S3 disabled pci:0000:00:1d.1 12. USB2 S3 disabled pci:0000:00:1d.2 13. USB3 S3 disabled 14. US31 S3 disabled pci:0000:00:1a.0 15. USB4 S3 disabled pci:0000:00:1a.1 16. USB5 S3 disabled pci:0000:00:1a.2 17. USBE S3 disabled pci:0000:00:1d.7 18. USE2 S3 disabled pci:0000:00:1a.7 19. AZAL S5 disabled pci:0000:00:1b.0 py@pc-fixe2:~$ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes But unfortunately, I could not wake up my PC with magic packet after shutdown. There is not much stuff in the BIOS but these events are enabled. Again, I checked right after that rebooting with XP actually enables WOL. I didn't try the patch from Rafael but I understood it only gives debug information, no kernel or module behaviour modification. Thanks for your help. Created attachment 14775 [details]
multicast register update for the 8168
Pierre-Yves,
the mac address filtering is different between the 8168 and the 8169.
Can you give the attached patch a try on top of the acpi suggestions ?
Thanks in advance.
--
Ueimor
François, I tried the patch on top of the r8169.c from the 2.6.24-7 kernel from ubuntu with no luck. I also tried along with your previous patch : no more luck. Of course I configured the interface through "ethtool -s eth0 wol g" and enabled all PCI devices in acpi as mentioned in previous comment (#35). I checked that the right (new) module was actually loaded and that WOL was working after a shutdown from windows... Thanks for your help. Realtek has released a new revision of the driver in january. The release notes could be of interest (but I'm not sure it is related to our issue): release date: 2008/01/09 driver version: 8.005.00 1. Fix hibernate and cannot wakeup issue. The root cause: In rtl8168_init_board, tp->dev is never assigned. Therefor, it is a NULL pointer and the system crashes when this pointer is accessed. Solution: Assign a vaild memory address to tp->dev. 2. Modify GPHY parameters of RTL8111C 3. Modify GPHY configurations of RTL8111C 4. Create a spin lock to protect GPHY configuration. 5. Implement a kernel timer to rescue the NIC after the PCI reset is triggered. Unfortunately the modules does not compile on my distro (Ubuntu Hardy Heron 2.6.24-11-generic) : py@pc-fixe2:~/r8168-8.005.00$ make modules make -C src/ modules make[1]: entrant dans le répertoire « /home/py/r8168-8.005.00/src » make -C /lib/modules/2.6.24-11-generic/build SUBDIRS=/home/py/r8168-8.005.00/src modules make[2]: entrant dans le répertoire « /usr/src/linux-headers-2.6.24-11-generic » CC [M] /home/py/r8168-8.005.00/src/r8168_n.o /home/py/r8168-8.005.00/src/r8168_n.c: Dans la fonction «rtl8168_init_board» : /home/py/r8168-8.005.00/src/r8168_n.c:2270: erreur: déclaration implicite de la fonction « «SET_MODULE_OWNER» » /home/py/r8168-8.005.00/src/r8168_n.c: Dans la fonction «rtl8168_init_one» : /home/py/r8168-8.005.00/src/r8168_n.c:2570: erreur: «struct net_device» has no member named «poll» /home/py/r8168-8.005.00/src/r8168_n.c:2571: erreur: «struct net_device» has no member named «weight» /home/py/r8168-8.005.00/src/r8168_n.c: Dans la fonction «rtl8168_rx_interrupt» : /home/py/r8168-8.005.00/src/r8168_n.c:3790: erreur: «struct net_device» has no member named «quota» /home/py/r8168-8.005.00/src/r8168_n.c:3790: attention : type defaults to «int» in declaration of «_y» /home/py/r8168-8.005.00/src/r8168_n.c:3790: erreur: «struct net_device» has no member named «quota» /home/py/r8168-8.005.00/src/r8168_n.c:3790: attention : il manque un transtypage pour comparer des types distincts de pointeur /home/py/r8168-8.005.00/src/r8168_n.c: Dans la fonction «rtl8168_interrupt» : /home/py/r8168-8.005.00/src/r8168_n.c:3986: erreur: trop peu d'arguments pour la fonction «netif_rx_schedule_prep» /home/py/r8168-8.005.00/src/r8168_n.c:3987: erreur: trop peu d'arguments pour la fonction «__netif_rx_schedule» /home/py/r8168-8.005.00/src/r8168_n.c: Dans la fonction «rtl8168_poll» : /home/py/r8168-8.005.00/src/r8168_n.c:4035: erreur: «struct net_device» has no member named «quota» /home/py/r8168-8.005.00/src/r8168_n.c:4035: attention : type defaults to «int» in declaration of «_y» /home/py/r8168-8.005.00/src/r8168_n.c:4035: erreur: «struct net_device» has no member named «quota» /home/py/r8168-8.005.00/src/r8168_n.c:4043: erreur: «struct net_device» has no member named «quota» /home/py/r8168-8.005.00/src/r8168_n.c:4046: erreur: trop peu d'arguments pour la fonction «netif_rx_complete» make[3]: *** [/home/py/r8168-8.005.00/src/r8168_n.o] Erreur 1 make[2]: *** [_module_/home/py/r8168-8.005.00/src] Erreur 2 make[2]: quittant le répertoire « /usr/src/linux-headers-2.6.24-11-generic » make[1]: *** [modules] Erreur 2 make[1]: quittant le répertoire « /home/py/r8168-8.005.00/src » make: *** [modules] Erreur 2 py@pc-fixe2:~/r8168-8.005.00$ I guess I have to set up an environment with an older kernel in order to compile and test this module. But if someone can advise me how to get this module compile in my current env ... PY Someone on the Ubuntu forum discovered that if you avoid bringing down the network interface when you shutdown, then WOL works perfectly. I have confirmed this. For Ubuntu, he suggested removing the -i option from the halt and reboot commands in the appropriate scripts that are called on shutdown For Fedora, if I edit /etc/rc5.d/S10network so that ifdown is not called on eth0 (the r8169 device on my P35 motherboard), then WOL works for me. So, it seems that there's a bug in the part of the driver that is called when the interface is brought down that is either wiping out the WOL setting or somehow resetting the device such that the WOL functionality gets disabled. Hope this helps you figure out what is wrong with the driver. Thanks for your suggestion. As I wrote in my very first post, I tried to remove the -i option of the halt command in the /etc/init.d/halt script. At the time of this first post, it did not work. I've just retried and ... no luck. Since you seem to have the same hardware config that me and that your Fedora can make WOL works provided some tweak in the networking script, I will try modify some scripts (searching for ifdown commands, try to comment it and have some tests). Thanks again PY Matthew, does your motherboard include a 8169 or a 8168 ? -- Ueimor lspci shows that I have: 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) My motherboard is Gigabyte GA-P35-DS3R Rev. 2.0 and I'm running a 2.6.24.3 x86_64 kernel. I've shutdown several times over a period of a couple days now, and WOL still works well. PY--you've probably checked this, but you aren't using any kind of network manager application that would be bringing your interface up or down? I know Fedora has something like that. Matthew, you're right, I'm using Network Manager. As far as I remember I tried to disabled NM but I'm not sure. So I will try to disable it before shutting down. Yeeess, congratulations Matthew. I can wake my PC if I disable NM (and manually reconfigure /etc/network/interfaces which is rather empty since ubuntu completely rely on NM). I will try to verify on my box that it is precisely the ifdown that disable WOL. Thank you ! OK, here is a small summary of what is needed (workaround only) to make my GA-P35-DS3P waking on LAN magic packet with ubuntu Hardy Heron (x86/64) : Before shutting down, edit /etc/init.d/halt and remove the "-i" option from halt command at the end of the script and kill NetworkManager processes. I did not need to patch the regular driver r8169. It seems that "ifdown" breaks WOL configuration. OK, some more information. First, the Ubuntu bug for this: https://bugs.launchpad.net/linux/+bug/160413 oops, didn't mean to send the above comment as is. Sorry. First, the bug log is quite long. Has someone managed to get WOL working *without* modifying the shutdown scripts to leave the interface up, as I suggested in the Ubuntu bug log? Re-reading the bug log, it seems that Pierre-Yves and Matthew solved it by leaving the interface up. Also, Bruno, can you confirm that it works even if the interface is down during shutdown? My current testing shows that with either patch #13898 or #14013, running "ifconfig eth0 down" blocks (ifconfig is left in D state). Has someone else seen the same behaviour? I'm using a 8168, but patch #14775 doesn't change anything to this problem. (the unpatched driver works fine) Lucas, for now running 2.6.25-rc9 I can't get the box to WoL after shutdown (independently of eth0 state at power-off or acpitool/ethtool configuration attempts) It works fine from S3/Suspend to RAM tough. When I get time I will check with 2.6.25 release (I don't expect any difference for that one) and a few older releases ( up to 2.6.22 if http://lkml.org/lkml/2008/4/20/67 has an influence here ) PS: Lucas, what kernel version are you using? 2.6.24. I haven't tried with 2.6.25 yet, but I don't expect any change. Should I? (In reply to comment #49) > 2.6.24. I haven't tried with 2.6.25 yet, but I don't expect any change. > Should I? No idea, but I guess there is more than just the r8168 driver involved in here (PM and ACPI are certainly responsible for some part). Might be insightful to compare with other network chips' ability to do WoL on Linux (S3, S4 and S5) and possible improvements/regressions they experienced over kernel releases. For me it looks like 2.6.25 got worse in regard to WoL from shutdown as there was a work-around for 2.6.24 which doesn't work for 2.6.25. I built/installed the stock 2.6.25 a few days ago and WOL still works fine for me, as long as I don't use NetworkManager, make sure ifdown is never called (including in shutdown scripts), and don't use the -i flag when halt is called. I should also mention that I do a /sbin/ethtool -s eth0 wol g on startup a while after the device is brought up. To further my last comment, I just tested my system and the last bit (calling /sbin/ethtool -s eth0 wol g) is not even necessary. It seems like the only constraint in my case is that I make sure nothing in the system brings down the interface at any point. I have just tested the new r8168-8.008.00 module from Realtek (now compatible with 2.6.24) and WOL doesn't work as long as NetworkManager is used (I tested that if NM is removed WOL just works normally). So, the issue still remains. Do you experience the same with 2.6.27-rc6 + http://www.kernel.org/~romieu/r8169/2.6.27-rc6/20080913-r8169-test.patch ? -- Ueimor Hi Francois, I used linus' git tree, not 2.6.27-rc6, but that's unlikely to make a difference. linus's git tree: - shutdown without shutting down interfaces: WOL works - shutdown with shutting down intefaces: WOL doesn't work linus's git tree + your patch: - shutdown without shutting down interfaces: WOL doesn't work anymore - shutdown with shutting down intefaces: WOL still doesn't work For me WOL seems to work pretty well with 2.6.27-rc6. Now WOL works in the following scenarios: - S3 - suspend to ram - S5 - shutdown - S5 - shutdown with power disconnected What I'm doing on system startup: ethtool -s eth0 wol d > /dev/null && \ ethtool -s eth0 wol g > /dev/null acpitool -w | grep 'P2PB.*enabled' > /dev/null || \ acpitool -W 7 > /dev/null echo enabled > "/sys/bus/pci/devices/0000:02:08.0/power/wakeup" PS: see comments 30 and 32 for my hardware Tomorrow or this week-end I will check which of those I may omit to keep WOL working on the above scenarios. The last step (echo enabled > /sys/...) is new since 2.6.27 and might be alone it's sufficient. If that's the case, it would be nice if the driver could do this by itself when WOL is active > The last step (echo enabled > /sys/...) is new since 2.6.27 and might be > alone > it's sufficient. If that's the case, it would be nice if the driver could do > this by itself when WOL is active I do need all of the 3 steps to get WOL from S5 (or S5 with intermittent power loss) and S3... Note: this is all without the patch from comment #54 Bruno: which distribution are you using? is it possible that it sets the interface UP before shutdown? Also, Bruno, can you try the patch from comment #54? For me, it makes things worse. Lucas: - patch from comment #54 makes no visible change for me - distro is Gentoo, just before powering down eth0 is DOWN (checked with ip link list && sleep just before powering down) With patch (not done as in-depth checks without the patch): - ethtool -s eth0 wol d && ethtool -s eth0 wol g Required to get WoL working without pulling the plug - acpitool Required in all cases - enabled > /sys/.../power/wakeup Required to get WoL working without pulling the plug So for S3 I need all of them, for S5 (power-down) I also need all of them unless I pull the plug before attempting WoL. The most annoying part is the ethtool hack: I need to disable and re-enable WoL for it to work! The wakeup part should be done by driver automatically if WoL is enabled The acpi part is possibly more tricky... don't know how easy/difficult it's to automatically find out what exactly has to be selected there... @Bruno: are you 100% sure that you are using the patched driver? (have you changed the version string to make sure that you load the correct driver?) If you use an initrd, you need to change the driver in it too (I ran into this). (In reply to comment #60) > @Bruno: are you 100% sure that you are using the patched driver? (have you > changed the version string to make sure that you load the correct driver?) > If you use an initrd, you need to change the driver in it too (I ran into > this). I'm not using an initrd and the driver is built-in. I'm pretty sure I didn't forget to copy the built kernel image and rerun lilo before rebooting. Anyhow, I've just sent 2 patches which make 2 out of the 3 manual steps obsolete and hopefully would make WoL work not only for me. The patches are at: http://kerneltrap.org/mailarchive/linux-netdev/2008/10/4/3508494 http://kerneltrap.org/mailarchive/linux-netdev/2008/10/4/3508504 http://kerneltrap.org/mailarchive/linux-netdev/2008/10/4/3508484 Maybe the shutdown handler in François Romieu's series will fill the missing part for shutdown I mention in the email... Hi Bruno, Could you mention it on the bug log when the patches will have been merged in a git tree I can pull from? Thank you, Hi all, first post here :) Lucas, it is my understanding that the above mentioned fixes are in 2.6.27-git2, see http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.27-git2.log and search for "r8169: WoL fixes". Second, reading that some people have it working with some manual changes I did try to follow those to make it work but did not manage. Is there a how-to for the manual changes somewhere else while this is being resolved? I tried to follow this thread but still can't get it to work in Kubuntu 8.04 amd64. If some clear steps where around it would be easier to say wheter I screwed up or my machine needs some additional steps. I'm on an Abit AB9 Pro for which WOL works from Windows (S3) but not after power-down (from S5). Is this a problem from the Linux perspective? After some upgrades, I can confirm that using Kubuntu Intrepid beta (kernel is 2.6.27-7-generic) I can wake up my system if I manually use ethtool, acpitool and echo "enabled" to wakeup for my NIC under /sys/bus/... and then call a modified halt command. Since I can wake up from S5 after halting linux, but I can't wake my computer after I pulled the cord and re-aattached it again, I'm guessing my BIOS is no good? Now I know that I'm doing something right so I will try the new patches again. However, I have had no such luck with waking from S3 though. I use "pmi action suspend" to put my box to sleep. Does anyone know how to tell the pmi command not to bring interfaces down? Is there a better command altogether? Bruno, what command do you use to put your box into S3? I do S3 from the basics: echo mem > /sys/power/state Note that this requires that your system is capable of resuming the graphics without hacks (e.g. that you have Intel graphics for which the i915 DRI drivers can resume the card or that your BIOS is capable of resuming the graphics - if this is not the case you system might still resume but without graphics so you have to interact with it via ssh or serial console if possible) Regarding disconnecting power-cable after power-down, there might be an option in BIOS config to enable/disable WoL (here touching the ACPI rule seems to be sufficient) Regarding NIC shutdown hook and my WoL fixes, they are now in Linus's tree (after 2.6.27). All what is remaining to do manually after these is acpitool. Thanks Bruno! I tried the echo mem thing but I'm not able to wake the box by LAN after that (wakening by power button works but my graphics can't handle it, checked by ssh login). So I'm still not able to resume from S3 by LAN (however as said before, it works after issuing the halt command). Gonna try and build new kernel that includes Bruno's patches. it still doesn't work for me, with 2.6.28-rc6. I'm trying to use wol after shutdown on a desktop, without pulling the plug. My NIC is: 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) My /etc/rc.local contains: ethtool -s eth0 wol d ethtool -s eth0 wol g while [ $(acpitool -w | grep "disabled" | wc -l) -ne 0 ]; do acpitool -W $(acpitool -w | grep disabled | head -1 | cut -d '.' -f 1) done echo enabled > /sys/bus/pci/devices/0000\:02\:00.0/power/wakeup (following instructions from Bruno) I can't wake up the system using WOL while it works with 2.6.24. I was using Ubuntu server with kernel 2.6.24 and WoL works, now with kernel 2.6.27 it doesn't work. Using "echo enabled > /sys/..." works for me. My netcard is an Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 0c), so e100 driver might be patched too... Thanks for your support. ;) I recently re-installed with Ubuntu server 8.10 amd64 on my Abit AB9 Pro and after I updated to kernel 2.6.27-9-server (I am assuming this is patch 9 from the Ubuntu-gang but still 2.26.7 as far as kernel.org is concerned). If I do: ethtool -s eth0 wol d && ethtool -s eth0 wol g acpitool -W 4 echo enabled > "/sys/bus/pci/devices/0000:03:00.0/power/wakeup" and modify the shutdown script to effectively remove the -i going to halt (as well as rename /sbin/ifdown just to be on the safe side) I can wake from S5 but not from S3 by magic packet as I stated before (I get to S3 by issuing "pm-suspend" or the "echo mem > /sys/power/state" and can wake by power button). What I find interesting is that if I modify the ethtool call to: ethtool -s eth0 wol d && ethtool -s eth0 wol gp i.e. let it wake on phy-activity, my box instantly wakes from sleep. To me this sounds like the problem with waking from S3 has to do with the reception of magic packets. lspci reports my eth0 as "Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)". Has anyone using a RTL8111/8168B (rev 01) been able to wake their box from S3 by magic packet? If so, what linux distro, kernel version and patches did you / are you using?? Comment on my previous post: Ubuntu server does not use "Network manager". Just updated to kernel 2.26.8-rc9 which includes a lot of fixes for the r8169 driver (see e.g. http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.28-rc1 etc). It also seems to include Bruno's two patches from post #61 above. This new kernel breaks my ability to wake from S5 after "shutdown -h now" (/sbin/ifdown still renamed). Since I was uncertain as to wheter any changes outside of r8169.c might have part in breaking my WOL from S5, I moved back to my Ubuntu-supplied kernel source for 2.6.27 (called 2.6.27.2) which allows me to wake from S5 and copied the r8169.c file from 2.6.28-rc9 over the one from the 2.6.27.2 kernel source. I rebuilt the r8169 kernel-module (in the 2.6.27.2 kernel tree), copied to /lib/modules/... and ran "update-initramfs" for my kernel (2.6.27.2). Sure enough WOL from S5 was broken! In 2.26.8-rc9 the r8169 kernel module among other things have a new shutdown handler. I did comment that out in "static struct pci_driver rtl8169_pci_driver" at the very end of the module code, recompiled the module, copied to /lib/modules and updated my initramfs. This time WOL from S5 worked again! And also without any of the three: ethtool -s eth0 wol d && ethtool -s eth0 wol g acpitool -W 4 echo enabled > "/sys/bus/pci/devices/0000:03:00.0/power/wakeup" mentioned above. :) Anyway, all the shutdown handler does is call "rtl8169_suspend(pdev, PMSG_SUSPEND);" which is the same function which is set as the suspend handler. It now seems to me that there is something wrong in the suspend handler that makes my 8168 stop listening for magic packets. I will continue to investigate, but this is the first time ever I look at any kernel-related code so it is slow... Also, I don't know what the usual way of handling these bugs is, but it seems to me that we should update version information in the bugs header to indicate that it is still present in later versions of the kernel???? Fredrik, so WoL for "any phy activity" works but not for magic packet? (in S3 or S5 with NIC being turned off) By the way, what PCI-ids are reported for your card and what version does the driver report when probing it (dmesg)? Two random guesses: - either the bit set for magic packet is inappropriate - or maybe it could be that the NIC's MAC address is not properly configured for the WoL to work (if I remember well there were some MAC address issues recently for some NICs handled by the r8169 driver), maybe you would want to look into this direction. For the S5 wake-up which only seems to work whenever the NIC is left UP be the kernel during shutdown this could be related to MAC guess above. How does it behave after pulling power plug while in S5 state? Success! I managed to get it working for both S5 and S3 some hours ago. :)
My "fix" was to comment out the following four lines in rtl8169_suspend():
spin_lock_irq(&tp->lock);
rtl8169_asic_down(ioaddr);
rtl8169_rx_missed(dev, ioaddr);
spin_unlock_irq(&tp->lock);
Also, I commented out setting a shutdown handler.
This is probably not the best fix ever but I am quite satisfied as I can now go to S5 (shutdown -h now) and also S3 (pm-suspend) and wake from both those states multiple times without any side effect as far as I can tell.
Anyway to answer some of Bruno's questions:
Yes, before this "fix" WoL for "any phy activity" worked but not for magic packet.
In dmesg I find the following on my network cards (the AB9 Pro has two):
[ 12.671231] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 12.671247] r8169 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 12.671272] r8169 0000:03:00.0: setting latency timer to 64
[ 12.671298] r8169: mac_version = 0x0c
[ 12.671616] eth0: RTL8168b/8111b at 0xffffc20000c34000, 00:50:8d:95:27:6a, XID 38000000 IRQ 2298
[ 12.671619] r8169: mac_version = 0x0c
[ 12.673028] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 12.673042] r8169 0000:04:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 12.673054] r8169 0000:04:00.0: setting latency timer to 64
[ 12.673078] r8169: mac_version = 0x0c
[ 12.673385] eth1: RTL8168b/8111b at 0xffffc20000c36000, 00:50:8d:95:27:6b, XID 38000000 IRQ 2297
[ 12.673387] r8169: mac_version = 0x0c
lspci gives me:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
lspci -n give me:
03:00.0 0200: 10ec:8168 (rev 01)
04:00.0 0200: 10ec:8168 (rev 01)
Bruno, with this information, do you still believe it to be related to the MAC address not being properly configured??
Shutting down the box and then pulling and re-attaching the power cord leaves it unresponsive to WOL magic packets I'm afraid.
I would gladly see this bug through to a more solid fix. At least it now seems that the issue has been narrowed down quite a bit, am I right?
As I mentioned I am kind of new to this so any suggestions would be appreciated.
(In reply to comment #72) > Success! I managed to get it working for both S5 and S3 some hours ago. :) > > My "fix" was to comment out the following four lines in rtl8169_suspend(): > > spin_lock_irq(&tp->lock); > > rtl8169_asic_down(ioaddr); > > rtl8169_rx_missed(dev, ioaddr); > > spin_unlock_irq(&tp->lock); > > Also, I commented out setting a shutdown handler. I think that you could keep the shutdown handler with the above lines commented out... What you basically do is disable what stops the network operation (I assume you would lose a few packets this way and eventually disturb the suspend process in case you are still receiving lots of traffic) For details HW doc is needed, e.g. what does ChipCmd 0x0 exactly mean > Bruno, with this information, do you still believe it to be related to the > MAC > address not being properly configured?? To be checked what NICs were affected (or maybe still partially are), François should know best. But your results don't rule it out. > Shutting down the box and then pulling and re-attaching the power cord leaves > it unresponsive to WOL magic packets I'm afraid. For me the acpitool did the task on this point, you may want to check your BIOS settings as well (how much of WoL it allows). (In reply to comment #72) > Success! I managed to get it working for both S5 and S3 some hours ago. :) > > My "fix" was to comment out the following four lines in rtl8169_suspend(): > > spin_lock_irq(&tp->lock); > > rtl8169_asic_down(ioaddr); > > rtl8169_rx_missed(dev, ioaddr); > > spin_unlock_irq(&tp->lock); > > Also, I commented out setting a shutdown handler. FWIW, I was seeing the exact same issues as you did (that is, WOL working with S5 but not S3/S4). This was on a M2A-VM, the realtek chip is (lspci -n) 02:00.0 0200: 10ec:8168 (rev 01), tinkering with /proc/acpi/wakeup or that /sys/bus/pci/devices/ entry did not help. Though for S5 I also needed to make sure NetworkManager isn't used for this connection as that would always result in the connection being terminated prior to shutdown, no matter the halt or reboot parameters... I modified this patch and simply replaced the rtl8169_asic_down function call with a call to rtl8169_irq_mask_and_ack in rtl8169_suspend - looks to me like the 0x0 ChipCmd is the culprit (I was using the ubuntu 8.10 kernel sources for this, which is some 2.6.27 version). Hallo,
after upgrading from 2.6.26.3 to 2.6.28 (vanilla on debian/testing) I got the same problem (2.6.26.3 works fine but 2.6.28 doesn't work).
My system is
x86_64
lspci
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
ethtool
Supports Wake-on: pumbg
Wake-on: g
lsmod
r8169 36740 0
mii 5568 1 r8169
The NIC ist onboard (Alive-SATA2 GLAN)
with regards
workaround: cp /usr/src/linux-2.6.26.3/drivers/net/r8169*.c /usr/src/linux/drivers/net/ rm /usr/src/linux/drivers/net/r8169*.o rm /usr/src/linux/drivers/net/r8169*.ko cd /usr/src/linux make cp drivers/net/r8169.ko /lib/modules/2.6.28/kernel/drivers/net/r8169.ko After next reboot with kernel 2.6.28 WOL works fine too. Same problem here, WoL from S5 with 2.6.26 worked for my Gigabye P35 DS3, .28 and .29.1 did not. My distribution(gentoo) has a switch to not bring down eths completely to make WoL work, which i've always enabled. I tried to make .29.1 work with acpitool, enabling wake for all bridges in my system, but that did not help. I finally commented out rtl8169_asic_down(ioaddr);, and it works again.. Any news on this one? We have still people affected by this downstream with kernel-2.6.29 Thanks Using the latest Realtek kernel module (r8168-8.012.00), it works with Ubuntu Jaunty distrib (2.6.28-12-generic) without making any other tweak (removing Network Manager, modifing halt script, ...). But I think that ubuntu has some patches in its kernels, on the other hand, some mandriva users have reported downstream that this still fails with vanilla kernel (called "kernel-linus" in mandriva): https://qa.mandriva.com/show_bug.cgi?id=41782#c10 Hello... that "some mandriva user" was me ... I tried the following scenario to avoid any confusions with initscripts or network managers etc. Testing scenario: ----------------- 1.) interface configured and working (tested with ping) 2.) poweroff -f entered Results: -------- 2.6.29.3-desktop-1mnb (Mandriva 2010.0 Cooker) ... can't wake up :( 2.6.29.2-1mdv [kernel-linus] (Mandriva 2009.1) ... can't wake up :( 2.6.29.1-desktop-4mnb (Mandriva 2009.1) ... cant't wake up :( 2.6.28.5-pmagic (Parted Magic) ... cant't wake up :( 2.6.27.19-desktop-1mnb (Mandriva 2009.0) ... WOL works! :) 2.6.24.4-desktop586-1mnb (Mandriva 2008.1 Live) ... WOL works! :) 2.6.24-gentoo-r5 (Gentoo 2008 beta2 minimal CD) ... WOL works! :) It looks like a new bug or principial change causing this unwanted behavior was introduced in 2.6.28.x Regards, Jaromir. 2.6.30-desktop-0.rc7.1mnb (Mandriva 2010.0 Cooker) ... can't wake up :( 2.6.30-0.rc7.2mdv [kernel-linus] (Mandriva 2010.0 Cooker) ... can't wake up I tested two rtl816x-based cards on the same computer and the behavior is different: ------------------------------------------------------------------------------------- Motherboard : GigaByte P35-DS3R 1.) Onboard PCIE card -Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) -WOL doesn't work since kernel 2.6.28 2.) PCI card -Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) -WOL works According to comments #72,#77 From Fredrik Viksten and Mike i commented out the body of the following function in r8169.c and WOL works again :D static void rtl8169_asic_down(void __iomem *ioaddr) { /* RTL_W8(ChipCmd, 0x00); rtl8169_irq_mask_and_ack(ioaddr); RTL_R16(CPlusCmd);*/ } Great work guys! As asic_down is called to bring the interface down, it's really better to comment it just in the rtl_shutdown function...i've made couple of tests and it really looks like it has no impact on anything else but the WOL ...
static void rtl_shutdown(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
struct rtl8169_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->mmio_addr;
rtl8169_net_suspend(dev);
spin_lock_irq(&tp->lock);
// rtl8169_asic_down(ioaddr);
spin_unlock_irq(&tp->lock);
if (system_state == SYSTEM_POWER_OFF) {
pci_wake_from_d3(pdev, true);
pci_set_power_state(pdev, PCI_D3hot);
}
}
(In reply to comment #85) Hallo, this patch works fine for me with vanilla-kernel 2.6.30.1. with regards Andreas Matthus Hi all! Does anyone have a list of parameters that are possible to send to the kernel boot that affects the r8169 module?? Is it possible to send similar parameters to the module via the command line and modprobe? This would simplify my experimentation so it would be greatly appreciated! /Fredrik Hello everybody .... So .... since it takes too long to get this fixed I tried to search in the RTL8168 datasheet .... r8169.c contains the following ... >static void rtl8169_asic_down(void __iomem *ioaddr) >{ > RTL_W8(ChipCmd, 0x00); > rtl8169_irq_mask_and_ack(ioaddr); > RTL_R16(CPlusCmd); >} ChipCmd = 0x37 ============================================= rtl8168 datasheet contains the following .... Command register - offset 0037h --------------------------------- >bit 7-5 : -, - Reserved >bit 4 : RST, rw Reset:Set this bit to 1 to force the RTL811B into a software reset state which disables the transmitter and receiver, reinitializes the FIFOs, and resets the system buffer pointer to the initial value (the start address of each descriptor group set in TNPDS, THPDS, and RDSAR registers). The values of IDR0-5, MAR0-7 and PCI configuration space will have no changes. This bit is 1 during the reset operation, and is self-cleared to 0 when the reset operation is complete. >bit 3 : RE, rw Receiver Enable >bit 2 : TE, rw Transmitter Enable >bit 1-0 : -, - Reserved ----------- Therefore it looks like it simply disables the receiver, therefore the wake-up packets are ignored ... Regards, Jaromir. Btw. my last comment means, that skipping the asic_down in the shutdown and suspend procedure could be considered as a FINAL SOLUTION .... And as it is sometimes hard to convince the kernel guys to apply any of the suggested solutions, we need somebody to pray for this change :D Francois, please, merge this change and everybody will celebrate Your goodness :) Regards, Jaromir. P.S. : As the asic down is called in order to "ifdown" the interface (and that won't change), the usage of variables like NETDOWN=yes or skipping the ifdown scripts and setting the halt arguments in halt initscript without the "-i" parameter is still needed ... but that could be considered as a configuration change, not a kernel bug ... Sorry for the confusion .... i was looking at the old kernel source. In 2.6.31 kernel the asic_down is not called from the rtl8169_suspend function anymore... therefore there could be just one change in the rtl8169_shutdown procedure. I guess the spin_lock / spin_unlock is called because of the asic_down and could be omitted too .... Regards, Jaromir. Jaromír Cápík :
[...]
> Btw. my last comment means, that skipping the asic_down in the shutdown and
> suspend procedure could be considered as a FINAL SOLUTION ....
I may sound like a sucker but skipping asic_down() means that the dev->close()
handler will simply release the rx / tx rings (and their associated memory
buffers) and keep the Rx DMA engine of the card running. It is not a solution.
Can you give the attached patch a try against 2.6.31-rc ?
Thanks in advance.
--
Ueimor
Created attachment 22366 [details]
Bring the device down more gently
Hi Francois. I understand .... the question is if it could have any negative impact on anything. The second question is, if the chip design allows to do the wol compatible shutdown better :D It would be neither first, nor the last "strange" HW design I've seen. But anyway ... it works and it's cheap :D The third question is ... how is it done in the M$ driver? Off course I am gonna try Your patch and let You know. I see there was a lot of changes made in the driver "recently" and I think it really needed to be reorganized :) Thanks a lot. Regards, Jaromir. Hi again ... Bad news ... The patch does not work properly ... The wakeup works, but as You have changed the rtl8169_down function, the card does not go up after previously called ifdown ... Regards, Jaromir. Created attachment 22380 [details]
Bring the device down more gently
(In reply to comment #95) [...] > The wakeup works, but as You have changed the rtl8169_down function, the card > does not go up after previously called ifdown ... What about this one ? -- Ueimor Hi Ueimor. Still the same result. if i enter the following: ifconfig eth0 down ifconfig eth0 up and assign the IP addres again, I cannot ping anything .... Looks like the asic_down is missing in the rtl8169_down function.... ... I see there is some loop checking the state and also some rtl8169_rx_clear that could depend on the command register, but I will have to read the docs to get familiar with that ... At the moment I have no problems with tuning the initscripts to let the interface up ... the most problematic section is the rtl_shutdown function that can't be solved with configuration changes .... Regards, Jaromir. Created attachment 22432 [details]
r8169-wol.patch - enables the receiver in the rtl_shutdown
static void rtl_shutdown(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
struct rtl8169_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->mmio_addr;
rtl8169_net_suspend(dev);
spin_lock_irq(&tp->lock);
rtl8169_asic_down(ioaddr);
spin_unlock_irq(&tp->lock);
if (system_state == SYSTEM_POWER_OFF) {
/* enable receiver to accept WOL */
RTL_W8(ChipCmd, 1<<3);
pci_wake_from_d3(pdev, true);
pci_set_power_state(pdev, PCI_D3hot);
}
}
Hi Ueimor. This patch should solve the problem ... it's an opposite approach ... it just enables the receiver at the end of the rtl_shutdown function, therefore it doesn't matter what the previous state is ... you could call ifdown and whatever .... simply without tuning the initscripts. I tested all possible scenarios and it seems to work without problems. Please, have a look at that and decide ... Have a nice day, Jaromir. Created attachment 22433 [details]
Reset the chipset before going down
Jaromir,
I am not sure why it makes a difference for Wol to
reset the chipset before going down but it should be
a safe thing to do anyway.
Can you check the attachment against plain 2.6.30-rc
and add a signed-off-by if it is ok with you ?
The patch is almost identical to yours: rtl8169_hw_reset()
will force a commit of the register write.
Thanks.
--
Ueimor
Hello Ueimor. Actually, I got the same idea 2 days ago, but then I got on my mind the following question: What happens with the WOL and Speed/Duplex settings when You reset the chip? How could the card process the packets, when the peer doesn't support autonegotiation and has a fixed speed? When the chip-reset changes the WOL reaction from the one tuned via the ethtool to some default, it's not the expected behavior anymore. Anyway, I've already tried that and it doesn't work (computer doesn't wake up). Therefore I think the chip-reset is unwanted, because we need to let the card in the same state it was before the shutdown ... because we know for sure it's correctly set up to accept packets and to be waken by the configured wol packets only. At the moment I don't know if a better solution than re-enabling the receiver exists, but unfortunately it's the only working solution we currently have. I am always willing to test new patches if You have any. Thanks and have a nice day. Regards, Jaromir. Jaromír Cápík <tavvva@volny.cz> : [...] > Actually, I got the same idea 2 days ago, > but then I got on my mind the following question: > What happens with the WOL and Speed/Duplex > settings when You reset the chip? Yeah, yeah, I confused 1 << 3 and CmdReset. Call me an idiot. I have read again the whole thread. Slowly. The reports show that the receiver needs to be enabled for some devices (especially amongst the 8168) to be able to WoL. You are completely right on that point. I'll take care of it. Please wait until tomorrow so that I add a Rx stop descriptor to prevent any corruption due to Rx DMA: afaik nothing ensures that RDSAR is correctly set when the receiver is enabled again in rtl_shutdown (especially if the device is down before rtl_shutdown is called). As a last question, is it right to assume that: 1. you can not WoL your 8168 if it is ifconfiged down before being suspended (i.e. whatever the shutdown path, it is not used) 2. the 8169 does not care Thanks for your patient testing. Hi there :D Actually, I haven't tested the suspend, because I have no swap / no resume partition configured ... I will try to use a regular file or create the partition and let You know ..... but I suppose I won't be able to wake my computer up after the ifdown+suspend ... And ... YES ... I was really thinking about the following changes several times :) why 2.6.30.1 contains : >static struct pci_driver rtl8169_pci_driver = { > .name = MODULENAME, > .id_table = rtl8169_pci_tbl, > .probe = rtl8169_init_one, > .remove = __devexit_p(rtl8169_remove_one), >#ifdef CONFIG_PM > .suspend = rtl8169_suspend, > .resume = rtl8169_resume, > .shutdown = rtl_shutdown, >#endif >}; (and the suspend was called from the rtl_shutdown ...) and 2.6.31.rc3 contains just : >static struct pci_driver rtl8169_pci_driver = { > .name = MODULENAME, > .id_table = rtl8169_pci_tbl, > .probe = rtl8169_init_one, > .remove = __devexit_p(rtl8169_remove_one), > .shutdown = rtl_shutdown, > .driver.pm = RTL8169_PM_OPS, >}; (and there's no suspend defined here... ) ? I suppose You know why :) BR, J. Created attachment 22477 [details]
Enable Rx when WoL is required
Jaromír Cápík <tavvva@volny.cz> : [...] > (and there's no suspend defined here... ) ? It waits behind RTL8169_PM_OPS. Can you test the updated patch and check if it is ok with your setup ? It should be rather safe wrt to DMA at random places. Testing with suspend / resume would be a bonus but it is not strictly needed yet :o) Thanks. Hi Ueimor. Yep. Shutdown+Wakeup works :) Ok ... I will wait with the suspend test till it is needed. Thanks. Regards, Jaromir. (In reply to comment #106) [...] > Yep. Shutdown+Wakeup works :) The patch is included in mainline as ca52efd5490f97f396d3c5863ba714624f272033. I'll close the bug when 2.6.30 is out if nobody complains until then. -- Ueimor Jaromir, can you attach your .config, a complete dmesg from boot and a lspci -vv / -t for future reference ? Thanks. -- Ueimor Hello Ueimor. I had an injury, thus sorry for the delay. I just installed 2.6.31-rc6 from the Mandriva repository and WOL works. I always take the .config files from the distribution kernels. I'm gonna attach the .config file I used for my tests and also my current one. Regards, Jaromir. Created attachment 22753 [details]
.config used for testing
Created attachment 22754 [details]
.config of my current kernel
Created attachment 22755 [details]
dmesg
Created attachment 22756 [details]
lspci -vv
Created attachment 22757 [details]
lspci -t
Hallo, WOL works fine with 2.6.31 thank you Andreas Matthus |