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

05-19-06 04:14 PM

Re: WOL with nforce4?

1 Attachment(s)

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

06-05-06 11:41 AM

Re: WOL with nforce4?

Quote:

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:

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

01-25-09 02:18 PM

Re: WOL with nforce4?

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.