Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 17 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment
Suspend/resume issues with Pixel Legacy boot path
Project Member Reported by dlaurie@chromium.org, Mar 11 2013 Back to list
Chrome Version     :  N/A
OS Version         :  Legcy
Type of computer   :  Chromebook Pixel
Network info       :  N/A

Suspend/resume is effectively broken when booting an OS via the Legacy boot path on Pixel.

The observed behavior is that the first suspend and resume will be successful and subsequent attempts to suspend will work, but then when the system wakes up it will reset instead of resuming.

The event log shows the following:

44 | 2013-03-10 14:12:56 | System boot | 90
45 | 2013-03-10 14:12:56 | System Reset
46 | 2013-03-10 14:12:57 | Chrome OS Developer Mode
47 | 2013-03-10 14:14:13 | ACPI Enter | S3
48 | 2013-03-10 14:14:16 | EC Event | Key Pressed
49 | 2013-03-10 14:14:16 | ACPI Wake | S3
50 | 2013-03-10 14:14:16 | Wake Source | GPIO | 14
51 | 2013-03-10 14:14:16 | Wake Source | GPIO | 15
52 | 2013-03-10 14:14:33 | ACPI Enter | S3
53 | 2013-03-10 14:14:37 | System boot | 91
54 | 2013-03-10 14:14:37 | Last post code in previous boot | 0x3f
55 | 2013-03-10 14:14:37 | System Reset

Which shows that the first s3 transition was successful but the second resulted in a reset with the last post code of 0x3f.

The reset in this case is happening because the TPM resume command (actually TPM_Startup(ST_STATE)) is failing.  The command is failing because the TPM was not sent a TPM_SaveState command before entering suspend.

The workaround for the first part of this issue is to load the tpm driver in the kernel with "modprobe tpm_tis force=1 interrupts=0".  This driver is compiled into the ChromeOS kernel and the arguments are passed on the kernel command line.

(note: It should be possible to load this driver automatically if there was a valid ACPI device entry for the TPM)

Once the driver is loaded another problem is exposed in that the first suspend attempt (or the first few attempts) after a reboot will be aborted with the kernel complaining:

tpm_tis tpm_tis: A TPM error (2048) occurred sending savestate before suspend

The cause for this issue is more subtle and harder to work around.

There is a firmware bug[1] in the legacy path where it is incorrectly sending a TPM_SaveState command before it jumps to SeaBIOS.  Unfortunately this command is sent while still in signed firmware before SeaBIOS is running so it is not something end users can fix since it requires an official signed update.

The TPM_SaveState command is only supposed to be sent before transitioning into suspend, and the TPM expects the next action in the state machine to be TPM_Init (i.e. LPC Reset), followed by TPM_Startup(ST_STATE) to restore the saved state.

Instead what happens when the loading the tpm+tpm_tis driver is some additional commands are sent during the initialization path, particularly TPM_SelfTest, TPM_PcrRead, and TPM_GetCapability.  This invalidates the previously saved state and causes the TPM to do extra time-consuming work (like re-generating PCRs) the next time the state is saved.

Unfortunately it does not appear to be possible to transition the TPM back into a happy point in its state machine without going through a reset/TPM_Init first.  I experimented with different command sequences, even trying the deprecated TPM_Reset command but none of these appear to be a reliable workaround.


The specification at first seems to say that additional commands after a TPM_SaveState isn't really prohibited:

TCG PC Client TIS (TPM Init Spec) 1.21
4. Power Management
The TPM_SaveState command allows a Static OS to indicate to the TPM that the platform may enter a low power state where the TPM will be required to enter into the D3 power state. The use of the term “may” is significant in that there is no requirement for the platform to actually enter the low power state after sending the TPM_SaveState command. The software may, in fact, send subsequent commands after sending the TPM_SaveState commands.


But then in other places it says not to do this and leaves the exact behavior up to the TPM implementation:

TCG PC Client BIS (BIOS Init Spec) 1.21
8.3.1 General Host Platform and OS Power Requirements
After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM commands before transitioning to S3 without issuing another TPM_SaveState command.

