WOL with nforce4?

[mathog]

I mistakenly posted this first in the "Nvidia linux forum", which seems to be all about graphics.

This is apparently a forcedeth issue with nforce4 - WOL doesn't work on a machine where WOL does work from Windows XP. More details here:

http://www.nvnews.net/vbulletin/showthread.php?t=70345

Any suggestions on how to get WOL working from Linux on this box?

Thanks

[mathog]

I should add that I also tried to enable this with Donald Becker's pci-config program.

pci-config -#11 -S

was run just before halt. It was followed by

pci-config -#11

which showed D3, and then immediately by halt. The machine went down but would not boot WOL afterwards.

I also tried booting to safe mode, running pci-config -#11 -S, and then
looking at these lines from pci-config -#11

Power management entry ver. 2: Capabilities fe02, Ctrl 0100, Event 0000.
Power state D0.

before and after a magic packet was sent. Nothing changed in the Ctrl mask which
suggests to me that the NIC wasn't configured right or that I'm doing something
else wrong.

Clearly the hardware is fine since WOL works exactly as it should when the machine shuts down from XP.

Suggestions???

[mathog]

We'll I'm really starting to run out of ideas.

I verified again that

ethtool -s eth0 wol g
ethtool -s eth0 wol d

do not toggle any bits in the PCI space by using:

lspci -xxx

and using diff on the output. So that seems to be pretty clearly a bug in forcedeth,
since I assume that the two ethtool commands should be equivalent to:

setpci -s 00:0a.0 48.W=0100
setpci -s 00:0a.0 48.W=0000

which do in fact change the relevant bit shown by lspci (with -vv) to
"PME-Enable+" or "PME-Enable-", respectively.

The machine's kernel was also upgraded to the lastest release: 2.6.16.16. Unfortunately following a poweroff from that kernel WOL still didn't work.

Finally, after this latest kernel was booted with "acpi=off" I verified with pci-config that
the card was CTRL=0103 (PME-ENABLED, state D3) and /sbin/halt
left the machine running. After powering off with the front panel button the
machind still wouldn't do a WOL. This experiment pretty much
takes acpi out of the picture.

Still, the machine does a WOL just fine following a shutdown from XP.
It does not do a WOL when it is first plugged in though, it has to run XP
first.

So somewhere or other there is a bit set wrong on linux that's breaking WOL, presumably in the PCI space of the ethernet PCI device. Can't anybody tell me what that bit might be?
The relevant part of an lspci -xxx is attached.

Thanks.

[mathog]

Originally Posted by mathog

We'll I'm really starting to run out of ideas.

This problem is due to a bug in the forcedeth driver. It was reported on kernel.org
and that thread is here:

http://bugzilla.kernel.org/show_bug.cgi?id=6604

long story short, at linux close forcedeth 0.56 (and unknown number of versions
earlier) wrote the MAC back to the device in the reverse order. So 01:02:03:04:05
became 05:04:03:02:01. The nforce4 board will WOL if the magic packet is sent
to the reversed MAC instead of the correct MAC, assuming that

ethtool -s eth0 wol g

has been issued before poweroff. The forcedeth driver is being modified to fix this
problem. In the meantime, if you have an older version of forcedeth and WOL isn't
working try sending the magic packet to the reversed MAC.

[farvardin]

thank you for posting about this issue and for finding a workaround!

I had this problem too, and what is strange is I could WOL my computer without problem a few months ago (on a linux kernel higher than 2.6.16), and then it stopped working. Using a reversed MAC solved this issue.

My card is nVidia Corporation MCP51 Ethernet Controller