If you're still seeing this, could you file a feedback report via Alt+Shift+i immediately after seeing the problem (and rebooting and logging back in)? Please note the email address that you used here. Thanks!

I can do that the next time this happens but the only way to wake it back up is to initiate the power wash procedure. PWR + ESC + Refresh once at that ! screen I just push the power to turn off and back on. I will not be able to submit a feedback report without rebooting the system.

Thank you for providing more feedback. Adding requester "derat@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I have submitted a report from.

32793189950
Service tag: F2C7VB2

In this report, I linked Directly to this issue.

Thanks, the feedback report is http://feedback/#/Report/83116698875.

Here's the end of powerd.PREVIOUS:

[1106/143620:INFO:daemon.cc(513)] Lid closed
[1106/143620:INFO:input_device_controller.cc(292)] Configuring devices for mode "closed"
[1106/143620:INFO:input_device_controller.cc(223)] Inhibiting /sys/devices/pci0000:00/INT3432:00/i2c-0/i2c-SYNA0000:00/0018:06CB:7AB3.0001/input/input4
[1106/143620:INFO:input_device_controller.cc(223)] Inhibiting /sys/devices/pci0000:00/INT3433:00/i2c-1/i2c-ELAN0001:00/input/input5
[1106/143620:INFO:input_device_controller.cc(223)] Inhibiting /sys/devices/platform/i8042/serio0/input/input3
[1106/143620:INFO:input_device_controller.cc(211)] Disabling wakeup for /sys/devices/pci0000:00/INT3432:00/i2c-0/i2c-SYNA0000:00/0018:06CB:7AB3.0001/input/input4 through /sys/devices/pci0000:00
/INT3432:00/i2c-0/i2c-SYNA0000:00
[1106/143620:INFO:input_device_controller.cc(211)] Disabling wakeup for /sys/devices/pci0000:00/INT3433:00/i2c-1/i2c-ELAN0001:00/input/input5 through /sys/devices/pci0000:00/INT3433:00/i2c-1/i2
c-ELAN0001:00
[1106/143620:INFO:input_device_controller.cc(211)] Disabling wakeup for /sys/devices/platform/i8042/serio0/input/input3 through /sys/devices/platform/i8042/serio0
[1106/143620:INFO:state_controller.cc(931)] Ready to perform lid-closed action (suspend)
[1106/143620:INFO:suspender.cc(402)] Starting request 70254635
[1106/143620:INFO:daemon.cc(602)] Reading wakeup count from /sys/power/wakeup_count
[1106/143620:INFO:daemon.cc(606)] Read wakeup count 35479
[1106/143620:INFO:internal_backlight_controller.cc(682)] Setting brightness to 0 (0%) over 0 ms
[1106/143620:INFO:internal_backlight_controller.cc(699)] Setting resume brightness to 380 (63%)
[1106/143620:INFO:keyboard_backlight_controller.cc(492)] Setting brightness to 0 (0%) over 0 ms
[1106/143620:INFO:suspend_delay_controller.cc(140)] Announcing suspend request 70254635 with 2 pending delay(s) and 0 outstanding delay(s) from previous request
[1106/143620:INFO:suspend_delay_controller.cc(86)] Got notification that delay 70254594 (shill) is ready for suspend request 70254635 from :1.11
[1106/143622:INFO:daemon.cc(1509)] Update operation is UPDATE_STATUS_CHECKING_FOR_UPDATE
[1106/143623:INFO:suspend_delay_controller.cc(86)] Got notification that delay 70254593 (chrome) is ready for suspend request 70254635 from :1.7
[1106/143623:INFO:suspend_delay_controller.cc(232)] Notifying observers that suspend is ready
[1106/143623:INFO:suspender.cc(473)] Starting suspend
[1106/143623:INFO:main.cc(233)] Running "/usr/bin/powerd_setuid_helper --action=suspend  --suspend_wakeup_count_valid --suspend_wakeup_count=35479"
[1106/143630:ERROR:main.cc(239)] Command failed with exit status 1
[1106/143630:INFO:daemon.cc(698)] powerd_suspend returned 1
[1106/143630:WARNING:suspender.cc(594)] Suspend attempt #1 failed; will retry in 10000 ms
[1106/143630:INFO:daemon.cc(602)] Reading wakeup count from /sys/power/wakeup_count
[1106/143630:INFO:daemon.cc(606)] Read wakeup count 35479
[1106/143637:INFO:activity_logger.cc(20)] User activity stopped; last reported 20 sec ago
[1106/143640:INFO:suspender.cc(473)] Starting suspend
[1106/143640:INFO:main.cc(233)] Running "/usr/bin/powerd_setuid_helper --action=suspend  --suspend_wakeup_count_valid --suspend_wakeup_count=35479"
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
...

