I suspect this has something to do with Power, so tentatively assigning to Sameer. Feel free to re-assign to the more accurate person within platform/power.

Sonny, could you follow the instructions at go/chromeos-hung and report back on which step recovered the system?  We will need to grab logs from the system too.

Yes, please either file a feedback report with Alt+Shift+i or attach debug logs generated from chrome://net-internals/#chromeos immediately after rebooting when you see the problem.

The battery suspend delay is a minute beyond the screen-off delay, so it's presumably dying when suspending.

So this is weird. Previously I have been having this issue every day since months ago and it reproduced 100% of the time. Now that I am ready to file a feedback report, it won't repro at all.

Is there a way to make the screen off (not suspend) faster than the default. The default is about 6 minutes and it takes long to experiment to find the repro.

> Is there a way to make the screen off (not suspend) faster than the default.

Not without putting the device into developer mode or sending it an enterprise policy that sets custom delays, as far as I'm aware. If this is a kernel-level suspend/resume issue, it's possible that you'd also be able to trigger it by closing the lid to make the system suspend.

If you see it again, it'd probably also be worthwhile noting the color of the LED on the device to see whether it's awake, suspended, off, etc. (I don't know where the LED is located on chell or what its colors mean, but LEDs are usually next to charging ports, I think.)

Thanks for the suggestion. I will close this bug for now until I am able to repro this again.

I finally was able to repro this again. So I left my chell on (without screen lock) and let it screen off automatically, but not suspend (because I am using Keep Awake extension), for the whole night. The morning I pressed any key to trigger screen on but the screen wouldn't turn on. I believe that the chromebook wasn't suspended because the screen was black but there was backlight (like a bright black).

I did the go/chromeos-hung and at step 3 (the one that caused kernel panic reboot) the chromebook rebooted itself. Then after it rebooted I filed the feedback report under my google account sonnysasaka@.

Update about the repro steps:
* I used Keep Awake extension, this makes the chromebook screen off but not suspend.
* After the screen off automatically, I needed to wait long (1 minute is not enough) to repro this case. I don't know how long is the threshold but in my case overnight is enough to repro.

Thanks, the feedback report is at http://feedback/#/Report/84973379056. Here's eventlog:

...
265 | 2018-01-24 00:34:55 | ACPI Enter | S3
266 | 2018-01-24 00:50:41 | ACPI Wake | S3
267 | 2018-01-24 00:50:41 | Wake Source | GPIO | 112
268 | 2018-01-24 00:50:41 | EC Event | Lid Open
269 | 2018-01-24 10:32:36 | Kernel Event | Panic
270 | 2018-01-24 10:32:38 | System boot | 41
271 | 2018-01-24 10:32:38 | System Reset

I take it that you closed the lid around 00:35 this morning, opened it at 00:50, and then left the system alone before noticing the problem around 10:32 and triggering the reboot, right?

This is from powerd.PREVIOUS:

[0124/010406:INFO:state_controller.cc(89)] Dimming screen after 10m
...
[0124/010506:INFO:state_controller.cc(89)] Turning screen off after 11m
[0124/010506:INFO:internal_backlight_controller.cc(677)] Setting brightness to 0 (0%) over 200 ms
[0124/010506:INFO:display_power_setter.cc(81)] Asking DisplayService to turn all displays off
[0124/010507:INFO:daemon.cc(1412)] Chrome is using normal display mode
[0124/010516:INFO:state_controller.cc(89)] Locking screen after 11m10s
...
<system is idle for a long time>
[0124/103132:INFO:activity_logger.cc(20)] User activity reported
[0124/103132:INFO:state_controller.cc(96)] Undimming screen
[0124/103132:INFO:state_controller.cc(96)] Turning screen on
[0124/103132:INFO:display_power_setter.cc(81)] Asking DisplayService to turn all displays on
[0124/103133:INFO:internal_backlight_controller.cc(677)] Setting brightness to 36 (18.75%) over 0 ms
[0124/103133:INFO:keyboard_backlight_controller.cc(519)] Setting brightness to 10 (10%) over 200 ms
[0124/103133:INFO:daemon.cc(1412)] Chrome is using normal display mode
[0124/103151:INFO:daemon.cc(771)] On battery at 69%, 2.634/3.843Ah at 0.615A, 14h28m35s until empty (13h37m54s until shutdown)
[0124/103157:INFO:activity_logger.cc(20)] User activity stopped; last reported 20 sec ago
[0124/103207:INFO:keyboard_backlight_controller.cc(519)] Setting brightness to 0 (0%) over 2000 ms
[0124/103221:INFO:daemon.cc(771)] On battery at 68% (displayed as 69%), 2.628/3.843Ah at 0.604A, 9h33m29s until empty (8h59m56s until shutdown)
[0124/103225:INFO:activity_logger.cc(20)] User activity reported
[0124/103225:INFO:keyboard_backlight_controller.cc(519)] Setting brightness to 10 (10%) over 200 ms
[0124/103227:INFO:suspend_delay_controller.cc(121)] Unregistering suspend delay 71106564 (chrome) due to D-Bus client :1.164 going away
[0124/103227:INFO:suspend_delay_controller.cc(121)] Unregistering dark suspend delay 71139332 (chrome) due to D-Bus client :1.164 going away
[0124/103227:INFO:daemon.cc(1516)] Session state changed to stopped
[0124/103227:INFO:state_controller.cc(820)] Updated settings: dim=30s screen_off=40s lock=50s idle_warn=0s idle=10m (suspend) lid_closed=suspend use_audio=1 use_video=1
[0124/103227:INFO:state_controller.cc(832)] Wake locks: system
<some garbage, presumably from the system rebooting>

Things look normal to me on the powerd side. I think that the Chrome exit and sudden reboot at 10:32:27 were just from Alt+VolumeUp+X.

Would you mind also going to chrome://net-internals/#chromeos, clicking "Store Debug Logs", and uploading the files to Drive and sharing them with me so I can take a look at the Chrome and kernel log corresponding to the previous session?

I can't say I remember about closing the lid at 00:35, but it is possible that that happened. If powerd had no problem, should we suspect that this is display issue? It doesn't surprise me that there is no problem in powerd because the chromebook shouldn't even go to sleep because of the Keep Awake extension.

Yes, this doesn't look like a power-related issue to me, since the system didn't suspend. If you attach those logs, it may be possible to narrow it down further (e.g. it could be a Chrome bug, a kernel display bug, etc.).

Thanks Daniel, here is the logs:
https://drive.google.com/file/d/1pmJEm-feyPBNwlryQjsI-kaXdb8QcMV1/view?usp=sharing

Thanks. In messages.1, I see some errors from the kernel that coincide with the attempt to turn the display back on:

2018-01-24T10:31:32.770418-08:00 ERR kernel: [83471.156135] [drm:skl_set_cdclk] *ERROR* failed to inform PCU about cdclk change
2018-01-24T10:31:32.978371-08:00 ERR kernel: [83471.364210] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun

This looks like the same problem being discussed at  issue 773825 , so let's take discussion there.

Until this is fixed, one possible workaround from the other bug is closing and opening the lid to trigger suspend/resume.

Yes,  issue 773825  seems like the same issue. Thanks for triaging this.