r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

[Daniel Drake]

Hi,

On the Acer laptop models Aspire ES1-533, Aspire ES1-732, PackardBell
ENTE69AP and Gateway NE533, we are seeing a problem where the system
immediately wakes up after being put into S3 suspend.

This problem has been seen on all kernel versions that we have tried,
including 4.14-rc3.

After disabling wakeup sources one by one, we found that the r8169
ethernet is responsible for these wakeups here, the hardware is:

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
    Subsystem: Acer Incorporated [ALI] Device 1084
    Flags: bus master, fast devsel, latency 0, IRQ 124
    I/O ports at 1000 [size=256]
    Memory at 91204000 (64-bit, non-prefetchable) [size=4K]
    Memory at 91200000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [70] Express Endpoint, MSI 01
    Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Virtual Channel
    Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
    Capabilities: [170] Latency Tolerance Reporting
    Capabilities: [178] L1 PM Substates
    Kernel driver in use: r8169

This driver enables WOL by default. The system wakes up immediately
when it is put into S3 suspend, even if there is no ethernet cable
plugged in.

The problem was also reproduced with the r8168 vendor driver, however
it does not occur under Windows, where we can suspend the system just
fine and also wake it up with a magic WOL packet.

Further investigation takes us into ACPI-land. The complete DSDT is here:
https://gist.github.com/dsd/62293b6d8c30a5204128709813a55ffb

Both Windows and Linux associate PCI0.RP05.PXSX with this device, so
let's consider this part of the DSDT:

  Device (RP05)
  {
      Method (_ADR, 0, NotSerialized)  // _ADR: Address
      {
          If (RPA5 != Zero)
          {
              Return (RPA5) /* \RPA5 */
          }
          Else
          {
              Return (0x00130002)
          }
      }

      Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
      {
          Return (GPRW (0x09, 0x04))
      }

      Device (PXSX)
      {
          Name (_ADR, Zero)  // _ADR: Address
          Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
          {
              0x08,
              0x04
          })
      }

  }

RP05 corresponds to
00:13.0 PCI bridge: Intel Corporation Device 5ada (rev fb)

I am not familiar with this subdevice approach, where PXSX (with
address 0) is detected as a child of the PCI bridge, however both
Windows and Linux associate PXSX with the ethernet device, so I guess
it is correct.

Now to focus on the _PRW power resource for wakeup. The PXSX
(ethernet) device says that it will wake up the system using GPE08.
However if you look at the _L08 GPE08 event handler, you will see that
it does not do anything related to RP05/PXSX (it instead calls into
RP02, which does not even physically exist on this platform) -
suspicious.

On the other hand, the RP05 (root port) _PRW says it will wake up the
system via GPE09, and the _L09 handler at least has one codepath which
could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup.

But in testing:
 - If GPE08 is enabled as a wakeup source, the system will always wake
up as soon as it goes to sleep
 - I have never seen a wakeup on GPE09
 - Disabling GPE08 and all other GPE wakeups, the system sleeps fine,
and Wake-on-LAN works fine too

So in summary, the messy situation is that the DSDT suggests that
GPE08 will be used for ethernet wakeups, however that GPE seems to
fire instantly during suspend, and actually wake-on-LAN does not
appear to use ACPI GPEs to wake the system it all - it must use some
other mechanism. Windows is for some reason ignoring the ethernet
device _PRW information so it does not suffer this issue.

Does anyone have suggestions for how Linux should work with this?

What logic should we use to ignore the _PRW in this case, or how can
we quirk it?

Also, is there a standard behaviour defined for ethernet drivers
regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
if it believes the hardware is capable of it, but other ethernet
drivers seem to default to WOL off. (I don't expect users of the
affected consumer laptops here to care about WOL support.)

Daniel

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

[Francois Romieu]

Daniel Drake <drake@endlessm.com> :
[...]
> Also, is there a standard behaviour defined for ethernet drivers
> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
> if it believes the hardware is capable of it,

If so it isn't its designed behavior.

The r8169 driver does not enable specific WoL event source (unicast packet,
link, etc.). It should keep the current settings unless one of those holds:
- explicit wol config from userspace (obviously :o) )
- runtime pm requires different settings to resume. The change should
  be temporary (save before suspend, restore after resume).