The garbage at the end suggests that the system crashed without shutting down cleanly.

Here's the end of eventlog:

...
153 | 2017-11-06 14:35:22 | ACPI Enter | S3
154 | 2017-11-06 14:36:11 | ACPI Wake | S3
155 | 2017-11-06 14:36:11 | Wake Source | PCI Express | 0
156 | 2017-11-06 14:36:11 | Wake Source | GPIO | 27
157 | 2017-11-06 14:36:41 | ACPI Enter | S3
158 | 2017-11-06 14:36:48 | ACPI Wake | S3
159 | 2017-11-06 14:36:48 | Wake Source | PCI Express | 0
160 | 2017-11-06 14:36:48 | Wake Source | GPIO | 27
161 | 2017-11-06 14:37:00 | System boot | 15
162 | 2017-11-06 14:37:00 | SUS Power Fail
163 | 2017-11-06 14:37:00 | System Reset
164 | 2017-11-06 14:37:00 | ACPI Wake | S5
165 | 2017-11-06 14:37:00 | Wake Source | Power Button | 0
166 | 2017-11-06 14:37:00 | Chrome OS Recovery Mode | Recovery Button Pressed | 0x02
167 | 2017-11-06 14:37:02 | Power Button
168 | 2017-11-06 14:37:02 | ACPI Enter | S5
169 | 2017-11-06 14:37:06 | System boot | 16
170 | 2017-11-06 14:37:06 | SUS Power Fail
171 | 2017-11-06 14:37:06 | System Reset
172 | 2017-11-06 14:37:06 | Log area cleared | 1034
173 | 2017-11-06 14:37:06 | ACPI Wake | S5
174 | 2017-11-06 14:37:06 | Wake Source | Power Button | 0

It looks like the system entered S3 at 14:36:41 but then woke up 7 seconds later.

Sameer, do you have any guesses about what happened (or have a suggestion for someone who can look into this)?

Todd, could you please take a look?

barry.j.sessoms@gmail.com: if / when you repro the issue again can you please follow the steps below:
1. hit alt-volup-x key combination 3 times within a 10 second period.  Wait about 5 seconds. If the system reboots, file feedback report. If not, go to the step below.
2. hit alt-volup-r key combo once. If the system reboots, file feedback report. 
 If not, go to the step below.
3. hit power+refresh key combo once. The system will reboots here. File feedback report.

Lulu diff from .94 -> .96 very minimal

https://crosland.corp.google.com/log/9592.94.0..9592.96.0

No luck w/ repro on my DVT2 - SKU5 (i3 / 4GB)

Curious if anyone know the wake source,
159 | 2017-11-06 14:36:48 | Wake Source | PCI Express | 0
160 | 2017-11-06 14:36:48 | Wake Source | GPIO | 27


Notable that initial suspend failed,
[1106/143630:WARNING:suspender.cc(594)] Suspend attempt #1 failed; will retry in 10000 ms

Unfortunately though there's no record in syslog of why as it only starts after power fail,

2017-11-06T14:37:08.856052-06:00 INFO kernel: [    0.000000] Initializing cgroup subsys cpu

@snanda@chromium.org

The next student that comes in I will follow those instructions! Thank you for looking into it and confirming we have an issue.

Good morning, 

I was out of the office for a couple of days. I got another student in this morning with power on issues. 

I reported it from 
Service tag: 2m2dvb2

Anybody able to locate the feedback report mentioned in #c11?

I have submitted another one from service tag 2R2DVB2.


I did alt+volup+r

I have Submitted another one from service tag 9TB7VB2


I did alt+volup+r

