Distribution: Gentoo Hardware Environment: EPIAM1000 Software Environment: vanilla kernel Problem Description: After upgrading from 2.6.7 to 2.6.12.1 and 2.6.12.2 system is not able to wake up after a sending a magicpacket (tm) string to the internal via-rhine nic. Nic/leds are activ when system is powered down, bios WOL settings are set and it's working fine with 2.6.7. ethtool eth0 output: Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000001 (1) Link detected: yes Setting PME bit with ethtool -s eth0 wol g, wake on status is g. After reboot status is d (disabled) again. As described in BUG 3801. Another dup could be BUG 3936
Created attachment 5273 [details] dmesg
Created attachment 5274 [details] acpidmp
Created attachment 5275 [details] dmidecode
Created attachment 5276 [details] interrupts
Created attachment 5277 [details] lspci -vv
Created attachment 5486 [details] patch for the issue Please try this patch. After applied the patch, do echo 'LAN0' > /proc/acpi/wakeup and try again.
Hi david, Thanks for looking into this.. Applied the patch to 2.6.12.2 and with only echo 'LAN0' > /proc/acpi/wakeup system doesn't wake up. With patch and echo and when enabling wol on the interface with ethtool -s eth0 wol g the system does wake-up after shutdown. :-) Status after boot is: cat /proc/acpi/wakeup Device Sleep state Status PCI0 5 disabled USB0 5 disabled USB1 5 disabled USB2 5 disabled USB3 3 disabled USB4 3 disabled USB5 3 disabled USB6 3 disabled LAN0 5 disabled AC97 5 disabled MC97 5 disabled UAR1 5 disabled Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000001 (1) Link detected: yes
hmm, tried it on the 2.6.12.1 kernel without the patch and with echo 'LAN0' > /proc/acpi/wakeup and ethtool -s eth0 wol g and system wakes up. So the patch doesn't seem to work.
echo 'LAN0' >/proc/acpi/wakeup should do nothing for S5 in 2.6.12.1, please check if just 'ethtool -s eth0 wol g' works.
your right, only ethtool -s eth0 wol g seems to do the trick but after boot status is d (disabled) again. So something is resetting this feature.
So how about only do echo 'LAN0' >/proc/acpi/wakeup with the patch?
Reported this earlier, see above. But with the patch to 2.6.12.2 and with only echo 'LAN0' > /proc/acpi/wakeup system doesn't wake up. Should i upgrade to linux-2.6.13-rc5 with patch to rule things out? That would take a while though.
So this means enable/disable ACPI wakeup doesn't matter for the case, right? It might not be an ACPI issue.
So this means enable/disable ACPI wakeup doesn't matter for the case, right? Affirmative It might not be an ACPI issue. Any suggestions where to start looking.?
Triggered by a post on viaarena forums this seems to be a well known issue. After searching the kernel archives (again) via_rhine maintainer Roger Luethi and Jeff seems to know about this problem. http://gossamer-threads.com/lists/linux/kernel/493224?search_string=via_rhine%20wol;#493224 and http://gossamer-threads.com/lists/linux/kernel/496802?search_string=via_rhine%20wol;#496802 Patch seems to be applied to via_rhine.c and not sure if changes are made to the internal via-rhine queue, inside the netdev-2.6 queue !? I am not that much of a programmer to know where that queue's are located :-) Anyway as far i understand it, this is a particular problem and difficult to solve with a generic solution. There is a workaround using ethtool so that's sufficient enough for me right now but for end-users bumping into this problem for the first time don't expect to use a workaround and imho it should work out of the box to avoid this kind of bug reports. Appreciate the effort and work you maintainers have done though, Thanks.