According to my tests this doesn't seem to fix the problem:

--- sky2.c.orig	2009-07-13 13:16:56.192739689 +0200
+++ sky2.c	2009-07-13 13:17:10.407739353 +0200
@@ -4730,8 +4730,7 @@
 	if (wol)
 		sky2_power_aux(hw);
 
-	pci_enable_wake(pdev, PCI_D3hot, wol);
-	pci_enable_wake(pdev, PCI_D3cold, wol);
+	pci_wake_from_d3(pdev, wol);
 
 	pci_disable_device(pdev);
 	pci_set_power_state(pdev, PCI_D3hot);


Anyway I think it's required to have it fixed.

Ref:
http://lkml.indiana.edu/hypermail/linux/kernel/0808.2/0873.html

Reassigned to Stephen.

The same behavior is confirmed also with suspend.

Steps to Reproduce:
1. ethtool -s eth0 wol g
2. suspend

Actual results:
The ethernet card led turns off.

Expected results:
The ethernet card should remain on (link led on) waiting for the magic packet.

Trying to let wol work with suspend as first step is faster for test and debug purpose as it doesn't require a full shutdown/boot cycle.

I think it will work if you enable wake-up using the /sys/devices/.../power/wakeup interface (i.e. echo 'enabled' to the /sys/devices/.../power/wakeup file of your device).

Can you attach a dmesg output from this machine, please?

