Bug 9512

Summary: Wake on LAN (WOL) not working with r8169 driver
Product: Drivers Reporter: Pierre-Yves Bretécher (py.bretecher)
Component: NetworkAssignee: 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)
Distribution:ubuntu Gutsy AMD64
Hardware Environment:Gigabyte A P35-DSP3 Motherboard
Software Environment:
Problem Description:
I Cannot make WOL (Wake on LAN) work with r8169 driver (Gigabyte A P35-DSP3 Motherboard under Gutsy AMD64).
Since I'am slightly game addicted I have a second partition with Windows XP and I can tell that after shutting down from XP WOL is working OK (WOL from my DD-WRT router).
After shutting down from Gutsy there is no way to wake up my PC.
I have tried many things as suggested in different forums :
- adding startup scripts to enable WOL through the "ethtool -s eth0 wol g" command (command is executed without any error and 'ethtool eth0' returns consistent WOL flags)
- removing '-i' option on the 'halt' command from the /etc/init.d/halt script
- using the Realtek official driver ( r8168 ) in place of the Gutsy provided r8169
- forcing network shutdown (ifdown -a --force) before 'halt' command in /etc/init.d/halt script


ethtool output :

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

lspci -nn output :

04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01)

Steps to reproduce: N/A

I have submitted the bug under launchpad (https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/160413) and I have been advised to open a bug report here.

Regards.
Comment 1 Andrew Morton 2007-12-06 14:12:36 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.
Comment 2 Pierre-Yves Bretécher 2007-12-06 14:25:09 UTC
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.
Comment 3 Francois Romieu 2007-12-06 15:10:05 UTC
Pierre Yves:
[...]
> - using the Realtek official driver ( r8168 ) in place of the Gutsy provided
> r8169

It made no difference, right ?

-- 
Ueimor
Comment 4 Francois Romieu 2007-12-06 15:12:33 UTC
Created attachment 13898 [details]
Hardcoded wol hack

Completely untested. I'll rework it if it kinda works.

-- 
Ueimor
Comment 5 Pierre-Yves Bretécher 2007-12-06 15:41:55 UTC
Yes, using r8168 from Realtek (r8168-8.003.00) does not work better.

I'll try your patch this WE.

Thanks a lot.

PY
Comment 6 Pierre-Yves Bretécher 2007-12-08 12:10:44 UTC
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
Comment 7 Pierre-Yves Bretécher 2007-12-08 14:29:54 UTC
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
Comment 8 Francois Romieu 2007-12-09 06:59:41 UTC
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.
Comment 9 Francois Romieu 2007-12-13 14:39:01 UTC
Created attachment 14013 [details]
add PCI device shutdown handler

Pierre-Yves, can you try this new patch on top of any recent kernel ?

-- 
Ueimor
Comment 10 Pierre-Yves Bretécher 2007-12-14 11:58:34 UTC
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
Comment 11 Francois Romieu 2007-12-15 03:36:57 UTC
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.
Comment 12 Pierre-Yves Bretécher 2007-12-15 11:46:01 UTC
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
Comment 13 Pierre-Yves Bretécher 2007-12-15 11:55:14 UTC
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
Comment 14 Francois Romieu 2007-12-15 15:19:02 UTC
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 
Comment 15 Francois Romieu 2007-12-15 15:25:15 UTC
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 ?
Comment 16 Pierre-Yves Bretécher 2007-12-16 00:33:09 UTC
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
Comment 17 Pierre-Yves Bretécher 2007-12-18 14:13:45 UTC
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
Comment 18 Francois Romieu 2007-12-18 14:54:42 UTC
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 ?
Comment 19 Pierre-Yves Bretécher 2007-12-18 15:15:04 UTC
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. 
Comment 20 Francois Romieu 2007-12-18 15:19:30 UTC
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/).
Comment 21 Pierre-Yves Bretécher 2007-12-18 15:24:06 UTC
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
Comment 22 Pierre-Yves Bretécher 2007-12-18 15:45:35 UTC
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
Comment 23 Francois Romieu 2007-12-20 15:08:34 UTC
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/
Comment 24 Pierre-Yves Bretécher 2007-12-20 22:25:01 UTC
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.
Comment 25 Pierre-Yves Bretécher 2007-12-22 02:13:50 UTC
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...
Comment 26 Tim Ansell 2007-12-27 22:47:06 UTC
I too have this problem, what is the best way to help fix it?
Comment 27 Bruno Prémont 2008-02-02 15:17:09 UTC
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).
Comment 28 Pierre-Yves Bretécher 2008-02-03 02:08:07 UTC
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.
Comment 29 Bruno Prémont 2008-02-03 03:04:34 UTC
(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
Comment 30 Bruno Prémont 2008-02-03 03:37:14 UTC
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.
Comment 31 Pierre-Yves Bretécher 2008-02-03 06:38:17 UTC
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
Comment 32 Bruno Prémont 2008-02-03 06:59:32 UTC
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)
Comment 33 Pierre-Yves Bretécher 2008-02-03 09:16:48 UTC
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
Comment 34 Bruno Prémont 2008-02-03 09:47:17 UTC
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
Comment 35 Pierre-Yves Bretécher 2008-02-04 00:03:49 UTC
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.
Comment 36 Francois Romieu 2008-02-10 13:35:46 UTC
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
Comment 37 Pierre-Yves Bretécher 2008-02-11 13:37:05 UTC
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.
Comment 38 Pierre-Yves Bretécher 2008-03-07 09:59:12 UTC
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
Comment 39 Matthew Nichols 2008-04-02 15:50:34 UTC
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.
Comment 40 Pierre-Yves Bretécher 2008-04-03 13:53:20 UTC
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
Comment 41 Francois Romieu 2008-04-03 13:59:46 UTC
Matthew, does your motherboard include a 8169 or a 8168 ?

