Wake on LAN (WOL) not working with r8169 driver
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Medium
|
|||
linux (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
linux-source-2.6.22 (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug 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
In particular it seems to me that my issue is not related to the bug #127010 (https:/
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)
Richard Samson (richard) wrote : | #1 |
SK (stephantom) wrote : | #2 |
According to launchpad's search, the r8169 driver is only found in kernel-
Changed in kernel-source-2.6.10: | |
assignee: | nobody → ubuntu-kernel-team |
Brian Murray (brian-murray) wrote : | #3 |
I've changed the package to linux-source-2.6.22 which is the kernel used for Gutsy.
Changed in kernel-source-2.6.10: | |
assignee: | ubuntu-kernel-team → nobody |
Leann Ogasawara (leannogasawara) wrote : Re: Wake on LAN (WOL) not working with r8169 driver on Gutsy | #4 |
The Hardy Heron kernel was recently uploaded for testing. We'd really appreciate it if you could try testing with this newer kernel and verify if this issue still exists. Unfortunately, the Hardy Heron Alpha1 LiveCD was released with the older 2.6.22 kernel. You'll have to manually install the newer Hardy Heron kernel in order to test. This should not be the case for Alpha2. However, here are the instructions to install (if you choose to do so):
1) edit the file /etc/apt/
deb http://
2) sudo apt-get update
3) sudo apt-get install linux-image-
4) reboot and select the new kernel from the grub menu
After you've tested, please feel free to revert back - ie boot into the old kernel, sudo apt-get remove linux-image-
Changed in linux: | |
importance: | Undecided → Medium |
status: | New → Incomplete |
Pierre-Yves (py-bretecher) wrote : | #5 |
Hi,
I have just tested the 2.6.24-1-generic kernel and there is no difference with 2.6.22 (I have also checked that it is still working after a windows XP shutdown). With this new kernel boot process is not complete since I guess my nvidia modules does not match the new kernel but I could check that, inside the console, I can ping other machines, so network interface is alive and working.
I have recently check the development activity on r8169.c inside git (http://
Regards
Leann Ogasawara (leannogasawara) wrote : | #6 |
Well there are maybe a few options you could do to get this noticed by upstream:
1) Open a bug report at bugzilla.kernel.org regarding this issue. Afterwards, we can then easily link this launchpad bug report to the upstream kernel bugzilla bug report you created.
2) You could attempt to contact the driver maintainer/mailing list to see if they would work on this issue.
Note that I'm going to close this report against linux-source-2.6.22 as it does not meet the criteria for a stable release update. However, against the actively developed kernel it will remain open. You can learn more about the stable release update process at https:/
Changed in linux: | |
status: | Incomplete → Won't Fix |
status: | Won't Fix → Triaged |
Changed in linux-source-2.6.22: | |
status: | New → Won't Fix |
Changed in linux: | |
assignee: | nobody → ubuntu-kernel-team |
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #51 |
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:
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:/
Regards.
In Linux Kernel Bug Tracker #9512, akpm (akpm-linux-kernel-bugs) wrote : | #52 |
> 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.
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #53 |
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.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #54 |
Pierre Yves:
[...]
> - using the Realtek official driver ( r8168 ) in place of the Gutsy provided
> r8169
It made no difference, right ?
--
Ueimor
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #55 |
Created attachment 13898
Hardcoded wol hack
Completely untested. I'll rework it if it kinda works.
--
Ueimor
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #56 |
Yes, using r8168 from Realtek (r8168-8.003.00) does not work better.
I'll try your patch this WE.
Thanks a lot.
PY
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #57 |
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:
CHK include/
CHK include/
CALL scripts/
CC [M] drivers/net/r8169.o
drivers/
drivers/
drivers/
drivers/
drivers/
make[2]: *** [drivers/
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
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #58 |
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
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
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
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #59 |
<email address hidden>:
[...]
> 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.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #60 |
Created attachment 14013
add PCI device shutdown handler
Pierre-Yves, can you try this new patch on top of any recent kernel ?
--
Ueimor
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #61 |
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:
CHK include/
CHK include/
CALL scripts/
CC [M] drivers/net/r8169.o
drivers/
drivers/
drivers/
drivers/
drivers/
make[2]: *** [drivers/
make[1]: *** [drivers/net] Erreur 2
make: *** [drivers] Erreur 2
Thanks a lot
PY
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #62 |
<email address hidden> 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.
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #63 |
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://
py@PC-FIXE2:
CHK include/
CHK include/
CALL scripts/
CC [M] drivers/net/r8169.o
drivers/
drivers/
drivers/
drivers/
drivers/
make[2]: *** [drivers/
make[1]: *** [drivers/net] Erreur 2
make: *** [drivers] Erreur 2
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #64 |
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
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #65 |
<email address hidden>:
[...]
> py@PC-FIXE2:
> CHK include/
> CHK include/
> CALL scripts/
> CC [M] drivers/net/r8169.o
> drivers/
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #66 |
<email address hidden>:
> 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 ?
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #67 |
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
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #68 |
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
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #69 |
<email address hidden> :
[...]
> 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 ?
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #70 |
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
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/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.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #71 |
<email address hidden> :
[...]
> I have not explicitely enable WOL but I can try.
Please try it (otherwise tp->features & RTL_FEATURE_WOL will be false :o/).
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #72 |
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
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #73 |
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
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #74 |
<email address hidden> 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 Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #75 |
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.
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #76 |
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...
Richard Samson (richard) wrote : | #7 |
I'm not sure it's a kernel bug. I tried latest vanilla kernel and Ubuntu Hardy, I got the same issue with wake on lan.
If I stopped computer with halt command (no call to init 6 or 0), then wol from another computer works fine.
Pierre-Yves (py-bretecher) wrote : | #8 |
hello Richard,
I just tried to shutdown my box using the halt command under Ubuntu Hardy : WOL is still not working on my box (I also verified that after a boot/shutdown with Win XP WOL is always OK). Did you use special options ?
Regards
PY
Richard Samson (richard) wrote : | #9 |
hi Pierre-Yves,
I have tried halt command few weeks ago, i forgot something, i can't get wol working now.
Perhaps I've started a Windows before booting Ubuntu.
Thanks for the bug report http://
Pierre-Yves (py-bretecher) wrote : | #10 |
Hello Richard,
On my side, booting linux after windows does not change anything :
- Shutting down from windows : works whatever the OS I ran before
- Shutting down from linux : does not work whatever the OS I ran before
Anyway, I feel less alone !
In Linux Kernel Bug Tracker #9512, mithro (mithro-linux-kernel-bugs) wrote : | #77 |
I too have this problem, what is the best way to help fix it?
Changed in linux: | |
status: | Unknown → In Progress |
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #78 |
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).
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #79 |
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:
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 Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #80 |
(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://
> On my side, I have had look to the "acpitool -w" output that seems strange
> to me :
> py@pc-fixe2:
> 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
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #81 |
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://
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #82 |
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
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #83 |
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)
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #84 |
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
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #85 |
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
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #86 |
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
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/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.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #87 |
Created attachment 14775
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
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #88 |
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.
John Cass (johnpcass) wrote : | #11 |
Hello
I wonder if there has been any progress on this?
I would like to report that since upgrading to Gutsy (from Edgy) - without changing the hardware at all - WOL has stopped working : it used to work perfectly.
My card is an 8139 type ethernet card. I set it correctly with ethtool but during the shutdown, somehow the system decides to power down the ethernet card (no LED).
Im starting to think its a problem related to ACPI, perhaps the DSDT table?
Does anyone have any other ideas we could try?
Regards
John
Richard Samson (richard) wrote : | #12 |
Hello,
Works fine on Hardy with kernel-
I didn't change anything, just follow Hardy updates.
Pierre-yves could you try with Hardy on host ?
Regards.
Richard
John Cass (johnpcass) wrote : | #13 |
Hi Richard
Did you update just the kernel from Heron to Gutsy, or did you do a 'full update'? I tried just upgrading just the kernel (using this procedure: http://
Regards
John
Richard Samson (richard) wrote : | #14 |
Hello,
I used Hardy, I didn't try Hardy kernel on Gutsy. This bug don't seem depend on kernel.
Regards.
Richard
Pierre-Yves (py-bretecher) wrote : | #15 |
Hello,
I'm currently on vacation, I hope to test the latetst kernel release this week end.
Regards
Pierre-Yves
John Cass (johnpcass) wrote : | #16 |
Hmmm.
Tried booting from the latest (alpha 5) heron xubuntu live cd, got thrown into ash in initramfs ;-(
Also tried booting from my previous edgy installation - in which wol worked for over a year - and now wol fails there too......
something in the bios changed by installing gutsy? i dont know enough about it but could it be an acpi-dsdt issue? - is this upgraded by the ubuntu installation?
an even more confused John
John Cass (johnpcass) wrote : | #17 |
Just found this (https:/
John
Lucas Nussbaum (lucas) wrote : | #18 |
It seems that the problem is that shutting down the NIC during shutdown disables WOL.
If I shutdown using "poweroff -f", WOL works fine. (Warning: poweroff -f doesn't go through the normal shutdown procedure, and might cause data loss)
Running 2.6.24 from Debian. Can someone double-check using 2.6.22 or 2.6.24 from Ubuntu?
Lucas Nussbaum (lucas) wrote : | #19 |
Another way to double-check that is to edit /etc/init.
stop)
if sed -n 's/^[^ ]* \([^ ]*\) \([^ ]*\) .*$/\2/p' /proc/mounts |
exit 0
fi
if ifdown -a --exclude=lo; then
else
fi
;;
And change:
if ifdown -a --exclude=lo; then
by:
if true; then
(or anything else that prevents ifdown from running)
Then do a normal shutdown. This way to test is safer than the other one, too :-)
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #89 |
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:
make -C src/ modules
make[1]: entrant dans le répertoire « /home/py/
make -C /lib/modules/
make[2]: entrant dans le répertoire « /usr/src/
CC [M] /home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
/home/py/
make[3]: *** [/home/
make[2]: *** [_module_
make[2]: quittant le répertoire « /usr/src/
make[1]: *** [modul...
Pierre-Yves (py-bretecher) wrote : | #20 |
Hi,
I tried both the new kernel revision and the network init script hack and ... no luck for me. Again, I checked right after each attempt that a shutdown after a Win XP boot re-enables WOL.
Pierre-Yves
John Cass (johnpcass) wrote : | #21 |
Confusingly, my system now DOES work with WOL - using Ubuntu Gutsy standard kernel 2.6.22-14
I dont know what has changed...
The system does turn off the light on the ethernet card but it does respond to magic packets.
If I find out what changed I will add a comment.
Regards
John
(note: my system uses a PCI 8139 type ethernet card)
Lucas Nussbaum (lucas) wrote : Re: [Bug 160413] Re: Wake on LAN (WOL) not working with r8169 driver on Gutsy | #22 |
On 09/03/08 at 11:27 -0000, John Cass wrote:
> (note: my system uses a PCI 8139 type ethernet card)
I think that 8139 is a different NIC, and you might use a different
driver. Are you sure that you are using r8169?
--
| Lucas Nussbaum
| <email address hidden> http://
| jabber: <email address hidden> GPG: 1024D/023B3F4F |
John Cass (johnpcass) wrote : Re: Wake on LAN (WOL) not working with r8169 driver on Gutsy | #23 |
Lucas
I am indeed using a 8139 type nic, not a 8169 - sorry for any confusion.
John
In Linux Kernel Bug Tracker #9512, mjnichol (mjnichol-linux-kernel-bugs) wrote : | #90 |
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.
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.
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #91 |
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
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #92 |
Matthew, does your motherboard include a 8169 or a 8168 ?
--
Ueimor
In Linux Kernel Bug Tracker #9512, mjnichol (mjnichol-linux-kernel-bugs) wrote : | #93 |
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.
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #94 |
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.
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #95 |
Yeeess, congratulations Matthew. I can wake my PC if I disable NM (and manually reconfigure /etc/network/
I will try to verify on my box that it is precisely the ifdown that disable WOL.
Thank you !
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #96 |
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.
In Linux Kernel Bug Tracker #9512, lucas (lucas-linux-kernel-bugs) wrote : | #97 |
OK, some more information.
First, the Ubuntu bug for this: https:/
In Linux Kernel Bug Tracker #9512, lucas (lucas-linux-kernel-bugs) wrote : | #98 |
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 Nussbaum (lucas) wrote : | #24 |
kernel bug for this: http://
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #99 |
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://
PS: Lucas, what kernel version are you using?
In Linux Kernel Bug Tracker #9512, lucas (lucas-linux-kernel-bugs) wrote : | #100 |
2.6.24. I haven't tried with 2.6.25 yet, but I don't expect any change. Should I?
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #101 |
(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/
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.
In Linux Kernel Bug Tracker #9512, mjnichol (mjnichol-linux-kernel-bugs) wrote : | #102 |
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.
In Linux Kernel Bug Tracker #9512, mjnichol (mjnichol-linux-kernel-bugs) wrote : | #103 |
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.
Mark Robinson (launchpad-zl2tod) wrote : | #25 |
speaks of a setting in Windows XP which prevents same from leaving the NIC in a state from which the linux drivers cannot recover.
That all said I am suspicious of network-manager given the reports that this problem only emerges when the full gui is booted.
Leann Ogasawara (leannogasawara) wrote : | #26 |
The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:
1) If you are comfortable installing packages on your own, the linux-image-
--or--
2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://
Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #104 |
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.
Pierre-Yves (py-bretecher) wrote : | #27 |
I have quickly tested the Kubuntu Intrepid Alpha, and the problem still exist.
As mentioned in the kernel bug report ( http://
Pierre-Yves (py-bretecher) wrote : | #28 |
Just tested the r8168-8.008.00 module from Realtek 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.
Richard Samson (richard) wrote : | #29 |
Pierre-Yves, this bug disappeared during Hardy development, since august with first Network Manager 0.7 upload on Intrepid, WOL stopped working. NM 0.7 seems to ignore network system settings.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #105 |
Do you experience the same with 2.6.27-rc6 +
http://
--
Ueimor
In Linux Kernel Bug Tracker #9512, lucas (lucas-linux-kernel-bugs) wrote : | #106 |
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
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #107 |
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/
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
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #108 |
> 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
In Linux Kernel Bug Tracker #9512, lucas (lucas-linux-kernel-bugs) wrote : | #109 |
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.
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #110 |
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/..
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...
In Linux Kernel Bug Tracker #9512, lucas (lucas-linux-kernel-bugs) wrote : | #111 |
@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 Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #112 |
(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://
http://
http://
Maybe the shutdown handler in François Romieu's series will fill the missing part for shutdown I mention in the email...
In Linux Kernel Bug Tracker #9512, lucas (lucas-linux-kernel-bugs) wrote : | #113 |
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,
In Linux Kernel Bug Tracker #9512, linuxkernel (linuxkernel-linux-kernel-bugs) wrote : | #114 |
Hi all, first post here :)
Lucas, it is my understanding that the above mentioned fixes are in 2.6.27-git2, see http://
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?
In Linux Kernel Bug Tracker #9512, linuxkernel (linuxkernel-linux-kernel-bugs) wrote : | #115 |
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?
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #116 |
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.
In Linux Kernel Bug Tracker #9512, linuxkernel (linuxkernel-linux-kernel-bugs) wrote : | #117 |
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.
In Linux Kernel Bug Tracker #9512, lucas (lucas-linux-kernel-bugs) wrote : | #118 |
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/
(following instructions from Bruno)
I can't wake up the system using WOL while it works with 2.6.24.
In Linux Kernel Bug Tracker #9512, aperez (aperez-linux-kernel-bugs) wrote : | #119 |
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. ;)
In Linux Kernel Bug Tracker #9512, linuxkernel (linuxkernel-linux-kernel-bugs) wrote : | #120 |
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/
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??
In Linux Kernel Bug Tracker #9512, linuxkernel (linuxkernel-linux-kernel-bugs) wrote : | #121 |
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://
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/
mentioned above. :)
Anyway, all the shutdown handler does is call "rtl8169_
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????
In Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #122 |
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?
Launchpad Janitor (janitor) wrote : Kernel team bugs | #30 |
Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https:/
In Linux Kernel Bug Tracker #9512, linuxkernel (linuxkernel-linux-kernel-bugs) wrote : | #123 |
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():
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 Linux Kernel Bug Tracker #9512, bonbons (bonbons-linux-kernel-bugs) wrote : | #124 |
(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_
>
> rtl8169_
>
> rtl8169_
>
> spin_unlock_
>
> 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 Linux Kernel Bug Tracker #9512, rscheidegger (rscheidegger-linux-kernel-bugs) wrote : | #125 |
(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_
>
> rtl8169_
>
> rtl8169_
>
> spin_unlock_
>
> 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/
I modified this patch and simply replaced the rtl8169_asic_down function call with a call to rtl8169_
In Linux Kernel Bug Tracker #9512, Andreas.Matthus (andreas.matthus-linux-kernel-bugs) wrote : | #126 |
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
In Linux Kernel Bug Tracker #9512, Andreas.Matthus (andreas.matthus-linux-kernel-bugs) wrote : | #127 |
workaround:
cp /usr/src/
rm /usr/src/
rm /usr/src/
cd /usr/src/linux
make
cp drivers/
After next reboot with kernel 2.6.28 WOL works fine too.
In Linux Kernel Bug Tracker #9512, empx (empx-linux-kernel-bugs) wrote : | #128 |
Same problem here, WoL from S5 with 2.6.26 worked for my Gigabye P35 DS3, .28 and .29.1 did not.
My distribution(
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_
Amit Kucheria (amitk) wrote : Re: Wake on LAN (WOL) not working with r8169 driver on Gutsy | #31 |
This bug was reported a while ago but there hasn't been any recent comments or updates. Is this still an issue with the latest pre-release of Jaunty 9.04? Refer to http://
Changed in linux (Ubuntu): | |
status: | Triaged → Incomplete |
Pierre-Yves (py-bretecher) wrote : | #32 |
A quick test with jaunty does not show any improvement on my machine (still the same as in my first post.
Thilo-Alexander Ginkel (thilo.ginkel) wrote : | #33 |
For me WOL magically started working - I tried a couple of times during the last few days. The weird thing is that I am still running Intrepid on the machine, i.e.:
Linux andromeda 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux
The only thing I changed kernel-wise during the last weeks (except for applying security updates if any) was that I migrated from KVM to VirtualBox, so kvm-intel is no longer loaded.
@Pierre-Yves: Are you by chance using kvm or is the module loaded on your machine (lsmod | grep kvm should do the trick)?
wangweilin (accounts-computational-chemistry) wrote : | #34 |
Hi my problem is a little different. I was using Kubuntu 8.10 till the update to 9.04 with Wake On Lan.
Just 3 things needed to be done in my case additional to enabling wol.
- Deinstallation des Networkmanagers
I guess because it messes with the settings
- Editieren der /etc/init.de/halt (NETDOWN=no)
You know why
- Editieren der /etc/network/
To stop bringing the Interface down.
But since the Update ... it stopped working ... and I am looking for someone who can tell me why or even how to fix it.
Maybe some of you can try it.
Cheers wangweilin
Changed in linux (Ubuntu): | |
importance: | Medium → Low |
status: | Incomplete → Confirmed |
tags: | added: ct-rev |
Geoff (gpwright) wrote : | #35 |
Just upgraded from Hardy to Jaunty and my wake on lan stopped working. I'm using a realtek 8168 on board NIC, although I notice the driver is 8169. Have tried editing halt script, using ethtool and disabling ifdown commands in /etc/init.
Does anyone have a fix? Should I try replacing the driver with the 8168 from realteks website? I downloaded it but couldn't figure out how to make it compile.
Thanks...
Geoff
Geoff (gpwright) wrote : | #36 |
For anyone who is having the above problem, the fix for me was to replace the 8169 driver with realteks latest 8168 driver from their website. This in combination with NETWORKDOWN=no in the /etc/init.d/halt script worked for me - WOL is now working nicely again.
I guess there is a small problem with jaunty upgrade that it is installing the wrong driver.
Geoff
summary: |
- Wake on LAN (WOL) not working with r8169 driver on Gutsy + Wake on LAN (WOL) not working with r8169 driver |
Pierre-Yves (py-bretecher) wrote : | #37 |
Hi Geoff,
I tried to use the Realtek r8168-8.011.00 driver in combination with "NETDOWN=no" in /etc/init.d/halt but WOL still does not work. Did you remove NetworkManager ? Until now, removing NetworkManager was the only way for me to get WOL working (but I haven't tested yet on Jaunty, I'll try it soon).
PY
Geoff (gpwright) wrote : Re: [Bug 160413] Re: Wake on LAN (WOL) not working with r8169 driver | #38 |
This is server edition Jaunty so no NetworkManager. I did make some
modifications to /etc/network/
difference.
Here is my /etc/network/
iface eth0 inet dchp
up ethtool -s eth0 wol g
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
auto lo
iface lo inet loopback
auto eth0
2009/5/6 Pierre-Yves <email address hidden>
> Hi Geoff,
>
> I tried to use the Realtek r8168-8.011.00 driver in combination with
> "NETDOWN=no" in /etc/init.d/halt but WOL still does not work. Did you
> remove NetworkManager ? Until now, removing NetworkManager was the only
> way for me to get WOL working (but I haven't tested yet on Jaunty, I'll
> try it soon).
>
> PY
>
> --
> Wake on LAN (WOL) not working with r8169 driver
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: In Progress
> Status in “linux” source package in Ubuntu: Confirmed
> Status in “linux-
>
> Bug 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
>
> In particular it seems to me that my issue is not related to the bug
> #127010 (https:/
>
>
>
> 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)
>
--
Geoff Wright
<email address hidden>
(+44)-788-202-3327
O. (olivierv) wrote : | #39 |
I don't know if it's of any help, but on jaunty with wicd installed instead of NetworkManager, WOL still does not work.
HOWEVER, booting and then halting on hardy kernel (2.6.27-11) with no other change at all allows my computer to wake up.
So I guess it's a kernel (driver ?) problem.
concertedrxn (travisejones) wrote : | #40 |
I found a solution to the problem. I have the same ethernet card as the original reporter of the bug, and I'm still running Intrepid (AMD64).
$ lspci -nn | grep Realtek
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01)
I solved the problem by downloading and compiling the driver for the r8168 from Realtek's web site: <http://
To get it to compile I had to manually edit the Makefile in the src/ directory so it would point to the correct src/ directory. For whatever reason, the line "$(MAKE) -C $(KDIR) SUBDIRS=$(PWD)/src modules" wouldn't work, so I replaced "$(PWD)/src" with the actual path.
After a "sudo modprobe -r r8169 && sudo modprobe r8168" I was able to suspend my computer and wake it up with a MagicPacket without any other change to the configuration. I suppose I need to blacklist the r8169 module in /etc/modprobe.
Realtek's r8168 driver is licensed under the GPL. It would be great if it could be included in Ubuntu.
joelholdsworth (joel-airwebreathe) wrote : | #41 |
concertedrxn's fix works for me. Works perfectly. Thank you - you are now my best friend forever and ever!
joelholdsworth (joel-airwebreathe) wrote : | #42 |
one more thing - the makefile mod fixes the driver build. Then you have to run "sudo make" (which is odd, but anyway), then "sudo make install". I had to run "sudo depmod" before "sudo modprobe -r r8169 && sudo modprobe r8168" in order to activate the driver.
In Linux Kernel Bug Tracker #9512, pachoramos1 (pachoramos1-linux-kernel-bugs) wrote : | #129 |
Any news on this one? We have still people affected by this downstream with kernel-2.6.29
Thanks
Pierre-Yves (py-bretecher) wrote : | #43 |
Few days ago I had tested the r8168-8.011.00 module from Realtek without success. Following the latest comments, I tried the very last release (r8168-8.012.00) of the kernel module and ... it simply worked (I could even remove NETDOWN=no in /etc/init.de/halt).
In order to make it permanent don't forget to blacklist r8169 in /etc/modprobe.
sudo depmod -a
sudo mkinitramfs -o /boot/initrd.
In Linux Kernel Bug Tracker #9512, py.bretecher (py.bretecher-linux-kernel-bugs) wrote : | #130 |
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, ...).
In Linux Kernel Bug Tracker #9512, pachoramos1 (pachoramos1-linux-kernel-bugs) wrote : | #131 |
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:/
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #132 |
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.
2.6.29.2-1mdv [kernel-linus] (Mandriva 2009.1) ... can't wake up :(
2.6.29.
2.6.28.5-pmagic (Parted Magic) ... cant't wake up :(
2.6.27.
2.6.24.
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.
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #133 |
2.6.30-
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #134 |
2.6.30-0.rc7.2mdv [kernel-linus] (Mandriva 2010.0 Cooker) ... can't wake up
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #135 |
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
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #136 |
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_
{
/* RTL_W8(ChipCmd, 0x00);
}
Great work guys!
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #137 |
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_
struct rtl8169_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->mmio_addr;
// rtl8169_
if (system_state == SYSTEM_POWER_OFF) {
}
}
In Linux Kernel Bug Tracker #9512, Andreas.Matthus (andreas.matthus-linux-kernel-bugs) wrote : | #138 |
(In reply to comment #85)
Hallo,
this patch works fine for me with vanilla-kernel 2.6.30.1.
with regards
Andreas Matthus
Janosch Peters (jp-binford3000) wrote : | #44 |
I had the same issue. The new driver did the trick. I didn't had to change the Makefile like "concertedrxn". It just worked out of the box. I suggest to include the new driver into the kernel.
concertedrxn (travisejones) wrote : | #45 |
After installing the r8168 module (v 8.012.00), I started having occasional kernel panics upon resuming from a suspended state. I thought the first one was a fluke, but recently they have become more common. I'm reverting back to the r8169 module until a new version of the r8168 becomes available. Is anyone else here experiencing the same problem?
In Linux Kernel Bug Tracker #9512, linuxkernel (linuxkernel-linux-kernel-bugs) wrote : | #139 |
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
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #140 |
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_
>{
> RTL_W8(ChipCmd, 0x00);
> rtl8169_
> 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.
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #141 |
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 ...
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #142 |
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.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #143 |
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
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #144 |
Created attachment 22366
Bring the device down more gently
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #145 |
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.
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #146 |
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.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #147 |
Created attachment 22380
Bring the device down more gently
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #148 |
(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
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #149 |
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.
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #150 |
Created attachment 22432
r8169-wol.patch - enables the receiver in the rtl_shutdown
static void rtl_shutdown(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_
struct rtl8169_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->mmio_addr;
if (system_state == SYSTEM_POWER_OFF) {
/* enable receiver to accept WOL */
}
}
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #151 |
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.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #152 |
Created attachment 22433
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
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #153 |
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.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #154 |
Jaromír Cápík <email address hidden> :
[...]
> 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.
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #155 |
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_
>#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_
> .shutdown = rtl_shutdown,
> .driver.pm = RTL8169_PM_OPS,
>};
(and there's no suspend defined here... )
?
I suppose You know why :)
BR, J.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #156 |
Created attachment 22477
Enable Rx when WoL is required
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #157 |
Jaromír Cápík <email address hidden> :
[...]
> (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.
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #158 |
Hi Ueimor.
Yep. Shutdown+Wakeup works :)
Ok ... I will wait with the suspend test till it is needed.
Thanks.
Regards,
Jaromir.
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #159 |
(In reply to comment #106)
[...]
> Yep. Shutdown+Wakeup works :)
The patch is included in mainline as ca52efd5490f97f
I'll close the bug when 2.6.30 is out if nobody complains until then.
--
Ueimor
In Linux Kernel Bug Tracker #9512, romieu (romieu-linux-kernel-bugs) wrote : | #160 |
Jaromir, can you attach your .config, a complete dmesg from boot and
a lspci -vv / -t for future reference ?
Thanks.
--
Ueimor
Christian Maier (launchpad-chmai) wrote : | #46 |
Can confirm that the new driver solves the problem. WOL worked fine in 8.10 and before. After update to 9.04 it stopped working. After replacing the driver with r8168 it works fine again.
Can not confirm problem with suspended state (reported by concertedrxn), because I am not using suspend state.
Thanks for solution! Will the replaced driver be included in 9.10 out of the box?
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #161 |
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.
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #162 |
Created attachment 22753
.config used for testing
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #163 |
Created attachment 22754
.config of my current kernel
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #164 |
Created attachment 22755
dmesg
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #165 |
Created attachment 22756
lspci -vv
In Linux Kernel Bug Tracker #9512, tavvva (tavvva-linux-kernel-bugs) wrote : | #166 |
Created attachment 22757
lspci -t
Mario Di Nicola (warp99) wrote : | #47 |
@concertedrxn
I'm also getting a kernel panic with the r8168 module on resume. The solution was to add a file in /etc/pm/config.d/ with the following contents:
SUSPEND_
Now the system doesn't cause a kernel panic, but getting the module to reload automatically after resume is an issue. I made a small script in /etc/pm/sleep.d to get it loaded and according to lsmod it's loaded, but the interface isn't working. I have to manually remove and reload the module to get the interface up again.
Mario Di Nicola (warp99) wrote : | #48 |
- 55networking script to resume networking Edit (221 bytes, text/plain)
@concertedrxn
Success!!! I have been able to suspend/resume without a kernel panic and have the interface working. I reconfigured my script in /etc/pm/sleep.d to instead start|stop networking services using pm-utils hooks (see attached). This along with the suspend_modules file fixed the problem.
In Linux Kernel Bug Tracker #9512, Andreas.Matthus (andreas.matthus-linux-kernel-bugs) wrote : | #167 |
Hallo,
WOL works fine with 2.6.31
thank you
Andreas Matthus
Changed in linux: | |
status: | In Progress → Fix Released |
Changed in linux: | |
importance: | Unknown → Medium |
Ivan Frederiks (idfred) wrote : | #49 |
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard
Ubuntu 11.04, x86_64, kernel 2.6.38-13-generic #57-Ubuntu SMP
Wake on lan is not working. Seems that adapter is switched off completely during shutdown: both link and act leds are off.
Tried:
* Putting "ethtool -s eth0 wol g" almost everywhere.
* Installing latest (version 8.028.00) r8168 driver from Realtek
* Removing "-i" option form halt call
* Putting "pci-config -B 2 -#1 -S" before halt call
* Putting "echo -n "RLAN" >> /proc/acpi/wakeup" to rc.local
* Switching adapter on and off in BIOS
* Switching WOL option on and off in BIOS
Anyone?
Phillip Susi (psusi) wrote : | #50 |
It looks like this was fixed upstream some time ago.
Changed in linux (Ubuntu): | |
status: | Confirmed → Fix Released |
In Linux Kernel Bug Tracker #9512, ucelsanicin (ucelsanicin-linux-kernel-bugs) wrote : | #168 |
$ ../gdb -nx --data-
(gdb) set osabi GNU/Linux http://
(gdb) set sysroot /home/simark/
(gdb) file Foo http://
Reading symbols from Foo...
(gdb) core-file Foo-core
warning: Can't open file /media/
warning: Can't open file /lib/libm-2.21.so during file-backed mapping note processing
warning: Can't open file /lib/libpthread
warning: Can't open file /lib/libgcc_s.so.1 during file-backed mapping note processing
warning: Can't open file /media/
warning: Can't open file /lib/libc-2.21.so during file-backed mapping note processing
warning: Can't open file /lib/ld-2.21.so during file-backed mapping note processing http://
[New LWP 29367]
[New LWP 29368] http://
warning: Could not load shared library symbols for 5 libraries, e.g. /lib/libc.so.6.
Use the "info sharedlibrary" command to see the complete listing. http://
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. http://
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. https:/
Core was generated by `./Foo'.
Program terminated with signal SIGABRT, Aborted. http://
#0 0xb6c3809c in pthread_cond_wait () from /home/simark/
[Current thread is 1 (LWP 29367)]
(gdb) bt http://
/home/simark/
Hi,
I got the same issue on a P35-DS3 mainboad with the same network card :
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
WOL works fine if I shutdown manually computer before Ubuntu loaded, for instance at Grub menu.