(In reply to comment #4)
> I think it will work if you enable wake-up using the
> /sys/devices/.../power/wakeup interface (i.e. echo 'enabled' to the
> /sys/devices/.../power/wakeup file of your device).
> 
> Can you attach a dmesg output from this machine, please?

The /sys/devices/.../power/wakeup is managed automatically by the module:

# ethtool eth0 | grep -i wake
        Supports Wake-on: pg
        Wake-on: d
# cat /sys/class/net/eth0/device/power/wakeup 
disabled
# ethtool -s eth0 wol g
# cat /sys/class/net/eth0/device/power/wakeup 
enabled

Created attachment 22443 [details]
dmesg

dmesg output.

Created attachment 22454 [details]
debug patch

Please try to suspend with this patch applied and post dmesg output generated right after that.

Created attachment 22455 [details]
dmesg-suspend-debug.out

dmesg output after suspend with debug patch.

# dmesg-suspend-debug.out
sky2 0000:04:00.0: wol: 32

The dmesg output you've just attached shows what the problem is.  Namely, the device has no ACPI context which usually is necessary to make WoL, and generally wake-up from a system sleep state, work.

Perhaps there is an option to use PCI Express PME interrupts for waking up your system, please check in the BIOS setup.

Thanks for the hint, I'm going to check the bios asap. I'd like to point out (as I said in the description) that windows (vista) is able to make wol work with this very bios setup.

Created attachment 22458 [details]
lspci.out

adding lspci -vvv output

Well, perhaps Windows sets up PCIe PME interrupts as wake-up interrupts.  We don't do that at the moment.

Whatever does the wake-up, it surely is not ACPI.

(In reply to comment #12)
> Well, perhaps Windows sets up PCIe PME interrupts as wake-up interrupts.  We
> don't do that at the moment.
> 
> Whatever does the wake-up, it surely is not ACPI.

The motherboard is an abit ip35:

http://file.abit.com.tw/pub/download/manual/english/ip35_ip35-e.zip

In the bios tab "Power Management Setup" the options are:

  CPI Suspend Type           S3(Suspend To RAM) Item Help
  - Resume By USB from S3    Enabled
  Power Button Function      Instant-Off
  Wake Up by PME# of PCI     Enabled
  Wake Up by WAKE# of PCIe   Enabled
  Wake Up by Onboard LAN     Enabled
  Wake Up by Alarm           Disabled
  - Date(of Month) Alarm      0
  - Time(hh:mm:ss) Alarm      0 : 0 : 0
  Power On Function          Button Only
  - KB Power On Password     Enter
  - Hot Key Power On         Ctrl-F1
  Restore On AC Power Loss   Power Off

Do you think the WAKE# option is the wake-up interrupt you were referring to? (PS. I'm using the Onboard LAN).
The wake-up interrupts are not supported by the sky2 module or generally by the kernel?
Do you think there is anything else I can try to make the wol work?

The settings look fine and the messages printed by the kernel during suspend also look correct.  There's nothing obviously suspicious in there.

Obviously your network adapter is apparently not handled by ACPI, but don't know exactly _how_ it's handled under Vista.

The PCIe PME interrupts are independent of device drivers and the kernel doesn't use them as wake-up interrupts at all.

I have an Asus board with sky2-compatible adapter and it's sufficient to enable something like 'Wake Up by WAKE# of PCIe' for the WoL to work on it IIRC.

Has this been fixed or there is a workaround?

I didn't find any fix or workaround yet.

Please try 2.6.32-rc5 (or later).  There's an important PCI wake-up fix in there.

I tried 2.6.32-rc5 from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc5/

And saw no change. :(

ged@quadcore:~$ uname -a
Linux quadcore 2.6.32-020632rc5-generic #020632rc5 SMP Fri Oct 16 09:06:17 UTC 2009 x86_64 GNU/Linux

ged@quadcore:~$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
HUB0	  S5	 disabled  pci:0000:00:0a.0
XVR0	  S5	 disabled  pci:0000:00:0b.0
XVR1	  S5	 disabled  pci:0000:00:0c.0
XVR2	  S5	 disabled  pci:0000:00:0d.0
UAR1	  S5	 disabled  pnp:00:08
USB0	  S3	 disabled  pci:0000:00:04.0
USB2	  S3	 disabled  pci:0000:00:04.1
AZAD	  S5	 disabled  pci:0000:00:09.0
MMAC	  S5	 disabled

Same result here with kernel-2.6.32-0.33.rc5.git1.fc13.
The wake-up still doesn't work.

Garth what motherboard do you have?
Can you attach your dmesg and lspci -vvv output thanks.

Garth, /proc/acpi/wakeup is meaningless in this case.

Please attach dmesg including a suspend/resume cycle with WoL enabled (from 2.6.32-rc5).

Created attachment 23639 [details]
lspci -vvv and dmesg from 2 runs

I'm attaching lspci -vvv output from the machine (hostname "quadcore"), along with 2 dmesg runs and a diff -y of the dmesg runs (the machine has never and still can't suspend/resume, it suspends but fails to resume - blinking text cursor + solid hard drive light).

The motherboard is a eVGA 112-CK-NF77-A1 ( http://www.newegg.com/Product/Product.aspx?Item=N82E16813188021 ) - Nvidia chipset, Core2 Quad, with a Marvell Yukon Gig-e PCI-e onboard NIC.

Sorry my understanding (from looking a different Core2 Duo machine "mythtv" with different mobo+NIC that does do WoL) was without the /proc/acpi/wakeup entry, it wouldn't wake up no matter what ethtool says the WoL state is... here is the ethtool WoL wake settings:
root@quadcore:/tmp# ethtool eth0 | grep -i wake
	Supports Wake-on: pg
	Wake-on: g

"quadcore" doesn't respond to WoL either from a power-off start or from suspend btw.

Let me know if there's anything else I can provide or try to assist.

Cheers,

-G

First, does hibernation work on this machine?

Second, please try to run

echo core > /sys/power/pm_test
echo mem > /sys/power/state

on this machine (that should simulate a suspend-resume cycle without actually suspending the system; it runs the suspend sequence, waits for 5 seconds and runs the resume sequence) and see if that works.

Created attachment 23686 [details]
Dmesg output from pm_test run on Quadcore

This is the dmesg from the pm_test...

Created attachment 23687 [details]
Dmesg output from hibernate run on Quadcore

Hibernate started from Gnome shutdown menu... looks like it crashes X down to ascii mode, but the machine stays up and running (can ssh into it).

In the latest sk98lin driver (version 10.84.3.3) wake on lan works as expected.

I think we can assume now that the problem is in the sky2 driver and not in something else.

The sk98lin source code can be downloaded from:

http://www.marvell.com/support.html

# modinfo sk98lin

filename:       /lib/modules/2.6.31.12-174.2.3.fc12.x86_64/extra/sk98lin.ko
version:        10.84.3.3
license:        GPL
description:    Marvell/SysKonnect Yukon Ethernet Network Driver
author:         Mirko Lindner <support@marvell.com>
srcversion:     9A05D55A65EE118E772F30E

# ethtool eth0 | grep Wake
	Supports Wake-on: g
	Wake-on: g

From the sk98lin.txt file:

9  Wake on Lan Support
======================

The sk98lin supports wake up from suspend mode with MagicPacket.
Wake on Lan support is enabled by default. To disable it, use the ethtool.

NOTE 1: WOL support has to be enabled in the BIOS and in the kernel.

NOTE 2: Refer to the kernel documentation for additional requirements
        regarding WOL support.

Any chance to test 2.6.33-rc6?  There are a couple of fixes in this area in there.

I did a quick test:

# uname -r
2.6.33-0.26.rc6.git1.fc13.x86_64

# cat /sys/module/sky2/version 
1.26

# ethtool -s eth0 wol g
# ethtool eth0 | grep Wake
	Supports Wake-on: pg
	Wake-on: g

It's still not working.

Could you please check out the Marvell driver? Maybe you could quickly understand what is missing from sky2.

$ wget http://extranet.marvell.com/drivers/files/install_v10.84.3.3.tar.tar
$ tar -xvf install_v10.84.3.3.tar.tar
$ cd DriverInstall
$ tar -xvjf sk98lin.tar.bz2

$ grep -r WakeFrom .
./common/h/skgeinit.h:		SK_U32 WakeFromS5:1;
./common/h/skgeinit.h:	SK_BOOL	WakeFromShutdownEn;	/* Wake From Shutdown (S5) Enable */
./common/skgeinit.c:		pCfgData->WakeFromShutdownEn	= (SK_BOOL)pCfgVal->fields.WakeFromS5;

In the latest sky2 version wol is still not working but I noticed something that might be relevant:

# cat /sys/module/sky2/version 
1.26
# echo -n core > /sys/power/pm_test
# ethtool -s eth0 wol d
# echo -n mem > /sys/power/state

The link led just turns off and on when the pc resumes.

# ethtool -s eth0 wol g
# echo -n mem > /sys/power/state

The link led turns off and on. After few seconds it turns off and on again when the pc resumes.

I'm not 100% sure but this might mean that it could be working.
What's the difference between the "echo -n mem > /sys/power/state" test and a real shutdown/suspend?

I noticed that in sk98lin a shutdown is treated as a suspend:

static void sk98lin_shutdown(struct pci_dev *pdev) {
        sk98lin_suspend(pdev, PMSG_SUSPEND);
}

Did anyone investigated further on what sk98lin is doing?
The functions sk98lin_suspend and SkEnableWOMagicPacket could reveal something.
Sadly I'm not sure I can fully understand them.

The bug can be reproduced also on an ASUS P5N-E SLI.

Created attachment 24976 [details]
sky2-wol.patch

I finally found the fix for this bug (patch attached).
The problem was quite silly: Y2_HW_WOL_ON and Y2_HW_WOL_OFF were used backward.
The hint came from the sk98lin driver (skge.c:1407):

static void SkEnableWOMagicPacket(
SK_AC         *pAC,      /* Adapter Control Context          */
SK_IOC         IoC,      /* I/O control context              */
SK_MAC_ADDR    MacAddr)  /* MacAddr expected in magic packet */
{
[...]
    SK_OUT16(IoC, B0_CTST, Y2_HW_WOL_OFF);
} /* SkEnableWOMagicPacket */

I don't know the reason (maybe initial mislabeling?) but you have to use the Y2_HW_WOL_OFF value to enable WOL.

According to the sk98lin code this fix isn't something specific to 88E8056: it's required for all Yukon adapters.
I really can't understand why nobody noticed it.
Who reported that WOL was successfully working before?

Please can anyone verify the patch, commit and close? Thanks.

Hmm.  In my kernel sources (2.6.33-rc7) the relevant piece of code is:

	if (hw->chip_id == CHIP_ID_YUKON_EC_U ||
	    hw->chip_id == CHIP_ID_YUKON_EX ||
	    hw->chip_id == CHIP_ID_YUKON_FE_P)
		sky2_write32(hw, B0_CTST, wol ? Y2_HW_WOL_ON : Y2_HW_WOL_OFF);

	device_set_wakeup_enable(&hw->pdev->dev, wol);

so I guess the bug should not be present in that kernel?

The bug is still present in the kernel.
Please read carefully comment #30.

If in doubt just patch the source:

  $ patch sky2.c < sky2-wol.patch

Created attachment 24983 [details]
sky2: fix wol

So this patch should work on your box as well.  Can you try it, please?

The Y2_HW_WOL_OXX bits control the "Plug in Go" functionality of the
chip. It looks like if this bit is set, then a different set of configuration parameters is loaded out of SPI flash when power transitions from Vmain to Vaux in D3.

The sky2 driver does not change or manage SPI flash directly, it is done by firmware or BIOS.

The vendor driver is a confusing mess and in some cases it does enable it, and other cases not.

Well, so do you think the problem reported by Federico is a firmware/BIOS issue?

It is a firmware/BIOS issue, but it probably can be worked around in the driver.

Rafael I had no time to check if your fix actually works but I'm pretty sure it does since it basically swaps the Y2_HW_WOL_ON and Y2_HW_WOL_OFF values.

I think my fix is better because if we start to mess around swapping macro values and breaking the correspondence between sky2 and sk98lin we'll be soon lost: it was very helpful to relay on similar macros with similar values during the debug.

I'm also pretty sure it was not mislabeled:

  $ find -name \*.c | xargs grep -B 1 -n Y2_HW_WOL_O
  ./skge.c-1406-
  ./skge.c:1407: SK_OUT16(IoC, B0_CTST, Y2_HW_WOL_OFF);
  --
  ./skgeinit.c-2686- /* enable HW WOL */
  ./skgeinit.c:2687: SK_OUT16(IoC, B0_CTST, Y2_HW_WOL_ON);
  --
  ./skgeinit.c-3244- /* disable HW WOL */
  ./skgeinit.c:3245: SK_OUT16(IoC, B0_CTST, Y2_HW_WOL_OFF);

We could prefix a comment to make it clear:

/* IMPORTANT: to *enable* Wake-On-Lan you need to use Y2_HW_WOL_OFF */
sky2_write32(hw, B0_CTST, wol ? Y2_HW_WOL_OFF : Y2_HW_WOL_ON);

Stephen, I don't know the yukon firmware/BIOS details and I agree with you: the vendor driver is a confusing mess.
I disagree on the fact that the use of Y2_HW_WOL_O(N|FF) is confusing: it is used only 3 times and at the end of SkEnableWOMagicPacket it was clearly set to Y2_HW_WOL_OFF. I don't think it's a firmware/BIOS workaround, maybe it's just a required parameter to be set.

I have the official documents on most of the chip variants, so the definition of the WOL bits is clear. What isn't clear is what the firmware does.

So Stephen could you verify, commit and close?

Can someone please commit the fix to the main tree?

I have the same problem with a Marvell 88E8071. I tried Rafael's patch on a 2.6.33 kernel and now it works.

I have also tried the stock Fedore 13 kernel (2.6.34) and the bug is still present.

It would be very kind if the fix would be in the main line.

(In reply to comment #40)
> Can someone please commit the fix to the main tree?
> 
> I have the same problem with a Marvell 88E8071. I tried Rafael's patch on a
> 2.6.33 kernel and now it works.

Good to know that Rafael's patch is working too.
I still prefer mine as I explained in comment #37.

> Rafael's patch
> I have also tried the stock Fedore 13 kernel (2.6.34) and the bug is still
> present.

I confirm this, you can check:

http://bugzilla.redhat.com/show_bug.cgi?id=510693

It's 4 months that I'm rebuilding the patched sky2 module due the lack of interest in resolving this bug in main line.

Fixed in 2.6.34

Author: stephen hemminger <shemminger@vyatta.com>  2010-02-11 22:57:59
Committer: David S. Miller <davem@davemloft.net>  2010-02-12 16:21:00
Parent: 8b05543129a5f216e08625e947a16b844bc4766d (sky2: fix sparse warning)
Child:  87b09f1f25cd1e01d7c50bf423c7fe33027d7511 (sky2: dont enable PME legacy mode)
Branches: master, remotes/origin/master
Follows: v2.6.33-rc5
Precedes: v2.6.34-rc1

    sky2: WoL changes
    
    Change Wake On Lan code to be similar to vendor driver. The definition
    of Y2_HW_WOL_ON is confusing; what it means is transition to firmware SPI
    setting when doing power change.
    
    Since same code is done for both shutdown and suspend, use common
    code path.
    
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

I just tested kernel-2.6.34.6-47.fc13.x86_64 and WOL is now working as expected.