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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
