Description of problem: We have a system installed with RHEL 5.2 . If it is hibernated (enter S4 state), it can not be resumed by WOL (wake on lan). We also note the LED on NIC is off after hibernating. However, if we install Win2003 on the same system, it can well resume by WOL after hibernating. Steps to Reproduce: 1. hibernate the system with RHEL 5.2 2. send WOL magic packet from control platform Actual results: The system can not be waked up. The control platform can not send WOL magic packets to the system in interest. Expected results: The system should be resumed to wake up.
Although Bug #477186 (https://bugzilla.redhat.com/show_bug.cgi?id=477186) may be a possible duplicate of this issue, we tried with Linux kernel 2.6.27.9 and it can resume by wol (wake on lan) after hibernating.
What hardware is this? What are the contents of the /sys/power/disk file?
I'm seeing the same this with a Tyan S2882 system as well. [root@apollo ~]# cat /sys/power/disk shutdown [root@apollo ~]# cat /sys/power/state standby disk Seems to be a lot of wake on lan / hibernate issues with the linux kernel lately. Posted an upstream report in Bug 477186. Not sure how much of this is hitting the RHEL kernel. Also seeing with tg3 driver.
Can you test after doing echo -n platform >/sys/power/disk and see if that affects the behaviour? This triggers shutdown via the ACPI S4 method rather than performing a full system shutdown. It's also worth testing /proc/acpi/wakeup - the wakeup state of the device there can be toggled by echoing the ACPI device name (the four character identifier) into the file.
[root@apapane ~]# echo -n platform > /sys/power/disk -bash: echo: write error: Invalid argument On my tg3 (tyan S2881) system I can set platform, but it doesn't help.
Have another tg3 system (HP DL145 G3) that wont wake from lan from either shutdown or hibernate. It will wake up if I pull the power cord and plug it back in. With 2.6.18-128.1.6.el5 (EL 5.3).
On S2882 system with e100, I enabled everything in /proc/acpi/wakeup to no effect.
Any ideas?
This appears to be working again for me with EL6.
Given how long this problem has gone unresolved, it's relatively low severity, and the lifecycle stage that RHEL 5 is currently in, the problem reported will not be fixed in RHEL 5. -Lenny.