[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
# [1]
forwarded 615110 http://thread.gmane.org/gmane.linux.kernel/1119143/focus=1119476
quit

Hi,

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
> ../../../bus/pnp/drivers/tpm_tis

Thanks.  Do you know the commit id of this 3.2-rc2+ kernel?  From [1]
we learn:

| 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.

Jonathan



Reply to: