You are not logged in.

#1 2014-02-05 10:44:45

brianbaligad
Member
Registered: 2013-08-12
Posts: 22

[SOLVED] Chromebook Pixel suspend

Solved: This is a known issue, and some workarounds are discussed in the issue tracker.  We can fix this issue today by enabling tpm (other issues mentioned on the tracker seem to be resolved):

modprobe tpm_tis force=1 interrupts=0

Hello, I'm trying to troubleshoot an issue with Suspend to RAM on a Chromebook Pixel running Arch with kernel 3.12.9-1 x86_64.  As a temporary workaround, I've been using hibernate instead of suspend, because it works every time.

Problem: After turning the Chromebook on, the first suspend/resume always works fine. But the second time I resume from suspend, the system always restarts. This happens whether using systemctl suspend, or echo mem > /sys/power/state.  This also happens in console mode without X running (I confirmed this by reproducing the issue using the arch 2012.08 installer image).

journalctl -r

-- Reboot --
Feb 05 01:53:04 brianb-cb systemd[1]: Starting Suspend...
Feb 05 01:53:04 brianb-cb systemd[1]: Reached target Sleep.
Feb 05 01:53:04 brianb-cb systemd[1]: Starting Sleep.
Feb 05 01:53:04 brianb-cb sudo[536]: pam_unix(sudo:session): session opened for user root by (uid=0)
Feb 05 01:53:04 brianb-cb sudo[536]: brianb : TTY=pts/0 ; PWD=/home/brianb ; USER=root ; COMMAND=/usr/bin/systemctl suspend
Feb 05 01:52:53 brianb-cb systemd[309]: Reached target Bluetooth.
Feb 05 01:52:53 brianb-cb systemd[309]: Starting Bluetooth.
Feb 05 01:52:53 brianb-cb systemd[1]: Reached target Bluetooth.
Feb 05 01:52:53 brianb-cb systemd[1]: Starting Bluetooth.
Feb 05 01:52:53 brianb-cb kernel: usb 1-1.2: string descriptor 0 read error: -22
Feb 05 01:52:53 brianb-cb kernel: usb 1-1.2: new full-speed USB device number 12 using ehci-pci
Feb 05 01:52:52 brianb-cb kernel: usb 1-1.2: USB disconnect, device number 11
Feb 05 01:52:52 brianb-cb kernel: usb 1-1.2: string descriptor 0 read error: -22
Feb 05 01:52:52 brianb-cb kernel: usb 1-1.2: new full-speed USB device number 11 using ehci-pci
Feb 05 01:52:52 brianb-cb kernel: usb 1-1.2: USB disconnect, device number 10
Feb 05 01:52:52 brianb-cb kernel: video LNXVIDEO:00: Restoring backlight state
Feb 05 01:52:52 brianb-cb kernel: Restarting tasks ... done.
Feb 05 01:52:52 brianb-cb kernel: PM: Finishing wakeup.
Feb 05 01:52:52 brianb-cb kernel: PM: resume of devices complete after 1580.109 msecs
Feb 05 01:52:52 brianb-cb kernel: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off

cat /proc/cmdline

BOOT_IMAGE=/vmlinuz-linux root=UUID=f0c4ad70-b8d3-4076-80f3-af97c7d3ebda rw cryptdevice=/dev/sda4:cb_crypt resume=/dev/sda3 quiet

I did not find any messages in dmesg corresponding with the reboot on second resume.  Intel suggests removing modules or dumping registers which I'll try to do next. I also need to figure out how to fix the usb error message, since it could be related. (hmm, maybe not) I figured asking here because it feels like I'm missing something simple; I haven't seen any other similar reports from Pixel users here.

Last edited by brianbaligad (2014-02-08 18:02:47)

Offline

#2 2014-02-07 17:58:05

brianbaligad
Member
Registered: 2013-08-12
Posts: 22

Re: [SOLVED] Chromebook Pixel suspend

I noticed after the system reboots from the second suspend, there will be an error and the keyboard won't work.  I have to power cycle the system to get a working keyboard in the init environment (for cryptsetup password entry).  The error says:

Can't read CTR while initializing i8042

I did try removing kernel modules as Intel suggests:

nomodeset modprobe.blacklist=i915,drm

The system suspends to ram, but doesn't bring the display back up after the first resume (probably for obvious reasons). I know the system is awake again because a usb device led will be on.  I can (blindly) run systemctl suspend again and the system will reboot immediately.  The difference here is that without the i915 driver, the system reboots on the second suspend immediately, rather than when it is resumed from the second suspend. I don't know if that tells us anything.

Someone recommended trying a newer kernel.  I installed linux-mainline 3.14rc1-1, but unfortunately it has the same issue. For whatever its worth, here are the results of intel_reg_dumper (the Intel article suggests collecting this information).   I guess I'll have to stick to using hibernate for now.  As a side note,  I also found that the keyboard didn't work at all with this kernel; I had to temporarily use a usb keyboard.

Update: Whups, a little more Google searching would have saved me some time: https://code.google.com/p/chromium/issu … ?id=221905

Last edited by brianbaligad (2014-02-08 17:21:08)

Offline

Board footer

Powered by FluxBB