Wake-on-LAN is broken for certain machines

[Grondr]

It seems that Wake-on-LAN is broken for some of my machines and not others.
They're all running 2.6.12-10, and they're all AMD's.

The WORKING case is an MSI K7T Turbo 2 (VIA chipset, Phoenix Award BIOS version
W6330MS V3.0 092601 10:49:47); I can wake this machine from poweroff at all
times. (That machine -still- suffers from bug #22544, where it won't -reboot-
without turning itself off, but that's a different story.)

The FAILING case is a pair of MSI K7N2 Delta-L machines (nVidia chipset, Phoenix
Award BIOS version W6570MS V5.6 110703 10:38:29). The failure mode here is
interesting: If I boot one of them and halt it in the BIOS (e.g., by holding
down DEL on boot), and then turn off the power with the front-panel
soft-power-off switch, I can wake the machine using Wake-on-LAN. However, if I
let the machine boot Ubuntu, then no matter how it powers down (soft-power-off
button, shutdown -h now, or hard power-off via the power-supply switch), I can't
wake it. I'm guessing that the OS has to leave the NIC in the right state
(e.g., waiting for the magic packet to go by, as documented in
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/20213.pdf),
and it's not. The BIOS, on the other hand, is.

[The hard-power-off was followed by turning the hard-power-switch back on with
the BIOS set to -not- power up automatically, of course. All of my other
testing had the BIOS power-on action set to "last state", e.g. if the machine's
soft-power was on when its hard power was cycled, it would turn itself back on.]

I've tried both ether-wake and wakeonlan; see
http://gsd.di.uminho.pt/jpo/software/wakeonlan/mini-howto/wol-mini-howto-3.html
for sources. The former sends an Ethernet frame; the latter sends a UDP packet.

If you're debugging this, note carefully that the VIA-based chipsets will wake
if the magic packet is sent straight to them, -or- if it's broadcast. The
nVidia chips, on the other hand, don't seem to notice the packet unless it's
sent to the broadcast address (-b in ether-wake).

Note also that it's not just this kernel version; the working machine was
running 2.6.12-9 until just a few minutes ago, and I meticulously tested its
wake-on-LAN behavior under that kernel before I took the offered upgrade to -10.
 Nothing about its behavior (neither the Wake-on-LAN, nor the
halts-instead-of-rebooting) changed after booting with the new kernel.

[Grondr (grondr)]

This bug has been open for 8 weeks now with no response whatsoever, including even moving it to some known package. It'd be really nice if this got fixed before the next release came out; does anyone need any more information from me on this?

Thanks!

[Benjamin Mako Hill (mako)]

Does this bug still show up in the newer version of the kernel -- like the kernel in Dapper?

[Ben Collins (ben-collins)]

If this affects dapper, please add a linux-source-2.6.15 target to this bug.

[Grondr (grondr)]

Making the assumption that the 6.06.1 LiveCD actually runs Dapper as its kernel, (*) this bug is still present. I booted from that CD, shut down, and verified that sending WOL packets to the machine does not wake it up. (I did not do the entire boot-to-BIOS-and-shut-down stuff I did when first reporting this, but the machine configuration hasn't changed; if someone would like me to be extra-paranoid about the control case, I can do that, but not until several days from now. I -did- verify that sending WOL packets to a known-working machine did work, so I think this bug is still here.)

[This is unfortunately becoming a critical issue for me, because the machine of mine where WOL worked (a VIA chipset) is being retired because that very chipset has proven to be unreliable when doing heavy multidisk I/O, and will be replaced by one of the machines in my report above for which WOL has never worked for me in Breezy.]

(*) (I just tested it this afternoon, but stupidly didn't actually type uname at a shell while I was running from the LiveCD, and none of my machines will be in a state where I can reboot to verify that for several days---but I'd be really surprised if the LiveCD ran a significantly different kernel than what the LiveCD installs. If it -does-, and you need me to actually install Dapper to retest this bug, let me know and I'll scrounge up a spare disk to do the installation---I'm not quite ready to install Dapper for real on any of the affected machines yet.)

Also---I'm not sure what "add a linux-source-2.6.15 target to this bug" means. Exactly where in the bugtracker UI am I supposed to do this? By clicking on "Edit Description/Tags" in the upper left and adding it as a tag? Somewhere else?

[Erwan Hamon (erwan-hamon)]

This bug is still open with feisty kernel 2.6.20.
Also, duplicated with: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/44170

[sylverpyro (sylverpyro)]

I can confirm that this affects Dapper and Feisty.

The Dapper (linux 2.6.15-26) machine is a AMD 64 x2 3200 series, and the Feisty machine (linux 2.6.20-16) is a AMD 64 x2 3800 series. Neither are capable of WOL (have not tried the hack mentioned in bug 44170).

As a note, my Pentium 4 Feisty box is capable of WOL.