TPM Main Level 2 Part 3 (v1.2 r116)
3.3 TPM_SaveState
The TPM MAY declare all preserved values invalid in response to any command other than TPM_Init.

TPM Main Level 2 Part 1 (v1.2 r116)
19. Audit Commands
Any command after TPM_SaveState MAY invalidate the saved state. 


How to deal with this issue?

1) Obviously the best way to deal with this is to fix the signed firmware to stop sending that command in the legacy path.  It was introduced in an attempt to placate Windows, but is clearly the wrong thing to do in this case.  I will get the appropriate change into the firmware but unfortunately the decision to actually release a Google signed update comes from product management and it may be a hard sell for something that isn't seen in the ChromeOS boot path.


2) Another possibility is to deal with this in the driver.  The TPM is responding with a non-fatal TPM_RETRY/0x800 code, which according to the spec means:

"The TPM is too busy to respond to the command immediately, but the command could be resubmitted at a later time.  The TPM MAY return TPM_RETRY for any command at any time."

So it could be argued that the driver should be retrying this command in the suspend path if it gets a TPM_RETRY return code.  Now obviously this is a self-inflicted problem, but it is possible to recreate this situation on other systems by sending a TPM_SaveState command via /dev/tpm0 and then doing some other TPM activity before attempting suspend.

It did appear to be successful when I wrapped the TPM_SaveState call in tpm.c:tpm_pm_suspend() to retry when TPM_RETRY/0x800 is returned.  It needs a decent timeout in the retry loop as it can take a couple seconds for the command to complete.


3) Userland workarounds.  Once the system boots and driver has been loaded it is possible to send the TPM_SaveState command via /dev/tpm0 and trigger this long invalidation at runtime.  Then, as long as nothing else is sent to the TPM, the driver does not have a problem sending TPM_SaveState on the way into suspend.

Unfortunately the TPM_SaveState command is not exported in the standard 'tpm-tools' package, probably because it is a bad idea to send this at runtime.  It is available in the 'tpmc' utility that is part of the ChromeOS verified boot reference implementation.

An even uglier workaround would be to not load the TPM driver until after the first suspend.


[1] https://gerrit.chromium.org/gerrit/gitweb?p=chromiumos/third_party/u-boot.git;a=commitdiff;h=56be69f8d4b72efe78956690c9dd532bca2e6655
 
Cc: olofj@chromium.org semenzato@chromium.org
It is also worth noting that the TPM driver is automatically loaded if there is an ACPI Device entry for it.  We should fix this for future platforms but for Pixel it is possible for SeaBIOS to add a new SSDT containing the TPM device.  It isn't pretty but it does work and I will post a patch for it.
Project Member Comment 3 by bugdroid1@chromium.org, Mar 20 2013
Labels: -Project-Link Proj-Link
Project Member Comment 4 by bugdroid1@chromium.org, Mar 20 2013
Project: chromiumos/third_party/u-boot
Branch : chromeos-v2011.12
Author : Duncan Laurie <dlaurie@chromium.org>
Commit : f92a676aad3b3c6bf9411f34f4317abc95bc8149

Code Review +2: Stefan Reinauer
Verified    +1: Duncan Laurie
Change-Id     : I17c236bc733b0492e938f1add44bf6f41ebdbcb8
Reviewed-at   : https://gerrit.chromium.org/gerrit/45239

Revert "cros: x86: bring TPM into a consistent state before entering SeaBIOS"

This reverts commit 56be69f8d4b72efe78956690c9dd532bca2e6655.

Sending a TPM_SaveState command should only happen immediately before suspend,
otherwise additional communication with the TPM can make it very unhappy when
TPM_SaveState is sent again.

BUG=chromium-os:39806
BRANCH=link
TEST=manual: Build and boot the firmware on link and ensure that the TPM
driver has no issues sending TPM_SaveState on the way into suspend.

Signed-off-by: Duncan Laurie <dlaurie@chromium.org>

M  cros/coreboot/legacy.c
Project Member Comment 5 by bugdroid1@chromium.org, Mar 27 2013
Project: chromiumos/third_party/u-boot
Branch : firmware-link-2695.B
Author : Duncan Laurie <dlaurie@chromium.org>
Commit : 6acf91ce95ab2015fbe7c9cdd68d689c84eded52

