On Thu, Oct 5, 2017 at 10:57 AM, Daniel Drake <drake@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
