Bug 120701

Summary:	Unable to wakeup Surface 3 with USB peripherals
Product:	Drivers	Reporter:	Stephen Just (stephenjust)
Component:	USB	Assignee:	Greg Kroah-Hartman (greg)
Status:	NEW ---
Severity:	normal	CC:	bugzilla, rui.zhang, szg00000
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	4.5.0-4.7.0-rc3	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	Surface 3 DSDT Surface 3 FACP dmesg with freeze Output of "cat /proc/acpi/wakeup"

Description Stephen Just 2016-06-20 18:38:20 UTC

On the Surface 3 tablet, I am unable to wake up a device that has been frozen with "echo freeze > /sys/power/state" with any device other than the capacitive "Windows" button or power button on the device.

Note: Support for the Windows button and other hardware keys requires patch set from http://www.spinics.net/lists/linux-input/msg44595.html, so anyone without this patch set has no way of unfreezing.
Also, https://bugzilla.kernel.org/show_bug.cgi?id=106941#c34 to keep the system from repeatedly suspending, or disable lid switch suspend in /etc/systemd/logind.conf

In Windows, this device goes into a "connected standby" (i.e. low-power S0) mode, and can be quickly woken with the Type Cover, or a USB attached mouse. The Type Cover is just a USB device that goes through a hardware DRM implementation.

Note that the only device that appears in /proc/acpi/wakeup is "WIFI".

I know very little about the power management stuff that happens in USB, but I have some non-technical observations about freeze:
* When freeze happens, USB peripherals still have power - a connected USB Hub still has an LED on.
* When freeze happens, a connected USB flash drive seems to suspend, its LED goes off
* When freeze happens, the connected Type Cover seems to lose power - its LEDs go off, and it does not respond to inputs.
* When freeze happens, moving a connected mouse seems to unsuspend the flash drive, its LED comes back on, but the system does not wake up. (Does the USB hub try to wake up everything attached to it?)
* Power button and Windows button will wake system. Hardware volume keys will not.

From my poor understanding of this system's DSDT, I think that the XHCI controller is supposed to remain powered on, so things connected to it shouldn't be suspending, which might make this an ACPI bug. Or a PM bug. Or a bug in the USB stack.

Comment 1 Stephen Just 2016-06-20 18:39:11 UTC

Created attachment 220701 [details]
Surface 3 DSDT

Comment 2 Stephen Just 2016-06-20 18:43:12 UTC

Created attachment 220711 [details]
Surface 3 FACP

FACP indicates support for "Low Power S0 Idle"

Comment 3 Stephen Just 2016-06-20 18:50:06 UTC

Created attachment 220721 [details]
dmesg with freeze

echo "freeze" > /dev/kmsg
echo "freeze" > /sys/power/state
-wakeup-
echo "unfreeze" > /dev/kmsg

Comment 4 Stephen Just 2016-06-20 18:51:22 UTC

Created attachment 220731 [details]
Output of "cat /proc/acpi/wakeup"

Comment 5 Stephen Just 2016-06-20 19:09:37 UTC

Also note that:
  echo "enabled" > /sys/bus/usb/devices/1-3/power/wakeup
allows the type cover to remain powered on during freeze, but it does not wake the system. It defaults to "disabled", which could be adjusted with a udev rule eventually.

Comment 6 Zhang Rui 2016-06-28 03:04:49 UTC

(In reply to Stephen Just from comment #0)
> On the Surface 3 tablet, I am unable to wake up a device that has been
> frozen with "echo freeze > /sys/power/state" with any device other than the
> capacitive "Windows" button or power button on the device.
> 
this depends on the drivers. Any driver that wants to wakeup the system from freeze state should configure its wakeup IRQ properly. This is not controlled by ACPI.

> Note: Support for the Windows button and other hardware keys requires patch
> set from http://www.spinics.net/lists/linux-input/msg44595.html, so anyone
> without this patch set has no way of unfreezing.
> Also, https://bugzilla.kernel.org/show_bug.cgi?id=106941#c34 to keep the
> system from repeatedly suspending, or disable lid switch suspend in
> /etc/systemd/logind.conf
> 
> In Windows, this device goes into a "connected standby" (i.e. low-power S0)
> mode, and can be quickly woken with the Type Cover, or a USB attached mouse.
> The Type Cover is just a USB device that goes through a hardware DRM
> implementation.
> 
> Note that the only device that appears in /proc/acpi/wakeup is "WIFI".
> 
> I know very little about the power management stuff that happens in USB, but
> I have some non-technical observations about freeze:
> * When freeze happens, USB peripherals still have power - a connected USB
> Hub still has an LED on.
> * When freeze happens, a connected USB flash drive seems to suspend, its LED
> goes off
> * When freeze happens, the connected Type Cover seems to lose power - its
> LEDs go off, and it does not respond to inputs.
> * When freeze happens, moving a connected mouse seems to unsuspend the flash
> drive, its LED comes back on, but the system does not wake up. (Does the USB
> hub try to wake up everything attached to it?)
> * Power button and Windows button will wake system. Hardware volume keys
> will not.
> 
> From my poor understanding of this system's DSDT, I think that the XHCI
> controller is supposed to remain powered on, so things connected to it
> shouldn't be suspending, which might make this an ACPI bug. Or a PM bug. Or
> a bug in the USB stack.

From the /proc/acpi/wakeup file attached, we can also see that there is no wakeup GPE for the xhci controller. This suggests it is a USB problem that does not configure its native wakeup interrupt properly.

Comment 7 Greg Kroah-Hartman 2016-06-28 04:52:03 UTC

On Tue, Jun 28, 2016 at 03:04:49AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:

Please send to the linux-usb@vger.kernel.org mailing list.