Code Review  +2: Bill Richardson
Verified     +1: Stefan Reinauer
Commit Ready   : Stefan Reinauer
Change-Id      : I36d0bcf7d19d6bff9b120c5e38fa815f5d25242e
Reviewed-at    : https://gerrit.chromium.org/gerrit/46691

Revert "cros: x86: bring TPM into a consistent state before entering SeaBIOS"

This reverts commit 56be69f8d4b72efe78956690c9dd532bca2e6655.

Sending a TPM_SaveState command should only happen immediately before suspend,
otherwise additional communication with the TPM can make it very unhappy when
TPM_SaveState is sent again.

BUG=chromium-os:39806
BRANCH=link
TEST=manual: Build and boot the firmware on link and ensure that the TPM
driver has no issues sending TPM_SaveState on the way into suspend.

Signed-off-by: Duncan Laurie <dlaurie@chromium.org>

(cherry picked from commit f92a676aad3b3c6bf9411f34f4317abc95bc8149)

Commit-Queue: Stefan Reinauer <reinauer@google.com>

M  cros/coreboot/legacy.c
Project Member Comment 6 by bugdroid1@chromium.org, Apr 19 2013
Project: chromiumos/third_party/seabios
Branch : chromeos-2012.05.12
Author : Duncan Laurie <dlaurie@chromium.org>
Commit : 5baf4b63529f0f7b13e19609c4173e3f61231e84

Code Review +2: Stefan Reinauer
Verified    +1: Duncan Laurie
Change-Id     : I049a4975fdd2265864e14d482484c7eb9191bcbd
Reviewed-at   : https://gerrit.chromium.org/gerrit/45261

link: Hack to add ACPI SSDT containing a TPM device

The ACPI DSDT on Link is missing the TPM Device on the LPC bus.
This means that the TPM driver does not automatically load and
must be forced with a module parameter.

This change will find the existing SSDT and add a new SSDT after
it and then add that new table to the RDST/XSDT so it can be found.

BUG=chromium-os:39806
BRANCH=link
TEST=manual: Boot Fedora with the 3.9-rc2 kernel and see that the
TPM driver modules are loaded and were able to detect the TPM.

Also read out the new SSDT and verify that the table is correct
and matches the table that is in the source:

$ sudo cat /sys/firmware/acpi/tables/SSDT2 > /tmp/SSDT2
$ iasl -d /tmp/SSDT2
$ cat /tmp/SSDT2.dsl # compare the output to the source

Signed-off-by: Duncan Laurie <dlaurie@chromium.org>

M  Makefile
A  src/acpi_tpm_fixup.c
A  src/acpi_tpm_fixup.h
M  src/post.c
Comment 7 by olofj@chromium.org, Apr 19 2013
FWIW, the upstream TPM maintainer has also applied Duncan's driver workaround, I would expect it to be merged for 3.10-rc1.
Project Member Comment 8 by bugdroid1@chromium.org, Aug 21 2013
Project: chromiumos/third_party/seabios
Branch : firmware-link-2695.B
Author : Duncan Laurie <dlaurie@chromium.org>
Commit : 187a6c83de86811f645780f88986e9a5e5ac62c5

Code Review +2: Duncan Laurie
Verified    +1: Duncan Laurie
Change-Id     : I7ba286e92b6456a254a3e8978b1ebd7c98e1e20a
Reviewed-at   : https://gerrit.chromium.org/gerrit/66565

link: Hack to add ACPI SSDT containing a TPM device

The ACPI DSDT on Link is missing the TPM Device on the LPC bus.
This means that the TPM driver does not automatically load and
must be forced with a module parameter.

This change will find the existing SSDT and add a new SSDT after
it and then add that new table to the RDST/XSDT so it can be found.

BUG=chromium-os:39806
BRANCH=link
TEST=manual: Boot Fedora with the 3.9-rc2 kernel and see that the
TPM driver modules are loaded and were able to detect the TPM.

Also read out the new SSDT and verify that the table is correct
and matches the table that is in the source:

