WOL doesn't work second time (VIA chipset)

techqbert · n00b Joined: 23 May 2007 Posts: 14

Machine boots. I then "sudo hibernate-ram," machine goes down. Send WOL packet, computer wakes up. "sudo hibernate-ram" again... then the WOL packet doesn't wake the computer up. Any ideas guys?

MotivatedTea · Posted: Mon Jul 07, 2008 3:35 am Post subject:

I'd guess that when your network card wakes up, it "forgets" that it should be in WOL mode. With my computer, WOL doesn't work until I run "ethtool -s eth0 g" (to set "wake on magic packet" on eth0), so I put that in an init script. I'm guessing you've probably done something similar? Try running ethtool manually to re-enable WOL mode and then try suspending again to see if that fixes your problem.

If that works, then you want ethtool to be run whenever your machine comes out of hibernation. (This isn't necessary on my machine, so I haven't tested this, but you should be able to get it to work.) Edit "/etc/hibernate/common.conf" and add a line like

techqbert · n00b Joined: 23 May 2007 Posts: 14

Quick response. Thanks!

That was actually my first thought on the matter- to set ethtool once again. It didn't work before and I just retried resetting ethtool manually by "sudo ethtool eth0 -s wol gp." Still no luck.

Important things to note:

--First wake up works. Second doesn't. Third does (i think even without issuing ethtool before hibernate).
--One thing I noticed is that using vinagre (vnc client) on ubuntu on the first wake up, I don't have to restart the VNC connect.
--When the second packet fails on the second hibernate, I press the power button but I have to restart the VNC connect. Weird. Perhaps this means something. NOTE: this doesn't occur repeatedly.
--Nonetheless, the lights remain on the NIC visible from the outside on the first, second, and third tries.
--The even-numbered hibernates fail regardless of RC_DOWN_INTERFACE in /etc/conf.d/rc or manual "ethtool eth0 -s wol gp" or automatic "ethtool eth0 -s wol gp" in /etc/conf.d/local.start

Any more bright ideas?

MotivatedTea · Posted: Mon Jul 07, 2008 2:07 pm Post subject:

That's kind of weird. What about stopping networking completely, unloading and re-loading your network modules, and then restarting networking? Maybe reloading the driver module will force the card to reset. Also, you said you were using hibernate-ram; have you tried just hibernate (to disk)? I've generally had better luck with suspend-to-disk than suspend-to-ram. Of course, that's slower, and unloading modules means you'd have to reconnect to everything (VNC, etc.) after suspend, unfortunately.

Settings in /etc/conf.d/rc and /etc/conf.d/local.start shouldn't have an effect, since they're only run on boot, not on resuming.

Just a stab in the dark here: what about using ethtool to disable ("-s wol d"), then re-enable WOL?

---
Some quick googling for "via rhine suspend" turned up a discussion on the kernel mailing list about bugs with the via-rhine driver (from your PCI output, I'd guess that's the one for your card?): http://lists.openwall.net/netdev/2008/04/27/28 (also click on "Thread-Next" a few times; they talk about how this might affect WOL).
I don't know if that is something they've fixed or are working on, but it looks like it describes your problem. That discussion is pretty recent, and it looks like it's talking about the 2.6.25 kernel series, so if there is a fix, it may not get into portage for a while. Looks like you might have to do some more googling to find a patch to apply manually (I don't know if there is one). In the meantime, see if re-loading the module works for now.