I've seen this on my R11 intermittently as well, but so far tracking down the trigger has been difficult. I have not been able to reliably reproduce it yet.

I've think I've narrowed it down to what I do when it happens. It's still inconstant but it doesn't happen during inactivity.

When I use the keyboard or touch the touchscreen sometimes it happens. 

I also forgot to mention that this was visible in ver. 52, but it wasn't as severe as this. 

Here is a forum thread from CBC with people with the issue https://productforums.google.com/forum/#!topic/chromebook-central/XPV-9YKMnko;context-place=forum/chromebook-central

Is there an ID in chrome://crashes?

Nothing shows up in Chrome://crashes for this. Have been checking ever since it first happened after updating to 54 and there still is nothing related to this. (just a few hard reset reports are visible)

I see this too in Canary, Dev and Beta on Edgar. This along with my kernel panics make Stable 53 my only safe haven for now.

Here's a gdrive link of a video of showing the "system hang" that happens afterwards. https://drive.google.com/file/d/0ByCy9ZJLJAjKLXhKb3JUaUZBRG8/view?usp=sharing

Updated to 54.0.2840.59 beta today and still no change. Happened pretty quickly after updating when typing in a google doc.

Bug reports sent at 8:06 and 8:15 CT, first one relating to google doc, other one relating to it happening while making a comment on this bug, then it happening while making another feedback report.

I've noticed a pattern. It seems to always do this randomly when a text field is selected and I start typing. 

Thanks for the feedback reports!

I didn't see any references to Chrome crashing and restarting in the feedback logs that I looked at. There are actually a decent number of browser, kernel, and ARC (Android) crash reports from your device, but most of them are from before the latest feedback reports. I also don't see any clear patterns in the recent browser crashes. There's a crash that appears to be related to a password manager dialog, but I don't think it's been reported enough to correspond to what you're seeing. I've filed issue 656141 (sorry, protected) to track it.

The renderers-not-responding-after-suspend problem sounds a bit like  issue 646912 . That bug has been present for a long time, but it's possible that some devices are more likely to trigger it. It should be fixed in M55.

As for the main problem, I don't have any great theories. So... the display goes black but the backlight remains on (maybe mostly while typing, using the touchscreen, or otherwise generating input events) and stays that way unless the lid is closed and opened, at which point the desktop comes back and the browser is responsive, but all renderers hang indefinitely?

I'm wondering if there are two separate problems here: a cyan-specific issue that's causing the display to turn off unexpectedly, and then a separate issue that's making renderers hang after suspend/resume (maybe caused by  issue 646912  or something similar).

May be the addition of another, unrelated set of issues but I will tell anyways. This morning in an attempt to troubleshoot this issue I did a powerwash and added a brand new account as the owner, then signed out, which -caused a full on crash to startup screen-. Then I added my usual account as a secondary profile. 

On my usual account, it started syncing applications and extensions normally, but most of my downloaded chromeapps had no icons (instead the default "box" icon), and some of my extensions were corrupted according to chrome://extensions. 

I sent feedback on this at approximately 11:05 CT, and the crash has not shown up in chrome://crashes yet

Also, while writing this the R11 did have another black screen, but it didn't have a system hang afterwards. 

Deleted: Screenshot 2016-10-15 at 10.43.59 AM.png 170 KB

	Screenshot 2016-10-15 at 10.43.59 AM.png 170 KB View Download

Deleted: Screenshot 2016-10-15 at 10.42.58 AM.png 83.4 KB

	Screenshot 2016-10-15 at 10.42.58 AM.png 83.4 KB View Download

Update on all of this, it did the black screen thing three times, then it stopped. It currently hasn't done it at all for almost 7 hours of use now. 

Update, I switched to stable 53 and have had no black screens whatsoever.

I have the same problem: occasional screen blank, linked to key press events.

With different extensions installed, it manifests differently: I had this one ad blocker extension.
* Without that extension: screen goes black, I close lid + open lid, everything is fine
* With that extension: screen goes black, I close lid + open lid, system reboots.

My guess is that the "tabs unresponsive" issue is created by some extension, whereas the screen blank itself is fresh from Google.

Confirmed here on two machines:

celes/strago on stable R54 
 and 
daisy/snow on beta R55.

