FWI - - > https://bugs.chromium.org/p/chromium/issues/detail?id=605554

Experiencing the exact same issues.

Version 51.0.2704.106 (64-bit)
Platform 8172.62.0 (Official Build) stable-channel chell
Firmware Google_Chell.7820.98.0

Activating. Please assign to the right owner and the appropriate priority.

It looks like the problem isn't in graphics subsystem. "mosys eventlog list" says that it even't doesn't try to wake up. So, reassigning it to the kernel team

Any idea on what next steps are for this? 

Attach log of failure. Was able to repro one failure w/ USB keyboard + mouse + two displays + HP elite USBC dock.

1. close chromebook -> see it enter docked mode
2. remove dock connection -> see standby entered
3. insert dock
4. wake system.

When it did fail,

- displays do NOT work.  USB keyboard+mouse do NOT work.  Only charging works.
- re-plug of dock's USBC cable to same port did NOT fix.
- re-plug of dock's USBC into other USBC port DID work.
- plugging other USBC devices into port worked.
- re-plug to original port then worked.

I'd speculate in case of my failure that the dock was wedged as I see no enumeration after coming out of suspend. 


SUCCESS

2017-11-16T18:11:02.252259+00:00 DEBUG kernel: [ 3020.625142] PM: Finishing wakeup.
2017-11-16T18:11:02.404034+00:00 INFO kernel: [ 3020.780505] usb 1-2: new high-speed USB device number 29 using xhci_hcd
2017-11-16T18:11:02.574393+00:00 INFO kernel: [ 3020.950480] usb 1-2: New USB device found, idVendor=05e3, idProduct=0610
2017-11-16T18:11:02.574405+00:00 INFO kernel: [ 3020.950492] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
2017-11-16T18:11:02.704025+00:00 INFO kernel: [ 3021.080646] usb 2-2: new SuperSpeed USB device number 13 using xhci_hcd
2017-11-16T18:11:02.717942+00:00 INFO kernel: [ 3021.094168] usb 2-2: New USB device found, idVendor=05e3, idProduct=0612
2017-11-16T18:11:02.717948+00:00 INFO kernel: [ 3021.094191] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
2017-11-16T18:11:02.736028+00:00 INFO kernel: [ 3021.112585] usb 1-7: new high-speed USB device number 30 using xhci_hcd
2017-11-16T18:11:02.953112+00:00 INFO kernel: [ 3021.329728] usb 1-7: New USB device found, idVendor=0408, idProduct=5060
2017-11-16T18:11:02.953144+00:00 INFO kernel: [ 3021.329758] usb 1-7: New USB device strings: Mfr=3, Product=1, SerialNumber=2
2017-11-16T18:11:02.985061+00:00 INFO kernel: [ 3021.361538] usb 2-2.3: new SuperSpeed USB device number 14 using xhci_hcd
2017-11-16T18:11:02.996396+00:00 INFO kernel: [ 3021.373082] usb 2-2.3: New USB device found, idVendor=0bda, idProduct=8153
2017-11-16T18:11:02.996423+00:00 INFO kernel: [ 3021.373111] usb 2-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=6
2017-11-16T18:11:03.242048+00:00 INFO kernel: [ 3021.619346] usb 2-2.2: new SuperSpeed USB device number 15 using xhci_hcd
2017-11-16T18:11:03.253052+00:00 INFO kernel: [ 3021.630257] usb 2-2.2: New USB device found, idVendor=17e9, idProduct=4354
2017-11-16T18:11:03.253067+00:00 INFO kernel: [ 3021.630277] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2017-11-16T18:11:03.371057+00:00 INFO kernel: [ 3021.747849] usb 1-2.1: new high-speed USB device number 31 using xhci_hcd
2017-11-16T18:11:03.458031+00:00 INFO kernel: [ 3021.834917] usb 1-2.1: New USB device found, idVendor=05e3, idProduct=0608
2017-11-16T18:11:03.458042+00:00 INFO kernel: [ 3021.834948] usb 1-2.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
2017-11-16T18:11:03.737044+00:00 INFO kernel: [ 3022.113758] usb 1-2.1.1: new low-speed USB device number 32 using xhci_hcd
2017-11-16T18:11:03.826032+00:00 INFO kernel: [ 3022.202829] usb 1-2.1.1: New USB device found, idVendor=046d, idProduct=c05a
2017-11-16T18:11:03.826042+00:00 INFO kernel: [ 3022.202840] usb 1-2.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
2017-11-16T18:11:03.894086+00:00 INFO kernel: [ 3022.270819] usb 1-2.1.2: new high-speed USB device number 33 using xhci_hcd
2017-11-16T18:11:03.969038+00:00 INFO kernel: [ 3022.346005] usb 1-2.1.2: New USB device found, idVendor=05e3, idProduct=0608
2017-11-16T18:11:03.969051+00:00 INFO kernel: [ 3022.346016] usb 1-2.1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
2017-11-16T18:11:04.047084+00:00 INFO kernel: [ 3022.423783] usb 1-2.1.3: new low-speed USB device number 34 using xhci_hcd
2017-11-16T18:11:04.138211+00:00 INFO kernel: [ 3022.514718] usb 1-2.1.3: New USB device found, idVendor=046d, idProduct=c31c
2017-11-16T18:11:04.138238+00:00 INFO kernel: [ 3022.514750] usb 1-2.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
2017-11-16T18:11:04.240093+00:00 INFO kernel: [ 3022.617087] usb 1-2.1.2.2: new high-speed USB device number 35 using xhci_hcd
2017-11-16T18:11:04.318147+00:00 INFO kernel: [ 3022.694925] usb 1-2.1.2.2: New USB device found, idVendor=0ea0, idProduct=2272
2017-11-16T18:11:04.318180+00:00 INFO kernel: [ 3022.694963] usb 1-2.1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3