$ sudo cat /sys/firmware/acpi/tables/SSDT2 > /tmp/SSDT2
$ iasl -d /tmp/SSDT2
$ cat /tmp/SSDT2.dsl # compare the output to the source

Original-Change-Id: I049a4975fdd2265864e14d482484c7eb9191bcbd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 5baf4b63529f0f7b13e19609c4173e3f61231e84)

Signed-off-by: Duncan Laurie <dlaurie@chromium.org>

M  Makefile
A  src/acpi_tpm_fixup.c
A  src/acpi_tpm_fixup.h
M  src/post.c
Comment 9 by benhenry@google.com, Nov 26 2013
Status: Assigned
In case this is useful to others, using "modprobe tpm_tis force=1 interrupts=0" to work around the issue mentioned here has been a solid performer until around kernel 3.13. After installing 3.13.9 a while back and 3.14.2 today, it looks like the tpm_tis driver doesn't get loaded at all according to lsmod and dmseg:
[    1.602644] IMA: No TPM chip found, activating TPM-bypass!

This ends up causing the second suspend to reboot the system as outlined in the first mail here.

The 3.12 family of kernels does still have the workaround functioning correctly.

Please let me know if there's more info I can provide or a better place to report this.
Sorry folks, I should have commented on this earlier.

Error 2048 (0x800) is TPM_E_RETRY which is often used by TPMs to slow down the NVRAM write rate and limit wear.  We have seen in suspend-resume tests for instance.  I am not looking at the code right now, but I thought we waited a bit and retried a few times when this happens.  Not sure why it's failing, but it seems strange that the TPM would not recover from a 0x800 just by waiting, maybe there is a bug in the TPM.
As an update, since Ubuntu Trusty uses kernel 3.13 by default, suspending and resuming fail out of the box even with the workaround listed here, unless the kernel is downgraded to the 3.12 family.

Is there anything I can provide to help out?
There was a regression in the kernel TPM driver that was causing it to fail to load at boot if a magic ACPI table is missing and so it never sends the appropriate commands to the TPM before suspend, even if the TPM is loaded with force=1.

Hopefully this patch will go in that will fix it:  http://sourceforge.net/p/tpmdd/mailman/message/32361653/
Thanks for the patch. I just tested 3.15.3, and the tpm_tis module still doesn't load, even though it looks like your patch made it into 3.15-rc6 here:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc6-utopic/CHANGES

When I run this kernel, I still get:
$ dmesg | grep TPM
[    1.630955] ima: No TPM chip found, activating TPM-bypass!

And the second suspend fails as described above.

Please let me know if there's any way I can help, I'm happy to test kernels out.
I'm having exactly the same problems Benjamin describes. Upgraded to kernel 3.15.7 but it still happens. Any chance of a fix or work-around in the near future?
Ken, the 3.15.6 kernel is working fine for me, as did 3.15.5.  Haven't tried 3.15.7 yet.  Are you sure you are using tpm_tis.force=1 tpm_tis.interrupts=0?  Are you using some non-standard source that doesn't include the fix?
Lon, per your comment I just tried 3.15.8, and see that the tpm module does not get loaded, and I can confirm that the second suspend still halts the system.

I'm curious how you made it work; can you send along your: 
/etc/modules 
output of: lsmod
output of: dmesg | grep TPM
anything you load manually with modprobe
what distro are you running?

Thanks a lot, maybe we can figure out why this works for you.

Just figured it out. The only way to apply this workaround was to supply the tpm module arguguments in /etc/modules:
tpm_tis force=1 interrupts=0

Whereas the new way to apply this workaround is to put the arguments in your /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.lvds_downclock=1 tpm_tis.force=1 tpm_tis.interrupts=0"

Lon, thank you for the argument line, it pointed me to the right place to put things.

3.15.8 works just fine for me now.
Ah hah. Adding it to the kernel command line fixed the problem for me as well. Thanks!
The problem for me persists, but perhaps differently.  I'm running Fedora 20 on an Acer C720, but I'm using the 3.17 kernel from rawhide
$ uname -r
3.17.0-0.rc5.git3.1.fc22.x86_64

I have, as recommended

$ grep LINUX /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.lvds_downclock=1 tpm_tis.force=1 tpm_tis.interrupts=0"

