Bug#615110: tpm_tis prevents suspend working more than once
tags 615110 - moreinfo
# extrapolating since there was no 3.2-rc2 package
found 615110 linux-2.6/3.1.0-1~experimental.1
forwarded 615110 http://thread.gmane.org/gmane.linux.kernel/1119143/focus=1119476
John Hughes wrote:
> This bug is still present as of 3.2.0
> Linux carbon 3.2.0-rc2+ #2 SMP Thu Dec 8 20:28:12 CET 2011 i686 GNU/Linux
> [ 295.064214] Suspending console(s) (use no_console_suspend to debug)
> [ 295.124146] legacy_suspend(): pnp_bus_suspend+0x0/0x57 returns 38
> [ 295.124154] PM: Device 00:07 failed to suspend: error 38
> [ 295.124160] PM: Some devices failed to suspend
> $ readlink /sys/devices/pnp0/00:07/driver
Thanks. Do you know the commit id of this 3.2-rc2+ kernel? From 
| Ok, so this error code means TPM_INVALID_POSTINIT (not a posix code)
| and means that this command was received in the wrong sequence relative
| to a TPM_Startup command. Well, what's supposed to be happening is this:
| When the machines (S3) suspends then the OS needs to send a
| TPM_SaveState() to the TPM. This is done by the Linux driver. Once the
| VM resumes, the BIOS is supposed to send a TPM_Startup(ST_STATE) to the TPM.
| Now the fun starts when a BIOS isn't doing that (even though the spec
| says it's supposed to), which could very well be the case in your case
| (don't know what broken BIOSes are out there... Did it ever work before
| with the TPM driver in the kernel ?). I could try to send you a small
| tool that you would have to run from user space upon resume so that we
| can see that this error goes away.
and there's a workaround in the same message you can try.
| The failure of the 2nd suspend then likely stems from the TPM not
| accepting the TPM_SaveState() anymore since it hasn't seen the
| TPM_Startup(ST_STATE) that we expected the BIOS to send.
That thread also proposes an approach to fixing this:
> - send a command to the TPM upon resume and if it returns with error
> code 38 send TPM_Startup(ST_STATE) -> this masks the BIOS problem; log
> this case; TPM stays usable; machine will suspend a 2nd time; a
> colleague tells me it may not be 'safe'
I don't know if anyone tried that.
There have been some tpm fixes upstream recently, so results from
testing v3.3-rc1 or later would be interesting.