The device is supposed to require both an event source + Config1.PMEnable.

A problem may happen if some event source bit is already set while
Config1.PMEnable is not. The driver has been forcing Config1.PMEnable
since 5d06a99f543e734ceb53bbc9e550537be97f0c49. One may thus experience
transition from inconsistent wol settings to enabled ones (if you want
to dig it, check beforehand if Config1.PMEnable is really read-write or
hardwired to 1).

Whatever it seems rather orthogonal with your wake over wifi style instant
resume symptom.

-- 
Ueimor

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

[Daniel Drake]

On Fri, Oct 6, 2017 at 8:16 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Daniel Drake <drake@endlessm.com> :
> [...]
>> Also, is there a standard behaviour defined for ethernet drivers
>> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
>> if it believes the hardware is capable of it,
>
> If so it isn't its designed behavior.
>
> The r8169 driver does not enable specific WoL event source (unicast packet,
> link, etc.). It should keep the current settings unless one of those holds:
> - explicit wol config from userspace (obviously :o) )
> - runtime pm requires different settings to resume. The change should
>   be temporary (save before suspend, restore after resume).
>
> The device is supposed to require both an event source + Config1.PMEnable.
>
> A problem may happen if some event source bit is already set while
> Config1.PMEnable is not. The driver has been forcing Config1.PMEnable
> since 5d06a99f543e734ceb53bbc9e550537be97f0c49. One may thus experience
> transition from inconsistent wol settings to enabled ones (if you want
> to dig it, check beforehand if Config1.PMEnable is really read-write or
> hardwired to 1).

The code in question here is in rtl_init_one():

    device_set_wakeup_enable(&pdev->dev, tp->features & RTL_FEATURE_WOL);

This enables wakeups regardless of current WOL settings, as long as
the hardware supports the WOL feature.
Should we remove this line? rtl8169_set_wol() looks like it will do
the right thing here if WOL is later enabled.

Daniel

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

[Rafael J. Wysocki]

On Thu, Oct 5, 2017 at 10:57 AM, Daniel Drake <drake@endlessm.com> wrote:
> Hi,
>
> On the Acer laptop models Aspire ES1-533, Aspire ES1-732, PackardBell
> ENTE69AP and Gateway NE533, we are seeing a problem where the system
> immediately wakes up after being put into S3 suspend.
>
> This problem has been seen on all kernel versions that we have tried,
> including 4.14-rc3.
>
> After disabling wakeup sources one by one, we found that the r8169
> ethernet is responsible for these wakeups here, the hardware is:
>
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
>     Subsystem: Acer Incorporated [ALI] Device 1084
>     Flags: bus master, fast devsel, latency 0, IRQ 124
>     I/O ports at 1000 [size=256]
>     Memory at 91204000 (64-bit, non-prefetchable) [size=4K]
>     Memory at 91200000 (64-bit, non-prefetchable) [size=16K]
>     Capabilities: [40] Power Management version 3
>     Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
>     Capabilities: [70] Express Endpoint, MSI 01
>     Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
>     Capabilities: [100] Advanced Error Reporting
>     Capabilities: [140] Virtual Channel
>     Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
>     Capabilities: [170] Latency Tolerance Reporting
>     Capabilities: [178] L1 PM Substates
>     Kernel driver in use: r8169
>
> This driver enables WOL by default. The system wakes up immediately
> when it is put into S3 suspend, even if there is no ethernet cable
> plugged in.
>
> The problem was also reproduced with the r8168 vendor driver, however
> it does not occur under Windows, where we can suspend the system just
> fine and also wake it up with a magic WOL packet.
>
> Further investigation takes us into ACPI-land. The complete DSDT is here:
> https://gist.github.com/dsd/62293b6d8c30a5204128709813a55ffb
>
> Both Windows and Linux associate PCI0.RP05.PXSX with this device, so
> let's consider this part of the DSDT:
>
>   Device (RP05)
>   {
>       Method (_ADR, 0, NotSerialized)  // _ADR: Address
>       {
>           If (RPA5 != Zero)
>           {
>               Return (RPA5) /* \RPA5 */
>           }
>           Else
>           {
>               Return (0x00130002)
>           }
>       }
>
>       Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
>       {
>           Return (GPRW (0x09, 0x04))
>       }
>
>       Device (PXSX)
>       {
>           Name (_ADR, Zero)  // _ADR: Address
>           Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
>           {
>               0x08,
>               0x04
>           })
>       }
>
>   }
>
> RP05 corresponds to
> 00:13.0 PCI bridge: Intel Corporation Device 5ada (rev fb)
>
> I am not familiar with this subdevice approach, where PXSX (with
> address 0) is detected as a child of the PCI bridge, however both
> Windows and Linux associate PXSX with the ethernet device, so I guess
> it is correct.
>
> Now to focus on the _PRW power resource for wakeup. The PXSX
> (ethernet) device says that it will wake up the system using GPE08.
> However if you look at the _L08 GPE08 event handler, you will see that
> it does not do anything related to RP05/PXSX (it instead calls into
> RP02, which does not even physically exist on this platform) -
> suspicious.