I see two different behavior.  1.  When I"m logged out, and close the lid, the power light turns orange, but turns back blue.  When I open the lid, the screen stays black---cannot be woken up. 2) When I am logged in, and close the lid, the poer light does the same, and when I open he lid, I see a locked screen, and I can log in. But switching to VT1, the following error runs continuously

... ehci-pci 0000:00:1d:0: port 1 resume-error -19 

Sometimes the port 1 part changes to port 2.

I remark that I saw the same behavior with the stock 3.16 kernel. In fact, I switched to the 3.17 kernel to see if things improved.

Instead of closing the lid, when I use -pm-suspend, the suspend works for a few seconds, and then it wakes up.  Here is what I see

sudo time pm-suspend
[sudo] password for marci: 
0.23user 1.19system 0:04.88elapsed 29%CPU (0avgtext+0avgdata 3276maxresident)k
1144inputs+32outputs (8major+24327minor)pagefaults 0swaps
[marci@localhost ~]$ dmesg|tail
[  804.134987] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.160992] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.186981] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.212973] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.238975] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.264976] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.290961] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.316955] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.345365] ehci-pci 0000:00:1d.0: port 2 resume error -19
[  804.370853] ehci-pci 0000:00:1d.0: port 2 resume error -19

pm-hibernate is working fine.  I'm attaching the pm-suspend log file.  As you can see, it takes 3 seconds to wake up.  
pm-suspend.log
8.6 KB View Download
Comment 22 by zoo...@gmail.com, Jan 9 2015
I have the same behavior — suspend works the first time after a reboot, but it wakes itself up from suspend on every time after the first time. My Google Chromebook Pixel, running Ubuntu 14.04.1, with (my own locally-compiled) kernel 3.18.1.

I tried https://code.google.com/p/chromium/issues/detail?id=221905#c21 and got the same behavior:

zooko@spark ~ $ sudo time pm-suspend
0.07user 0.21system 0:10.37elapsed 2%CPU (0avgtext+0avgdata 3504maxresident)k
432inputs+20736outputs (0major+38437minor)pagefaults 0swaps

The workaround posted on https://bugs.launchpad.net/chromium/+bug/1224689/comments/7 doesn't work for me:

sudo  modprobe -r tpm_tis
sudo  modprobe tpm_tis force=1 interrupts=0

Curiously, I didn't have this problem for a long time, but I started getting it when I upgraded my Linux kernel.