Found one of the two feedbacks recently submitted ... thanks!

https://listnr.corp.google.com/report/84743760094

Similar syslog signature ...

2017-12-04T13:53:29.294594-06:00 NOTICE powerd_suspend[2962]: Finalizing suspend
2017-12-04T13:55:46.660822-06:00 INFO kernel: [    0.000000] Initializing cgroup subsys cpuset

Nothing out of the ordinary in powerd.PREVIOUS IMO,

[1204/135329:INFO:state_controller.cc(984)] Ready to perform lid-closed action (suspend)
[1204/135329:INFO:suspender.cc(402)] Starting request 73990147
[1204/135329:INFO:daemon.cc(617)] Reading wakeup count from /sys/power/wakeup_count
[1204/135329:INFO:daemon.cc(621)] Read wakeup count 60
[1204/135329:INFO:internal_backlight_controller.cc(682)] Setting brightness to 0 (0%) over 0 ms
[1204/135329:INFO:internal_backlight_controller.cc(699)] Setting resume brightness to 380 (63%)
[1204/135329:ERROR:object_proxy.cc(582)] Failed to call method: org.chromium.cras.Control.SetSuspendAudio: object_path= /org/chromium/cras: org.freedesktop.DBus.Error.ServiceUnknown: The name org.chromium.cras was not provided by any .service files
[1204/135329:INFO:suspend_delay_controller.cc(140)] Announcing suspend request 73990147 with 1 pending delay(s) and 0 outstanding delay(s) from previous request
[1204/135329:INFO:suspend_delay_controller.cc(86)] Got notification that delay 73990145 (shill) is ready for suspend request 73990147 from :1.8
[1204/135329:INFO:suspend_delay_controller.cc(232)] Notifying observers that suspend is ready
[1204/135329:INFO:suspender.cc(473)] Starting suspend
[1204/135329:INFO:main.cc(231)] Running "/usr/bin/powerd_setuid_helper --action=suspend  --suspend_wakeup_count_valid --suspend_wakeup_count=60"

No console-ramoops log however.

eventlog looks similar,

213 | 2017-12-04 08:15:01 | ACPI Enter | S3
214 | 2017-12-04 13:52:13 | ACPI Wake | S3
215 | 2017-12-04 13:52:13 | Wake Source | PCI Express | 0
216 | 2017-12-04 13:52:13 | Wake Source | GPIO | 27
217 | 2017-12-04 13:53:30 | ACPI Enter | S3
218 | 2017-12-04 13:55:30 | ACPI Wake | S3
219 | 2017-12-04 13:55:30 | Wake Source | PCI Express | 0
220 | 2017-12-04 13:55:30 | Wake Source | GPIO | 27
221 | 2017-12-04 13:55:45 | System boot | 18
222 | 2017-12-04 13:55:45 | TCO Reset
223 | 2017-12-04 13:55:45 | System Reset
224 | 2017-12-04 13:55:45 | Wake Source | GPIO | 27

I sent another one from fp2dvb2.

Googlers only - the last submitted feedback is here: https://listnr.corp.google.com/product/208/report/84780941664
(found while digging wifi feedback reports for something else) .

Logs attached. 

Description:
"This is for Issue 767887

https://bugs.chromium.org/p/chromium/issues/detail?id=767887

We are also having issues on both Dell 7310 and Dell 3380 systems when they wake up from sleep they take extremely long to initialize the wifi connection. The systems will freeze completely until they are connected to the wifi network. This was never an issue prior to the latest updates."

Deleted: 84780941664-system_logs.zip 445 KB

84780941664-system_logs.zip 445 KB Download

+stevenh who owns kefka according to GE

tbroch@ - we have a customer reporting a similar failure to power on with open for 300 Dell 3180 units. Do you believe this could be related?

Is there any status update to this bug? Would having some of these units in hand (customer ships to MTV) expedite troubleshooting for you?

Raising priority due to customer escalated impact.

Video repro of issue on 3180 (google.com shared)
https://drive.google.com/file/d/1aBOjSodt5bsfnexhgd5rsZPNBygeN4pj/view?usp=sharing

