New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 894632 link

Starred by 4 users
Status: WontFix
Owner: ----
Closed: Dec 18
Cc:
█ ravisadineni@chromium.org
bleung@chromium.org
derat@chromium.org
█ igo@chromium.org
dnojiri@chromium.org
tbroch@chromium.org
█ shchen@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Chromebox wakes up upon shutting off external monitor with integrated USB hub

Project Member Reported by mnissler@chromium.org, Oct 11 
This is on 10895.56.0 (Official Build) stable-channel fizz-unibuild

I have an external monitor with an integrated USB 3 hub. The Chromebox is hooked up via HDMI and USB A-to-B cable to the monitor, keyboard and mouse are connected to the monitor via USB.

Repro steps:
1. Lock Chrome OS via search-alt-l, locks as expected
2. Turn off external monitor (which I'm assuming will also kill power for its integrated USB hub)

Expected behavior: Chromebox remains asleep
Actual behavior: Chromebox wakes up, presumably due to observing USB bus changes (the hub disappearing).

Working around this is surprisingly unwieldy: I can't turn off the monitor first (no way to send the Chromebox to sleep then, the power button would cause it to shut down). Waiting until the Chromebox goes back to sleep may work, but will take 30m30s if I read the powerd log correctly. So what I'm doing for now is to request sleep via search-alt-l and then immedtiately after turn off the monitor (my guess is that the USB disconnect is then being handled before going to sleep).

Feedback report with a few suspend cycles (both for the wake-on-USB-off case, and for the quickly-turn-monitor-off workaround) is at https://listnr.corp.google.com/product/208/report/85717216131

There's probably no good reason to wake up when USB devices get disconnected? We might not be able to distinguish connect from disconnect events though when deciding to wake up or not? Or maybe expose a knob to control whether wake on USB is enabled or not?

Over to derat@ to triage.

Comment 1 by derat@chromium.org, Oct 11

Cc: bleung@chromium.org ravisadineni@chromium.org derat@chromium.org tbroch@chromium.org
Components: -OS>Systems OS>Kernel>Power
Owner: ----
Status: Untriaged (was: Unconfirmed)
Lock is just Search+L. Are you typing Search+Alt+L (which isn't an accelerator, I don't think) or Search+Shift+L (Suspend)?

In the feedback report, I see a few suspends, suggesting that it's the latter:

...
218 | 2018-10-11 23:55:12 | ACPI Enter | S3
219 | 2018-10-11 23:55:15 | ACPI Wake | S3
220 | 2018-10-11 23:55:15 | Wake Source | PME - XHCI (USB 2.0 port) | 2
221 | 2018-10-11 23:55:15 | Wake Source | GPE # | 109
222 | 2018-10-11 23:57:24 | ACPI Enter | S3
223 | 2018-10-11 23:57:47 | ACPI Wake | S3
224 | 2018-10-11 23:57:47 | Wake Source | PME - XHCI (USB 2.0 port) | 2
225 | 2018-10-11 23:57:47 | Wake Source | GPE # | 109

2018-10-11T21:57:47.319096+00:00 DEBUG kernel: [41337.986236] PM: Finishing wakeup.
2018-10-11T21:57:47.319097+00:00 INFO kernel: [41337.986237] Restarting tasks ... done.
2018-10-11T21:57:47.324177+00:00 INFO kernel: [41337.994221] PM: suspend exit 2018-10-11 21:57:47.323535651 UTC
2018-10-11T21:57:47.325329+00:00 NOTICE powerd_suspend[31809]: wake source: SMI_STS: PM1 #012PM1_STS: WAK #012TCO_STS: BOOT SECOND_TO #012--#012SMI_STS: PM1 #012PM1_STS: WAK #012TCO_STS: BOOT SECOND_TO 
2018-10-11T21:57:47.329660+00:00 NOTICE powerd_suspend[31824]: Enabling Bluetooth HCI mode change event after resume
2018-10-11T21:57:47.333954+00:00 NOTICE powerd_suspend[31835]: Resume finished

Whatever's going on, it's presumably below userspace. Cc-ing some people who probably know more.

Comment 2 by bleung@google.com, Oct 11

Cc: dnojiri@chromium.org shchen@chromium.org
+firmware folks on Fizz.

I think this is related to wake on USB. May be expected.

Comment 3 by mnissler@chromium.org, Oct 12 

Yes, I'm suspending via search-shift-l (shouldn't file bugs at midnight I guess :-D)

I wouldn't be surprised to hear that this is WAI, just figured I'd file a bug given that the user experience in this edge case is somewhat unfortunate. If we can configure wake-on-USB to not trigger on disconnects, that'd be nice. If not, then maybe we need to consider giving users more control over wake behavior to allow disabling wake-on-USB when it gets in the way?

Comment 4 by bleung@google.com, Oct 14

Cc: igo@chromium.org
+igo

Comment 5 by dnojiri@chromium.org, Oct 16 

I think devices shouldn't wake up on USB disconnect. So, it's a bug to fix. 

Fizz EC doesn't enable/disable the USB-A ports on suspend. So, wake-up is controlled by the AP/PCH.

Comment 6 by tbroch@google.com, Dec 18

Status: WontFix (was: Untriaged)
Believe this is WAI.  Docs updated here: b/62095784
►

Sign in to add a comment