-- 
Ueimor
Comment 42 Matthew Nichols 2008-04-04 11:10:15 UTC
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.
Comment 43 Pierre-Yves Bretécher 2008-04-04 11:48:49 UTC
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.
Comment 44 Pierre-Yves Bretécher 2008-04-04 12:09:37 UTC
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 !
Comment 45 Pierre-Yves Bretécher 2008-04-12 08:41:54 UTC
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.
Comment 46 Lucas Nussbaum 2008-04-18 02:59:40 UTC
OK, some more information.
First, the Ubuntu bug for this: https://bugs.launchpad.net/linux/+bug/160413
Comment 47 Lucas Nussbaum 2008-04-18 03:13:04 UTC
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)
Comment 48 Bruno Prémont 2008-04-20 05:06:57 UTC
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?
Comment 49 Lucas Nussbaum 2008-04-20 05:15:47 UTC
2.6.24. I haven't tried with 2.6.25 yet, but I don't expect any change. Should I?
Comment 50 Bruno Prémont 2008-04-20 05:43:48 UTC
(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.
Comment 51 Matthew Nichols 2008-04-21 18:07:13 UTC
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.
Comment 52 Matthew Nichols 2008-04-21 18:15:17 UTC
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.
Comment 53 Pierre-Yves Bretécher 2008-09-06 01:21:54 UTC
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.
Comment 54 Francois Romieu 2008-09-16 15:35:07 UTC
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
Comment 55 Lucas Nussbaum 2008-09-17 01:40:38 UTC
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
Comment 56 Bruno Prémont 2008-09-17 13:00:58 UTC
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
Comment 57 Bruno Prémont 2008-09-21 13:04:00 UTC
> 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
Comment 58 Lucas Nussbaum 2008-09-21 23:26:02 UTC
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.
Comment 59 Bruno Prémont 2008-09-22 09:55:28 UTC
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...
Comment 60 Lucas Nussbaum 2008-09-25 22:24:48 UTC
@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).
Comment 61 Bruno Prémont 2008-10-04 09:40:11 UTC
(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...
Comment 62 Lucas Nussbaum 2008-10-06 01:48:55 UTC
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,
Comment 63 Fredrik Viksten 2008-10-14 04:31:53 UTC
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?
Comment 64 Fredrik Viksten 2008-10-15 02:51:23 UTC
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?
Comment 65 Bruno Prémont 2008-10-15 09:38:50 UTC
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.
Comment 66 Fredrik Viksten 2008-10-16 03:11:33 UTC
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.
Comment 67 Lucas Nussbaum 2008-11-29 04:26:40 UTC
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.
Comment 68 Antonio Perez 2008-12-17 09:08:18 UTC
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. ;)
Comment 69 Fredrik Viksten 2008-12-22 15:55:06 UTC
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 70 Fredrik Viksten 2008-12-23 04:18:26 UTC
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????
Comment 71 Bruno Prémont 2008-12-23 09:37:21 UTC
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?
Comment 72 Fredrik Viksten 2008-12-23 12:56:28 UTC
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.
Comment 73 Bruno Prémont 2008-12-23 13:33:11 UTC
(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).
Comment 74 Roland Scheidegger 2008-12-29 18:24:50 UTC
(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).
Comment 75 Andreas Matthus 2009-01-13 23:41:20 UTC
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
Comment 76 Andreas Matthus 2009-01-23 00:24:21 UTC
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.
Comment 77 Mike 2009-04-09 13:35:42 UTC
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..
Comment 78 Pacho Ramos 2009-05-17 09:32:17 UTC
Any news on this one? We have still people affected by this downstream with kernel-2.6.29