FAIL

2017-11-16T18:11:42.262612+00:00 DEBUG kernel: [ 3050.921057] PM: Finishing wakeup.
2017-11-16T18:11:42.400399+00:00 INFO kernel: [ 3051.074535] usb 1-7: new high-speed USB device number 36 using xhci_hcd
2017-11-16T18:11:42.619439+00:00 INFO kernel: [ 3051.293761] usb 1-7: New USB device found, idVendor=0408, idProduct=5060
2017-11-16T18:11:42.619463+00:00 INFO kernel: [ 3051.293784] usb 1-7: New USB device strings: Mfr=3, Product=1, SerialNumber=2

Repro was difficult (1/60) however and while initially the failure seemed persistent to the dock it eventually became operational w/o power cycling.

Someone needs to refine the repro first.  To that end I wrote this test script (chell_dock_stress.sh) which appears to repro above failure quickly (<10 iterations).

Have no idea if its completely fair way to treat the port but its not completely dissimilar to whats happening on disconnect and it seems to repro much faster than via s2r cycling.

Unfortunately I don't have additional time to dedicate to this ATM.  +Benson for his thoughts & availability.

Deleted: debug-logs_20171116-101232.tgz 495 KB

debug-logs_20171116-101232.tgz 495 KB Download

Deleted: chell_dock_stress.sh 466 bytes

chell_dock_stress.sh 466 bytes View Download

Sameer, can you re-triage this? 

Kalin, can you help with getting repros of this scenario?

If this is indeed being caused by the dock getting wedged as mentioned in c#11, not sure how much we will be able to do to fix.

We have HP USB-C (Elite) docking station, and will try to reproduce manually. If not the stress script in #11 might come handy. Will test with M64 build and update till EOD today.

sontis@ tested 10176.13.1 / 64.0.3282.24 chell board

The first repro steps(without docking) in #1 are valid, and easily reproduced. It is enough to wait for suspend or execute 'powerd_dbus_suspend', and then resume is not possible using the mouse or keyboard attached to the docking station.

sontis@ reported the failure to resume is happening mostly on second or third attempt to resume, but sometimes could happen on the first attempt too. He could reproduce easily and 100%. No need to wait  for long time suspend.
Reproducible without external monitors too, and only kb and mouse plugged to docking station.

Logs are at https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/620418

This issue is specific to HP USB-C dock station.

Not able to reproduce this issue on DELL and STRONGR USB-c dock stations.

Yung, do we think this is a regression or have we always had issues resuming via KB / mouse connected to HP's USB-C dock?

Does this still even happen? This bug started in 2016, so it is nearing the age where we may want to just close it if we will never do anything about it. 

If this is specific to the dock, do we have any contact at HP in case we need them to do something on the dock side (if that is even possible)?

If no one has said anything here for so long, and we don't have any plan of action, we can mark as WontFix, if someone is still seeing this please feel free to reopen.