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:
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: 18.104.22.168. 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
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.