Thanks
Comment 79 Pierre-Yves Bretécher 2009-05-17 10:37:55 UTC
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, ...).
Comment 80 Pacho Ramos 2009-05-17 12:57:22 UTC
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
Comment 81 Jaromír Cápík 2009-05-23 17:48:33 UTC
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.
Comment 82 Jaromír Cápík 2009-05-28 06:49:44 UTC
2.6.30-desktop-0.rc7.1mnb (Mandriva 2010.0 Cooker) ... can't wake up :(
Comment 83 Jaromír Cápík 2009-05-28 09:19:17 UTC
2.6.30-0.rc7.2mdv [kernel-linus] (Mandriva 2010.0 Cooker) ... can't wake up
Comment 84 Jaromír Cápík 2009-06-20 10:45:39 UTC
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
Comment 85 Jaromír Cápík 2009-07-05 22:29:52 UTC
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!
Comment 86 Jaromír Cápík 2009-07-06 08:58:26 UTC
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);
        }
}
Comment 87 Andreas Matthus 2009-07-09 06:55:00 UTC
(In reply to comment #85)
Hallo,

this patch works fine for me with vanilla-kernel 2.6.30.1.

with regards
Andreas Matthus
Comment 88 Fredrik Viksten 2009-07-13 10:07:30 UTC
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
Comment 89 Jaromír Cápík 2009-07-15 12:52:06 UTC
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.
Comment 90 Jaromír Cápík 2009-07-15 13:09:38 UTC
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 ...
Comment 91 Jaromír Cápík 2009-07-15 13:46:08 UTC
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.
Comment 92 Francois Romieu 2009-07-15 22:05:35 UTC
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
Comment 93 Francois Romieu 2009-07-15 22:08:38 UTC
Created attachment 22366 [details]
Bring the device down more gently
Comment 94 Jaromír Cápík 2009-07-16 08:16:14 UTC
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.
Comment 95 Jaromír Cápík 2009-07-16 16:40:35 UTC
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.
Comment 96 Francois Romieu 2009-07-16 21:49:56 UTC
Created attachment 22380 [details]
Bring the device down more gently
Comment 97 Francois Romieu 2009-07-16 21:52:10 UTC
(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
Comment 98 Jaromír Cápík 2009-07-17 08:06:17 UTC
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.
Comment 99 Jaromír Cápík 2009-07-21 18:03:44 UTC
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);
        }
}
Comment 100 Jaromír Cápík 2009-07-21 18:05:30 UTC
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.
Comment 101 Francois Romieu 2009-07-21 20:58:50 UTC
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
Comment 102 Jaromír Cápík 2009-07-22 11:10:28 UTC
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.
Comment 103 Francois Romieu 2009-07-22 21:54:18 UTC
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.
Comment 104 Jaromír Cápík 2009-07-22 23:29:27 UTC
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.
Comment 105 Francois Romieu 2009-07-23 21:49:25 UTC
Created attachment 22477 [details]
Enable Rx when WoL is required
Comment 106 Francois Romieu 2009-07-23 21:53:55 UTC
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.
Comment 107 Jaromír Cápík 2009-07-24 16:24:40 UTC
Hi Ueimor.

Yep. Shutdown+Wakeup works :)

Ok ... I will wait with the suspend test till it is needed. 

Thanks.
Regards,
Jaromir.
Comment 108 Francois Romieu 2009-07-28 18:59:46 UTC
(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
Comment 109 Francois Romieu 2009-08-02 20:47:29 UTC
Jaromir, can you attach your .config, a complete dmesg from boot and
a lspci -vv / -t for future reference ?

Thanks.

-- 
Ueimor
Comment 110 Jaromír Cápík 2009-08-17 13:29:39 UTC
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.
Comment 111 Jaromír Cápík 2009-08-17 13:39:53 UTC
Created attachment 22753 [details]
.config used for testing
Comment 112 Jaromír Cápík 2009-08-17 13:42:16 UTC
Created attachment 22754 [details]
.config of my current kernel
Comment 113 Jaromír Cápík 2009-08-17 13:43:19 UTC
Created attachment 22755 [details]
dmesg
Comment 114 Jaromír Cápík 2009-08-17 13:44:12 UTC
Created attachment 22756 [details]
lspci -vv
Comment 115 Jaromír Cápík 2009-08-17 13:44:40 UTC
Created attachment 22757 [details]
lspci -t
Comment 116 Andreas Matthus 2009-09-29 06:56:22 UTC
Hallo,

WOL works fine with 2.6.31

thank you
Andreas Matthus