looking into this

I should say this now to prevent further confusion.

I was trying to reproduce issue 859358 by repetitively opening and closing the lid as I thought it may be a way to reproduce the problem. After the 20 seconds of it not occurring again, I gave up and went to bed. At the next entry (203-207 (11:14 AM)) was when it reoccurred and tried alt+volup+x first and then alt+volup+r which restarted the system as normal. Once I was signed back in, I sent the report.

I will share a video of what I was doing if you would like as it was taking about a second or two more to wake up, just let me know.

You can continue looking into this issue if you would like, but I thought I should mention it now as I forgot to add it in the report.

Thanks for having a look Ravi.

Sorry. Forgot updating the bug. From the logs, it looks like the wake is due to  PCI power management event. 
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/stabilize-7199.B/src/soc/intel/baytrail/elog.c#91

Not sure why this is happening. Will look into it further.

It can be xhci host controller. Was wondering if Bus 001 Device 002: ID 0b05:610f ASUSTek Computer, Inc. might be the reason. If you have a external usb connected, can you please remove that and see if you can reproduce the issue. 

It was most likely my phone that is being listed as it was manufactured by ASUS. I removed all external connections excluding the charging cable due to a battery failure, but it should show there is nothing connected.

I sent two reports with the bug id in the first line.

More swanky feedback reports:

http://feedback/#/Report/85581846297
http://feedback/#/Report/85582627204

Ravi, can you take a look at them?

Tried reproducing the issue locally but to no luck. 

From the logs: 
 The system seems to resume fine from EC/Bios perspective (could see the wake event in the event log). It is the kernel resume process that seems to get stuck forever. 

My theory is,
   Since I cannot reproduce the issue locally, it might be the drivers of additional usb devices connected to the system that might be taking forever to resume.
 
I have a MP device that do not have cameras on usb bus. But from the log I see that cameras are on the usb bus on both the devices.

I will try to get a device with cameras on usb bus and see if I can reproduce the issue.


 

Issue occurred today, about 2 or three days after updating to M69 (10895.21.0 (Official Build) beta-channel swanky). Sent feedback with "crbug.com/860305" in the first line from this email

Feedback from #10 is http://feedback/#/Report/85610718607.

This doesn't look like the same problem that's described above. There's no suspend/resume loop; Chrome was presumably hanging after the system resumed and came back up after Alt+F10+X:

[0819/165448:INFO:suspender.cc(457)] Starting suspend
[0819/165448:INFO:main.cc(259)] Running "/usr/bin/powerd_setuid_helper --action=suspend  --suspend_wakeup_count_valid --suspend_wakeup_count=4
"
[0819/165619:INFO:daemon.cc(625)] powerd_suspend returned 0
[0819/165619:INFO:suspender.cc(416)] Finishing request 59637761 successfully after 1m31s
...

2018-08-19T16:56:47.081851-04:00 INFO kernel: [ 1212.651081] sysrq: SysRq : Cros dump and crash
2018-08-19T16:56:47.081881-04:00 INFO kernel: [ 1212.651151] sysrq_x_cros_signal_process: signal 6 chrome pid 959 tgid 959
2018-08-19T16:56:47.277584-04:00 WARNING crash_reporter[4631]: Received crash notification for chrome[959] user 1000 (called directly)

No client ID in the feedback report (is the "Automatically send diagnostic and usage data to Google" setting disabled?), so I don't know how to find the Chrome crash report to see what it was doing when it was killed. If you go to chrome://crashes and click "Start uploading crashes", does a corresponding entry with "Local Crash ID: Chrome" show up eventually?

#c11, Two crashes are on that date, 

crash/c1de07e5e045c48c
crash/4ad360a2b2ed5c91 

Both are about 2 minutes apart from being uploaded from each other. 

#c10 was for Issue 859358 as you had requested that further swanky reports be sent to this issue (crbug.com/859358#c26).

#12: Thanks, but neither of those crashes appears to be related to suspend/resume.

The next time you see this, could you collect full logs immediately after rebooting by going to chrome://net-internals/#chromeos and clicking "Store Debug Logs"? If you upload the resulting archive and share it with derat@chromium.org, I'll take a look.

To confirm, you want the logs from the OS not waking sent to your email? Bit confused on which issue you were talking about.

Logs from whichever suspend/resume issue you're currently seeing.

(Doesn't need to be emailed -- sorry, I meant to write "... upload the resulting archive _to Google Drive_ and share ...".)

https://crbug.com/859358#c36

Logs attached. Seeing this on M71 beta now and the system only reponds to esc+refresh+power, refresh+power, or holding the power button or so that the power supply is interupted. Still nothing in chrome:crashes, but something may turn up in the feedback report I sent or the attached logs.

Deleted: debug-logs_20181210-231234.tgz 5.9 MB

debug-logs_20181210-231234.tgz 5.9 MB Download