The rest of this comment is the relevant excerpt from /var/log/syslog:
Jan  9 16:52:30 spark kernel: [ 4827.361375] PM: Syncing filesystems ... done.
Jan  9 16:52:30 spark kernel: [ 4827.806135] PM: Preparing system for mem sleep
Jan  9 16:52:30 spark kernel: [ 4827.806285] Freezing user space processes ... (elapsed 0.001 seconds) done.
Jan  9 16:52:30 spark kernel: [ 4827.808218] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Jan  9 16:52:30 spark kernel: [ 4827.809573] PM: Entering mem sleep
Jan  9 16:52:30 spark kernel: [ 4827.809587] Suspending console(s) (use no_console_suspend to debug)
Jan  9 16:52:30 spark kernel: [ 4827.877145] wlan0: deauthenticating from 40:16:7e:60:46:40 by local choice (Reason: 3=DEAUTH_LEAVING)
Jan  9 16:52:30 spark kernel: [ 4827.889305] sd 0:0:0:0: [sda] Synchronizing SCSI cache
Jan  9 16:52:30 spark kernel: [ 4827.889422] sd 0:0:0:0: [sda] Stopping disk
Jan  9 16:52:30 spark kernel: [ 4827.889427] cfg80211: All devices are disconnected, going to restore regulatory settings
Jan  9 16:52:30 spark kernel: [ 4827.889436] cfg80211: Restoring regulatory settings
Jan  9 16:52:30 spark kernel: [ 4827.889439] cfg80211: Kicking the queue
Jan  9 16:52:30 spark kernel: [ 4827.889441] cfg80211: Calling CRDA to update world regulatory domain
Jan  9 16:52:30 spark kernel: [ 4828.206696] PM: suspend of devices complete after 397.087 msecs
Jan  9 16:52:30 spark kernel: [ 4828.206698] PM: suspend devices took 0.397 seconds
Jan  9 16:52:30 spark kernel: [ 4828.217454] PM: late suspend of devices complete after 10.753 msecs
Jan  9 16:52:30 spark kernel: [ 4828.218304] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
Jan  9 16:52:30 spark kernel: [ 4828.218381] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
Jan  9 16:52:30 spark kernel: [ 4828.229358] PM: noirq suspend of devices complete after 11.903 msecs
Jan  9 16:52:30 spark kernel: [ 4828.229652] ACPI: Preparing to enter system sleep state S3
Jan  9 16:52:30 spark kernel: [ 4828.229723] PM: Saving platform NVS memory
Jan  9 16:52:30 spark kernel: [ 4828.229724] Disabling non-boot CPUs ...
Jan  9 16:52:30 spark kernel: [ 4828.229783] intel_pstate CPU 1 exiting
Jan  9 16:52:30 spark kernel: [ 4828.231046] kvm: disabling virtualization on CPU1
Jan  9 16:52:30 spark kernel: [ 4828.231077] smpboot: CPU 1 is now offline
Jan  9 16:52:30 spark kernel: [ 4828.231463] intel_pstate CPU 2 exiting
Jan  9 16:52:30 spark kernel: [ 4828.232697] kvm: disabling virtualization on CPU2
Jan  9 16:52:30 spark kernel: [ 4828.232708] smpboot: CPU 2 is now offline
Jan  9 16:52:30 spark kernel: [ 4828.233084] intel_pstate CPU 3 exiting
Jan  9 16:52:30 spark kernel: [ 4828.234288] kvm: disabling virtualization on CPU3
Jan  9 16:52:30 spark kernel: [ 4828.234300] smpboot: CPU 3 is now offline
Jan  9 16:52:30 spark kernel: [ 4828.235817] ACPI: Low-level resume complete
Jan  9 16:52:30 spark kernel: [ 4828.235861] PM: Restoring platform NVS memory
Jan  9 16:52:30 spark kernel: [ 4828.236189] Enabling non-boot CPUs ...
Jan  9 16:52:30 spark kernel: [ 4828.236234] x86: Booting SMP configuration:
Jan  9 16:52:30 spark kernel: [ 4828.236235] smpboot: Booting Node 0 Processor 1 APIC 0x1
Jan  9 16:52:30 spark kernel: [ 4828.247932] kvm: enabling virtualization on CPU1
Jan  9 16:52:30 spark kernel: [ 4828.250256] CPU1 is up
Jan  9 16:52:30 spark kernel: [ 4828.250281] smpboot: Booting Node 0 Processor 2 APIC 0x2
Jan  9 16:52:30 spark kernel: [ 4828.261869] kvm: enabling virtualization on CPU2
Jan  9 16:52:30 spark kernel: [ 4828.264191] CPU2 is up
Jan  9 16:52:30 spark kernel: [ 4828.264217] smpboot: Booting Node 0 Processor 3 APIC 0x3
Jan  9 16:52:30 spark kernel: [ 4828.275814] kvm: enabling virtualization on CPU3
Jan  9 16:52:30 spark kernel: [ 4828.278152] CPU3 is up
Jan  9 16:52:30 spark kernel: [ 4828.281582] ACPI: Waking up from system sleep state S3
Jan  9 16:52:30 spark kernel: [ 4828.291908] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI
Jan  9 16:52:30 spark kernel: [ 4828.292001] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
Jan  9 16:52:30 spark kernel: [ 4828.293061] PM: noirq resume of devices complete after 11.358 msecs
Jan  9 16:52:30 spark kernel: [ 4828.293750] PM: early resume of devices complete after 0.657 msecs
Jan  9 16:52:30 spark kernel: [ 4828.295965] snd_hda_intel 0000:00:1b.0: irq 27 for MSI/MSI-X
Jan  9 16:52:30 spark kernel: [ 4828.296086] ath: phy0: ASPM enabled: 0x43
Jan  9 16:52:30 spark kernel: [ 4828.296120] rtc_cmos 00:03: System wakeup disabled by ACPI
Jan  9 16:52:30 spark kernel: [ 4828.303923] sd 0:0:0:0: [sda] Starting disk
Jan  9 16:52:30 spark kernel: [ 4828.502903] usb 1-1.1: reset high-speed USB device number 3 using ehci-pci
Jan  9 16:52:30 spark kernel: [ 4828.511895] usb 2-1.3: reset high-speed USB device number 5 using ehci-pci
Jan  9 16:52:30 spark kernel: [ 4828.604714] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jan  9 16:52:30 spark kernel: [ 4828.607101] ata1.00: configured for UDMA/133
Jan  9 16:52:30 spark kernel: [ 4828.654022] usb 1-1.2: reset full-speed USB device number 11 using ehci-pci
Jan  9 16:52:30 spark kernel: [ 4828.738980] usb 1-1.2: device firmware changed
Jan  9 16:52:30 spark kernel: [ 4828.848742] usb 2-1.2: reset low-speed USB device number 3 using ehci-pci
Jan  9 16:52:30 spark kernel: [ 4829.319491] atmel_mxt_ts 2-004b: __mxt_write_reg: i2c send failed (-6)
Jan  9 16:52:30 spark kernel: [ 4829.367613] usb 2-1.3.1: reset low-speed USB device number 6 using ehci-pci
Jan  9 16:52:30 spark kernel: [ 4829.704480] PM: resume of devices complete after 1411.172 msecs
Jan  9 16:52:30 spark kernel: [ 4829.704691] PM: resume devices took 1.412 seconds
Jan  9 16:52:30 spark kernel: [ 4829.704739] PM: Finishing wakeup.