Logs from device:
https://drive.google.com/file/d/1gWnJlQ7JWNpDXuE7s5sReYxvzlzLeknU/view?usp=sharing

Ya, I am not sure this will ever be resolved just like the WIFI issues with our devices it's just something we have had to deal with.

The only fix I have is taking the bottom lid off and removing the battery for a couple of seconds. Sometimes the problem doesn't come back at all sometimes the problem comes back within a couple of days. It's not ideal but at this point, I have no hope for a fix.

We are moving away from Dell products and moving to Asus next year so hopefully, this issue doesn't follow.

@#19, yes if there's devices that fail easily it would help to have one in-house.  Note, the devices in all likelihood would not be returnable so it should be RMA'd accordingly.

@#20,in the video both devices start with lids closed.  What was the state prior to lid closure?  Reason I ask is the 'working' device on left does wake but it appears to be from 'off' not 'suspend' as I would have expected given issue summary.

In looking at logs provided ... powerd.PREVIOUS shows 

[0228/081100:INFO:daemon.cc(1606)] Shutting down, reason: user-request

And eventlog looks to indicate the same,

230 | 2018-02-28 08:02:53 | Wake Source | Power Button | 0
231 | 2018-02-28 08:03:10 | ACPI Enter | S3
232 | 2018-02-28 08:09:46 | EC Event | Lid Open
233 | 2018-02-28 08:09:46 | ACPI Wake | S3
234 | 2018-02-28 08:11:03 | Kernel Event | Clean Shutdown
235 | 2018-02-28 08:11:03 | ACPI Enter | S5
236 | 2018-02-28 08:11:23 | System boot | 26
237 | 2018-02-28 08:11:23 | EC Event | Power Button
238 | 2018-02-28 08:11:23 | SUS Power Fail
239 | 2018-02-28 08:11:23 | System Reset
240 | 2018-02-28 08:11:23 | Wake Source | Power Button | 0

This may be a new issue as device appears to be shutting down cleanly and then failing to power on on lid-open.

With regard to battery disconnect/cut-off workaround you may find these instructions helpful.  

To cut off power, first shutdown device, then hold F3 (refresh key) + power button and unplug the charger at the same time.  Check that your device does not power on without the charger plugged in.  When you want to power back on the device, just plug the charger in again.  If you run into any issues or have further questions about these devices, please directly contact your device manufacturer.

While I don't have a dell chromebook 11 (AKA kefka) to test myself they should work.

I should also point out that original debug and feedback was on lulu (broadwell) while latest logs are kefka (braswell)  It would be good to separate out these issues as the platforms and it appears the failures are different

@jayhlee, please create new issue for issue from #19 and lets keep this one focused on lulu resume failure.

@#22, customer said the devices are powered off before the lids are closed.

We'll ask the customer to send us a problematic unit. 
The issue they are facing is different from the one reported in this bug in that their devices are powered off and does not power on upon lid open.

Just to add to this issues.  We have around 300 of the i3 Chromebook 13 lulu.  We frequently have users report this same issues.  For us it only requires an extended hold off power button(30-45 secs) to resolve.  Unconfirmed if it still happens on Chrome 65 yet as we ussually stay a release behind. 

@#19 - #24 (kefka) is being tracked here: crbug.com/829126

With regard to lulu, I don't have any solid leads ATM.  Internal stress testing of suspend/resume in lab looks healthy for last 30days across R67, R66, R65.

That testing doesn't focus on lid specifically though as sleep/wake source nor does it occur while on battery which I believe are parts of the reporting repro steps.

I'll look to do some additional manual testing in hopes of surfacing the repro more reliably.

If reporting users are able to provide additional thoughts about repro or if they can ship a device that fails easily that might speed the investigation.

Also if you are successful using the hang debug steps in #comment7

1. hit alt-volup-x key combination 3 times within a 10 second period.  Wait about 5 seconds. If the system reboots, file feedback report. If not, go to the step below.
2. hit alt-volup-r key combo once. If the system reboots, file feedback report. 
 If not, go to the step below.
3. hit power+refresh key combo once. The system will reboots here. File feedback report.

and do file feedback please post which step worked.  If steps 1 or 2 are successful there may be additional detail in the feedback report to help identify the root cause.