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 |
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 !
Changed in linux: | |
status: | Unknown → In Progress |
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 :-)
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
Lucas Nussbaum (lucas) wrote : | #24 |
kernel bug for this: http://
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.
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.
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:/
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.
88 comments hidden Loading more comments | view all 168 comments |
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
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
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
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
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 |
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.