Is it possible? I suspend by:
echo -n mem > /sys/power/state

And the system goes to sleep. Pressing the power button, it resumes and about 5 seconds later I am back exactly where I left off. Pressing a key on the keyboard also works, and I presume that activity from a USB device may also work (since my BIOS has that option).

However, sending a WOL magic packet or even a broadcast packet doesn't work. From completely shutdown (shutdown -h now) I can WOL sending the magic packet, works like a champ. I can even wake my system using the wake at a specific time option, so I know the BIOS can handle it. However, in sleep mode, the BIOS doesn't get reinitialized which leads me to believe that it doesn't really matter what the BIOS supports, it's the OS that I need to tell to wake-on-lan from sleep.

Any ideas, hints, conjecture, hate, or suggestions?

Thanks!

-Chad

Hi,

I can only think of an alternative, which is to use suspend-to-disk. Then using WOL will boot the computer, load the session, and resume it (in theory ).

Sam

PS
Another idea - suspend to ram may power off your network card. So if you can either tell your bios or your os to not disable your network card during sleep modes, and then somehow tell the bios or os to enable wake events from the network, you might be on the right track. <--all conjecture

Silly question, but did you try something as simple as
prior to suspending?
Perhaps you can put your network card into a specific sleep mode prior to suspending the system. Perhaps something like
Where you replace ADDR1 and ADDR2 with the relevant pci addresses for your NIC (as discernable from lspci).

P.S., what chipset/driver does your NIC use?

Thanks for the responses

Indeed supsend to disk (or hibernate if you prefer) works because it hits the BIOS on "resuming" but takes a little longer and requires a disk to suspend to (won't work easily with a "diskless" client).

I did use ethtool, one of the boards I'm testing this with doesn't support WOL "p" but all support "g" or magic packet.

The specific chipset and module are several actually:
Marvell Yukon using either module sk98lin or sg3 (IIRC I'm not at the system right now...)
Via chip using via-rhine
Nvidia onboard using forcedeth

None of them seem to work using suspend to RAM. I will poke around the BIOS some more to see if there are some settings in the ACPI area relating to sleep states and the network card.

Thanks!

-Chad

Hello,

I also have this same problem. I want to use wol while in suspend to RAM. I noticed the same behavior, and my conclusion is that the support is missing in the ethernet driver. I am testing it in several machines, and in one of them it works very well, this one has a Marvel chipset that uses the driver sky2. The others are d-link (skge) and Nvidia (forcedeth) drivers, they do not work from suspend to ram, but the d-link one works very well in windows, checking the box to enable the device to wake up and then suspending to ram, what eliminates the possibility of any Bios configuration. If anyone had success making it work with skge or forcedeth, please, let me know. I am using the kernel 2.6.22 with suspend2 patches. The kernel configuration is the same in the machine with sky2, where wol and suspend to ram works like a charm, and the other kernels.

Thank you

Did anyone ever find a solution? I'm experiencing the same thing using the forcedeth driver and kernel 2.6.22. No problems waking from power-off using a magic packet, but it won't wake from S3 without hitting the power button.
erikt

Don't take this is as gospel, but I believe I've read somewhere where it depends on your hardware. Some can use WOL to come out of suspend and some can't. The only machine I've been interested in WOL seems to only be able to come out of any form of suspend with the power switch.

This is one issue I'd be quite happy to be proven wrong on.

Sorry to bring up an old thread, but did you guys find a solution? I can WOL when I shutdown my system, but if I do a suspend to ram (S3) it doesn't respond to the magic packet. It's still even connected because the lights are still on the router.