Two different users. The one on celes/strago had virtually no extensions and only a minimal profile.

Screens turned black with backlight active on both machines. Did not recover (only waited for around a minute, then decided to hard-shutdown via power button long-press).

I've sent a report after reboot on each of them. I have not mentioned this bug report though since I only saw it after.

#15: Thanks! What email address did you use to submit the reports? I don't see any reports from the address you used when leaving this comment.

I'm hopeful that the "tabs are unresponsive" part of this was actually  issue 646912 . The fix for that has been merged to 54.0.2840.79, so I'd like to know if it's still showing up on devices with that version or later of Chrome.

As far as the screen going black goes, I'm much less sure. Maybe there'll be clues in feedback reports...

#16 derat:

For daisy/snow I actually used my private email address, which I don't wanna type in full here if you don't mind, but it starts with hg.we...@gmail.com.

For celes/strago I sent the report with virtually the same description a few minutes later but left the email address blank.

I don't know how many reports you guys are getting per minute and it's the first time I sent one, so was quite ignorant in regards to filling out that info, sorry about that. Just let me know if it would still make sense to send another one (I'd only use one address and also reference this bug report in that case)

#17: Thanks, it took a while but I found one of them (http://feedback/#/Report/21940967478). The other one might've been submitted anonymously; I suspect it's http://feedback/#/Report/21941276818. I'll take a look at the logs tomorrow morning.

The logs from 21940967478 are fairly limited (no eventlog or powerd.PREVIOUS), but 21941276818 (celes) has both of these. Here's the part of eventlog from 2016-11-03:

282 | 2016-11-03 18:48:58 | System boot | 9
283 | 2016-11-03 18:48:58 | SUS Power Fail
284 | 2016-11-03 18:48:58 | System Reset
285 | 2016-11-03 18:48:58 | Wake Source | Power Button | 0
286 | 2016-11-03 20:07:55 | ACPI Enter | S3
287 | 2016-11-03 20:31:30 | ACPI Wake | S3
288 | 2016-11-03 20:31:30 | Wake Source | Internal PME | 0
289 | 2016-11-03 21:23:11 | Kernel Event | Clean Shutdown
290 | 2016-11-03 21:23:11 | ACPI Enter | S5
291 | 2016-11-03 21:23:17 | System boot | 10
292 | 2016-11-03 21:23:17 | EC Event | Power Button
293 | 2016-11-03 21:23:17 | System Reset
294 | 2016-11-03 21:23:17 | ACPI Wake | S5
295 | 2016-11-03 21:23:17 | Wake Source | Power Button | 0
296 | 2016-11-03 21:23:40 | Kernel Event | Clean Shutdown
297 | 2016-11-03 21:23:40 | ACPI Enter | S5
298 | 2016-11-03 22:31:23 | System boot | 11
299 | 2016-11-03 22:31:23 | SUS Power Fail
300 | 2016-11-03 22:31:23 | System Reset
301 | 2016-11-03 22:31:23 | Wake Source | Power Button | 0

powerd.PREVIOUS goes from 21:23:20 until a power-button-triggered shutdown at 21:23:36.

powerd.LATEST starts at 22:31:26.

I think that this window may be where the problem occurred:

286 | 2016-11-03 20:07:55 | ACPI Enter | S3
287 | 2016-11-03 20:31:30 | ACPI Wake | S3
288 | 2016-11-03 20:31:30 | Wake Source | Internal PME | 0
289 | 2016-11-03 21:23:11 | Kernel Event | Clean Shutdown
290 | 2016-11-03 21:23:11 | ACPI Enter | S5
291 | 2016-11-03 21:23:17 | System boot | 10

Does that line up with your memory of the sequence of events?

Could you also browse to file:///var/log on the device, save the messages* and power_manager/powerd.* files from 2016-11-03, and then email them to derat@chromium.org? Thanks!

Thanks for looking into this; I'm glad one of the reports contained some useful data. I'm physically away from my machines until tomorrow evening UTC, but I'll email those logs once I'm back.

#19 derat: I've sent the archive containing the requested logs via email now.

Thanks! Here's what I see from the power manager logs that you sent:

18:49:01  system booted
19:16:02  screen off for inactivity
19:17:26  screen on for user activity
19:32:31  screen off for inactivity
19:36:15  screen on for user activity
19:45:54  screen off for inactivity
20:07:54  suspend for inactivity
20:31:30  resume for user activity
21:22:13  power button tapped but released immediately
21:23:04  power button held
21:23:08  shut down for power button
21:23:20  system booted
21:23:37  shut down for power button
22:31:26  system booted (and feedback report sent after this)

If you still remember what happened, can you approximate the time when the screen turned off unexpectedly? The shutdown at 21:23:08 and boot 12 seconds later looks likely, but there's one more shutdown after that at 21:23:37, and then it looks like the system was off for ~8 minutes before it booted again and the feedback report was sent, so I want to make sure that I'm looking at the right point.

I don't see any non-clean shutdowns, so it's likely that Chrome was still responsive enough to ask powerd to shut down after you held the power button.

It must have been the first shutdown that you're seeing. I find it strange that it shows two shutdowns in a row with almost no time in between.

There's a "[drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun" error logged by the kernel at 21:22:05, 8 seconds before the power button was tapped and about a minute before it was held to shut the system down:

...
2016-11-03T21:19:29.837645+00:00 INFO kernel: [ 7616.309539] sst-mfld-platform sst-mfld-platform: Enter: enable=0 port_name=ssp2-port
2016-11-03T21:19:29.837675+00:00 DEBUG kernel: [ 7616.309563] writing to lpe: 00000000: 01 01 01 01 00 00 1a 00 ff ff ff ff 75 00 12 00  ............u...
2016-11-03T21:19:29.837682+00:00 DEBUG kernel: [ 7616.309567] writing to lpe: 00000010: 03 00 00 00 18 09 0f ff 0f ff 03 00 01 01 01 00  ................
2016-11-03T21:19:29.837688+00:00 DEBUG kernel: [ 7616.309570] writing to lpe: 00000020: 00 00                                            ..
2016-11-03T21:19:29.859649+00:00 DEBUG kernel: [ 7616.331494] writing to lpe: 00000000: 01 01 01 01 00 00 08 00 ff ff ff ff 0e 00 00 00  ................
2016-11-03T21:19:29.859670+00:00 DEBUG kernel: [ 7616.331678] writing to lpe: 00000000: 01 02 01 03 00 00 14 00 ff ff ff ff 21 00 0c 00  ............!...
2016-11-03T21:19:29.859678+00:00 DEBUG kernel: [ 7616.331683] writing to lpe: 00000010: 01 00 00 90 67 00 60 fa 60 fa 32 00              ....g.`.`.2.
2016-11-03T21:19:29.860625+00:00 INFO kernel: [ 7616.332126] intel_sst_acpi 808622A8:00: Free for str 1 pipe 0x90
2016-11-03T21:19:29.874612+00:00 DEBUG kernel: [ 7616.346520] writing to lpe: 00000000: 01 01 01 01 00 00 0a 00 ff 8d ff ff 77 00 02 00  ............w...
2016-11-03T21:19:29.874641+00:00 DEBUG kernel: [ 7616.346525] writing to lpe: 00000010: 00 00                                            ..
2016-11-03T21:19:29.874648+00:00 DEBUG kernel: [ 7616.346990] writing to lpe: 00000000: 01 01 01 03 00 00 0a 00 ff 12 ff ff 77 00 02 00  ............w...
2016-11-03T21:19:29.874654+00:00 DEBUG kernel: [ 7616.346994] writing to lpe: 00000010: 00 00                                            ..
2016-11-03T21:19:29.875622+00:00 DEBUG kernel: [ 7616.347239] writing to lpe: 00000000: 01 01 01 01 00 00 14 00 ff ff ff ff 72 00 0c 00  ............r...
2016-11-03T21:19:29.875635+00:00 DEBUG kernel: [ 7616.347244] writing to lpe: 00000010: ff 02 ff ff 00 00 01 00 ff 8d ff ff              ............
2016-11-03T21:19:29.875641+00:00 DEBUG kernel: [ 7616.347366] writing to lpe: 00000000: 01 01 01 03 00 00 14 00 ff ff ff ff 72 00 0c 00  ............r...
2016-11-03T21:19:29.875646+00:00 DEBUG kernel: [ 7616.347371] writing to lpe: 00000010: ff 12 ff ff 00 00 01 00 ff 90 ff ff              ............
2016-11-03T21:22:05.738676+00:00 ERR kernel: [ 7772.210958] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun

Searching for that error suggests that it might be coming from the i915 driver (see e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1550779).

 Issue 660205  might be the same thing.

 Issue 660205  has been merged into this issue.

Pasting from the duped bug:

marcheu@: "This should be fixed by the reverts I landed last week in the kernel and in 55/54"

derat@: "Thanks. I assume that it's some combination of the ones between Nov 1 and Nov 3 at https://chromium-review.googlesource.com/q/owner:marcheu. :-)"

not reproducible in 8975.0.0 / 56.0.2907.0

Still visible in 54.0.2840.93

Really is a shame, have come across several people who have been forced to return their Chromebooks due to this bug...

Any more updates?

#29: Does the problem that you're seeing have the same cause, or is it something else? Are there [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun" messages in the messages* files under file:///var/log?

Nothing like that under that in any of the messages files.

The i915 fixes went out in 8743.81.0. Chrome 54.0.2840.93, where issues are still being seen, shipped in 8743.83.0, so the i915 changes should be present there.

Can you describe how/if what you're seeing now differs from what was originally reported? It sounds like this is what you were seeing before:

- The display turns off suddenly while the system is in use.
- The only way to turn it back on is by closing and opening the lid.
- Chrome tabs are all frozen at this point.
- Non-tab-specific input that was performed while the screen was off (brightness, volume, etc.) appears to have taken effect, though.

Are all tabs still frozen now, for example, or is that part fixed?

Looking at your earlier feedback reports (thanks for uploading all of those!), some things seem a bit suspicious. For example, the eventlog from 14122604465 shows the following:

324 | 2016-10-15 11:50:21 | System boot | 213
325 | 2016-10-15 11:50:21 | EC Event | Power Button
326 | 2016-10-15 11:50:21 | SUS Power Fail
327 | 2016-10-15 11:50:21 | System Reset
328 | 2016-10-15 11:50:21 | Wake Source | Power Button | 0
329 | 2016-10-15 12:58:23 | ACPI Enter | S3
330 | 2016-10-15 12:59:39 | EC Event | Lid Open
331 | 2016-10-15 12:59:39 | ACPI Wake | S3
332 | 2016-10-15 13:22:11 | System boot | 214
333 | 2016-10-15 13:22:11 | SUS Power Fail
334 | 2016-10-15 13:22:11 | System Reset
335 | 2016-10-15 13:22:11 | Wake Source | Power Button | 0

powerd.PREVIOUS starts at 11:50:23 but ends abruptly (without a clean shutdown, or even the power button being held) at 13:19:40. powerd.LATEST starts at 13:22:17 and continues until 13:22:53. I would guess that the kernel crashed there, but I don't see any crash reports from the client ID that was used to submit that feedback -- do you have crash reporting (the "Automatically send diagnostic and usage data to Google" setting, I think) enabled?

And would you mind submitting one more feedback report right after the next time you see this? I can believe that there are/were multiple overlapping issues here, and I'd like to make sure that we're not seeing something else now. Thanks again.

Tabs don't get frozen anymore + it doesn't require screen close/open anymore, usually comes back on own. I haven't had it happen since a bit before my response in comment #29, but I will send a feedback report immediately when it does happen again.

Are the similar issues on Braswell boards (issue 661656, just so you know, I did not use an affected Chromebook to make that bug but this R11) possibly related? There's not much information I know about that one, sorry.

Re Braswell issues being related, I'm not sure.

Thanks for filing issue 661656. Mind if we move discussion of the screen-turns-off-but-comes-back-on-its-own behavior there?

I suspect that most of the earlier reports on this bug were caused by a mix of:

a) video driver issue turning the backlight off suddenly, and
b) lid-close-and-open possibly turning the backlight back on, but triggering a separate suspend/resume bug that made renderers hang ( issue 646912 ).

Since the fixes for both a) and b) have been merged to M54, I suspect that what you're seeing now is a new issue. I can think of multiple potential causes (display hardware issue, misfiring lid switch, a new software bug, etc.), but can't do much more than guess until the logs point at something definite.