(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Sat, 2 Oct 2010 08:30:14 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=19492
> 
>            Summary: sky2 wake on line stopped working in 2.6.34/2.6.35
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 2.6.34, 2.6.35
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Network
>         AssignedTo: drivers_network@kernel-bugs.osdl.org
>         ReportedBy: arekm@maven.pl
>         Regression: Yes
> 

A regression.

> sky2 WOL feature stopped working in 2.6.34 kernel. It was working fine in
> 2.6.33. ethtool 2.6.35 (and some earlier version before).
> 
> # ethtool -s eth0 wol g
> # ethtool eth0|grep Wake
>         Supports Wake-on: pg
>         Wake-on: g
> # ethtool -i eth0
> driver: sky2
> version: 1.28
> firmware-version: N/A
> bus-info: 0000:05:00.0
> # poweroff
> 
> When googling for solution I found /sys/class/net/eth0/device/power/wakeup
> which contains "disabled" before AND after I run ethtool. So I echoed
> "enabled"
> there, too but it didn't help. The machine doesn't wake up on magick packet.
> 
> ...
>

I can't immediately see any recent changes to the driver in that area
apart from "ethtool: Change ethtool_op_set_flags to validate flags". 
Perhaps you could run

	strace -f ethtool -s eth0 wol g

and see if it's getting an error when setting WOL mode.  If so, ethtool
is broken ;)

Reply-To: shemminger@vyatta.com

On Mon, 4 Oct 2010 15:14:04 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> 
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> On Sat, 2 Oct 2010 08:30:14 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
> 
> > https://bugzilla.kernel.org/show_bug.cgi?id=19492
> > 
> >            Summary: sky2 wake on line stopped working in 2.6.34/2.6.35
> >            Product: Drivers
> >            Version: 2.5
> >     Kernel Version: 2.6.34, 2.6.35
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: Network
> >         AssignedTo: drivers_network@kernel-bugs.osdl.org
> >         ReportedBy: arekm@maven.pl
> >         Regression: Yes
> > 
> 
> A regression.
> 
> > sky2 WOL feature stopped working in 2.6.34 kernel. It was working fine in
> > 2.6.33. ethtool 2.6.35 (and some earlier version before).
> > 
> > # ethtool -s eth0 wol g
> > # ethtool eth0|grep Wake
> >         Supports Wake-on: pg
> >         Wake-on: g
> > # ethtool -i eth0
> > driver: sky2
> > version: 1.28
> > firmware-version: N/A
> > bus-info: 0000:05:00.0
> > # poweroff
> > 
> > When googling for solution I found /sys/class/net/eth0/device/power/wakeup
> > which contains "disabled" before AND after I run ethtool. So I echoed
> "enabled"
> > there, too but it didn't help. The machine doesn't wake up on magick
> packet.
> > 
> > ...
> >
> 
> I can't immediately see any recent changes to the driver in that area
> apart from "ethtool: Change ethtool_op_set_flags to validate flags". 
> Perhaps you could run
> 
>       strace -f ethtool -s eth0 wol g
> 
> and see if it's getting an error when setting WOL mode.  If so, ethtool
> is broken ;)
> 

There have been changes in the core power management layer, that is
where I would look. Usually the problem is the incorrectly BIOS marks the device
as unable to do PM. Probably the old kernel ignored the BIOS, and newer
kernels look at it more closely?

Last WoL changes were to make driver follow vendor driver which happened
between 2.6.33 and 2.6.34

commit 5f8ae5c537d937bab9cfeb83a30a9b670c3cfb35
Author: stephen hemminger <shemminger@vyatta.com>
Date:   Fri Feb 12 06:57:59 2010 +0000

    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>

commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511
Author: stephen hemminger <shemminger@vyatta.com>
Date:   Fri Feb 12 06:58:00 2010 +0000

    sky2: dont enable PME legacy mode
    
    This bit is not changed by vendor driver, and should be left alone.
    The documentation implies this a debug bit.
      0 = WAKE# only asserted when VMAIN not available
      1 = WAKE# is depend on wake events and independent of VMAIN.
    
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

On Tuesday 05 of October 2010, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=19492

Reverting commit below on my 2.6.35.7 makes my sky2 waking up properly on 
magic packet.

No new bios for this mainboard (latest one is from 2006).

> commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511
> Author: stephen hemminger <shemminger@vyatta.com>
> Date:   Fri Feb 12 06:58:00 2010 +0000
> 
>     sky2: dont enable PME legacy mode
> 
>     This bit is not changed by vendor driver, and should be left alone.
>     The documentation implies this a debug bit.
>       0 = WAKE# only asserted when VMAIN not available
>       1 = WAKE# is depend on wake events and independent of VMAIN.
> 
>     Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>

Has there been any update on this?  If not, can someone please look into fixing it?  It's still a problem as of 2.6.38, and the fix suggested by Arkadiusz nearly a year ago still applies.

I'm attaching a patch that undoes commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511 and restores the WOL functionality that was broken by this change.

Thanks.

Created attachment 63532 [details]
sky2_wol_fix.patch

Reference: http://thread.gmane.org/gmane.linux.kernel/1270776/focus=1271677
Reference: http://bugs.debian.org/671788

Was a dmi_match() for the broken systems actually added yet?

(In reply to comment #7)
> Was a dmi_match() for the broken systems actually added yet?

Reopening and claiming. I encourage anyone experiencing this bug to attach their DMI information (e.g., by attaching "dmesg" output from booting). "lspci -vv" and "acpidump" output would be interesting as well.

Currently we know about the following system for which the sky2.legacy_pme=1 parameter helps:

 Manufacturer: ASUSTeK Computer INC.
 Product Name: P5LD2
 BIOS Vendor: American Megatrends Inc.
 BIOS Version: 2002
 BIOS Release Date: 08/28/2009
 Ethernet controller: 11ab:4362, subsystem 1043:8142

Knut Petersen also mentioned "Two ASUSTek P5* mainboards with AMI BIOSes, two AOpen i915G* mainboards with Award/Phoenix BIOSes" with the problem and Stephen Hemminger explained that it looks like "the BIOS has configured the device to disable power management", but we don't seem to have any more detail than that.

From http://thread.gmane.org/gmane.linux.kernel/1252986, http://thread.gmane.org/gmane.linux.kernel/1210032, http://article.gmane.org/gmane.linux.kernel/1082837,
http://article.gmane.org/gmane.linux.kernel/370600:

 Board vendor: AOpen
 Board name: i915GMm-HFS
 BIOS: 6.00 PG 09/14/2005 (Award BIOS)
 Ethernet controller: 11ab:4362, subsystem a0a0:0506

Created attachment 81801 [details]
info.tgz

Sorry for the delay - this computer was offline for a while and I only recently had a chance to test the new legacy_pme setting.  It does work (thank you for fixing this), and I can confirm that it is required for this motherboard.  Basic info from dmidecode and lspci:

Base Board Information
    Manufacturer: ASUSTeK Computer INC.
    Product Name: P5B-Deluxe
BIOS Information
    Vendor: American Megatrends Inc.
    Version: 1238
    Release Date: 09/30/2008
Ethernet
    11ab:4364 (rev 12), subsystem 1043:81f8

Attached is the requested dmesg and lspci -vv output from this computer.  I don't have acpidump command.

Please let me know if I can provide any additional info.

This bug is obsolete as it's over 2 years old. Please tell a newer kernel to see
if this bug is still valid.
Thanks Nick

As of kernel 3.17.7 (specifically Fedora's 3.17.7-200.fc20.x86_64) legacy_pme=1 workaround works for me (same Asus P5B Deluxe MB as Jared's).