Bug 19492

Summary: sky2 wake on line stopped working in 2.6.34/2.6.35
Product: Drivers Reporter: Arkadiusz Miskiewicz (arekm)
Component: NetworkAssignee: Jonathan Nieder (jrnieder)
Status: RESOLVED OBSOLETE    
Severity: normal CC: alan, an0nym, jrnieder, nitro, xerofoify
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.1 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: sky2_wol_fix.patch
info.tgz

Description Arkadiusz Miskiewicz 2010-10-02 08:30:10 UTC
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.

05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 15)
        Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 36
        Region 0: Memory at d9000000 (64-bit, non-prefetchable) [size=16K]
        Region 2: I/O ports at 9000 [size=256]
        Expansion ROM at d8000000 [disabled] [size=128K]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data
                Product Name: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
                Read-only fields:
                        [PN] Part number: Yukon 88E8052
                        [EC] Engineering changes: Rev. 1.5
                        [MN] Manufacture ID: 4d 61 72 76 65 6c 6c
                        [SN] Serial number: AbCdEfGb326fd
                        [CP] Extended capability: 01 10 cc 03
                        [RV] Reserved: checksum good, 10 byte(s) reserved
                Read/write fields:
                        [RW] Read-write area: 121 byte(s) free
                End
        Capabilities: [5c] MSI: Enable- Count=1/2 Maskable- 64bit+
                Address: 00000000fee0100c  Data: 41a1
        Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
                LnkCap: Port #3, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <256ns, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                AERCap: First Error Pointer: 1f, GenCap- CGenEn- ChkCap- ChkEn-
        Kernel driver in use: sky2
Comment 1 Andrew Morton 2010-10-04 22:14:30 UTC
(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 ;)
Comment 2 Anonymous Emailer 2010-10-05 00:11:32 UTC
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>
Comment 3 Arkadiusz Miskiewicz 2010-10-09 20:26:48 UTC
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>
Comment 4 Jared 2011-06-26 00:42:34 UTC
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.
Comment 5 Jared 2011-06-26 00:43:07 UTC
Created attachment 63532 [details]
sky2_wol_fix.patch
Comment 7 Jonathan Nieder 2012-08-13 16:48:19 UTC
Was a dmi_match() for the broken systems actually added yet?
Comment 8 Jonathan Nieder 2012-09-07 18:30:47 UTC
(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.
Comment 9 Jonathan Nieder 2012-09-07 18:53:06 UTC
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
Comment 10 Jared 2012-10-01 19:38:17 UTC
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.
Comment 11 xerofoify 2014-06-25 02:00:32 UTC
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
Comment 12 an0nym 2015-01-10 06:22:46 UTC
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).