Well, it is broken, but that doesn't matter for wakeups from S3.

> On the other hand, the RP05 (root port) _PRW says it will wake up the
> system via GPE09, and the _L09 handler at least has one codepath which
> could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup.

Which can only happen in the S0 system state.

> But in testing:
>  - If GPE08 is enabled as a wakeup source, the system will always wake
> up as soon as it goes to sleep

What exactly do you mean by "enabled as a wakeup source"?

>  - I have never seen a wakeup on GPE09
>  - Disabling GPE08 and all other GPE wakeups, the system sleeps fine,
> and Wake-on-LAN works fine too

Again, what exactly do you mean by "Disabling GPE08 and all other GPE
wakeups"?  That is, what exactly do you do to disable/enable them?

> So in summary, the messy situation is that the DSDT suggests that
> GPE08 will be used for ethernet wakeups, however that GPE seems to
> fire instantly during suspend, and actually wake-on-LAN does not
> appear to use ACPI GPEs to wake the system it all - it must use some
> other mechanism. Windows is for some reason ignoring the ethernet
> device _PRW information so it does not suffer this issue.

Oh well.

> Does anyone have suggestions for how Linux should work with this?
>
> What logic should we use to ignore the _PRW in this case, or how can
> we quirk it?

User space can do that via /proc/acpi/wakeup.  The kernel not so much.

I guess it might be possible to add a DMI-based quirk for this system
to ignore _PRW for a specific ACPI device object, but that would be
super-ugly.

> Also, is there a standard behaviour defined for ethernet drivers
> regarding wake-on-LAN?

I'm not aware of any. :-)

> r8169 appears to enable wake-on-LAN by default
> if it believes the hardware is capable of it, but other ethernet
> drivers seem to default to WOL off. (I don't expect users of the
> affected consumer laptops here to care about WOL support.)

Defaulting to off is generally safer, because you avoid spurious
wakeups when the user doesn't care about WoL.

Thanks,
Rafael

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

[Daniel Drake]

On Fri, Oct 6, 2017 at 9:24 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On the other hand, the RP05 (root port) _PRW says it will wake up the
>> system via GPE09, and the _L09 handler at least has one codepath which
>> could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup.
>
> Which can only happen in the S0 system state.

Not quite sure I understand your comment here. Of course the _L09
handler (and any other ACPI code) can only execute in S0 state.
However if Linux leaves GPE09 enabled during S3 suspend, and then
detects that it has an event pending on resume, it will execute _L09
during resume. (However, we have not observed GPE09 firing at all)

>> But in testing:
>>  - If GPE08 is enabled as a wakeup source, the system will always wake
>> up as soon as it goes to sleep
>
> What exactly do you mean by "enabled as a wakeup source"?

Linux associates the ethernet PCI device with PCI0.RP05.PXSX, which
has _PRW referencing GPE08.
r8169 has already done device_set_wakeup_enable() at probe time.
So when going into suspend, acpi_enable_wakeup_devices() and the code
beneath that will ensure that GPE08 is enabled when the system goes
into suspend.
See acpi_hw_enable_wakeup_gpe_block().

To disable it, "echo disabled > power/wakeup" for the ethernet device in sysfs.

To test with GPE09 instead, I modified the _PRW method in the DSDT to
point at GPE09, and again used sysfs to control whether the GPE is
enabled during suspend or not.

Thanks
Daniel