Comment 23 by Deleted ...@, May 27 2015
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner may be inactive (i.e. hasn't fixed an issue in the last 30 days or commented in this particular issue in the last 90 days).  Thanks for helping out!

-Anthony
Comment 25 by zoo...@gmail.com, Feb 10 2016
This stopped happening for me, and I happily ran with fully operational suspend/resume for a long time using the Linux-4.1.y series. Most recently Linux-4.1.17. However, a few days ago I upgraded from Linux-4.1.17 to the 4.4.y series — currently Linux-4.4.1 — and now the same symptoms happen again: after closing the lid, when I open the lid later I find it has powered down and it is now booting up.

Rebooting back into my Linux-4.1.17 kernel fixes it — as long as I've booted to that kernel then I can suspend-and-resume to my heart's content.
Labels: -Hotlist-Recharge -Proj-Link hotlist-recharge proj-link
@zoo did you ever find a resolution?
Comment 27 by olofj@chromium.org, May 27 2016
Cc: olofj@google.com
Comment 28 by olofj@chromium.org, May 27 2016
Cc: -olofj@chromium.org -olofj@google.com
Labels: -proj-link Proj-Link
Just FYI seems that this is reproducible with current mainline (4.8 and 4.9-rc1). Also the proposed solution of passing "modprobe tpm_tis force=1 interrupts=0" doesn't seems to help
Running Ubuntu 17.04 with 4.10.0-19-generic kernel and running into this issue. The workaround of running "modprobe tpm_tis force=1 interrupts=0" also does not help for me. 

I did notice systemd complaining just before the system was supposed to sleep, with a few networking items before this:

Jul  6 19:47:42 SilverLine systemd-sleep[1920]: /lib/systemd/system-sleep/wpasupplicant failed with error code 255.
Jul  6 19:47:42 SilverLine systemd-sleep[1919]: Suspending system...

But I'm not sure if that's even related. 
I am running Fedora 26 with 4.12.8-300.fc26 and can verify that this is still an issue after applying the modprobe command. 
I've seen this issue come and go a half dozen times now, but haven't looked into what precisely is happening. Low numbered kernels often seem to fail, but eventually someone seems to fix it again. Currently, 4.13.3 does not work for me, but 4.12.14 does. And some recent 4.9.x worked also, which might be the best choice (LTS).

I would have expected the 4.12.8 kernel to work; it might be better to use the kernel command line, instead of modprobe, to set "tpm_tis.force=1 tpm_tis.interrupts=0".
Sign in to add a comment