Bug 4849

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.