TPM chip prevents machine from suspending
Jeff Layton
to Fedora 14, it fails to suspend consistently. On the first attempt to
suspend it, it works fine. Once it has woken back up however, it will
not suspend again. Here's the dmesg log from such an attempt:
[ 202.460967] PM: Syncing filesystems ... done.
[ 202.464818] PM: Preparing system for mem sleep
[ 202.485968] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 202.497079] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 202.508067] PM: Entering mem sleep
[ 202.508086] Suspending console(s) (use no_console_suspend to debug)
[ 202.508451] sd 3:0:0:0: [sdb] Synchronizing SCSI cache
[ 202.508562] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 202.508616] sd 3:0:0:0: [sdb] Stopping disk
[ 202.511956] parport_pc 00:0b: disabled
[ 202.512127] serial 00:09: disabled
[ 202.512134] serial 00:09: wake-up capability disabled by ACPI
[ 202.536058] legacy_suspend(): pnp_bus_suspend+0x0/0x82 returns 38
[ 202.536061] PM: Device 00:02 failed to suspend: error 38
[ 202.997517] sd 2:0:0:0: [sda] Stopping disk
[ 202.997806] PM: Some devices failed to suspend
[ 202.998085] sd 2:0:0:0: [sda] Starting disk
[ 202.998144] sd 3:0:0:0: [sdb] Starting disk
[ 202.998614] serial 00:09: activated
[ 202.999158] parport_pc 00:0b: activated
[ 204.543094] PM: resume of devices complete after 1545.282 msecs
[ 204.543268] PM: Finishing wakeup.
[ 204.543270] Restarting tasks ... done.
...error 38 is ENOSYS, and the 00:02 is this:
# cat /sys/bus/pnp/devices/00\:02/id
IFX0102
PNP0c31
That appears to be an Infineon TPM chip:
# modinfo tpm_infineon
filename: /lib/modules/2.6.38.2-8.fc15.x86_64/kernel/drivers/char/tpm/tpm_infineon.ko
license: GPL
version: 1.9.2
description: Driver for Infineon TPM SLD 9630 TT 1.1 / SLB 9635 TT 1.2
author: Marcel Selhorst <m.sel...@sirrix.com>
srcversion: 01A807F04E1D1EC617254C4
alias: acpi*:IFX0102:*
alias: pnp:dIFX0102*
alias: acpi*:IFX0101:*
alias: pnp:dIFX0101*
depends:
vermagic: 2.6.38.2-8.fc15.x86_64 SMP mod_unload
Perhaps it's not being reset correctly on the initial wakeup? I've seen
some other emails about similar problems that were fixed a few releases
ago, but I can reproduce the above behavior with kernels as late as
2.6.38.2. Specifically, the above log is from the most recent kernel I
could find in Fedora koji:
2.6.38.2-8.fc15.x86_64
Let me know if you need other info or need me to test patches.
Thanks,
--
Jeff Layton <jla...@poochiereds.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Stefan Berger
module that laptop was using (tpm_tis or tpm_infineon) and try whether
one of them works better than the other one? Please do a reboot between
trying one and then the other.
Try the following before and after a suspend/resume:
cd /sys
find . | grep caps$ | xargs cat
It should display manufacturer data.
Stefan
Jeff Layton
It's using tpm_tis:
lrwxrwxrwx. 1 root root 0 Mar 28 13:40 /sys/bus/pnp/devices/00:02/driver -> ../../../bus/pnp/drivers/tpm_tis
FWIW, the fedora kernels have this:
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
When I boot, tpm_infineon is also plugged in, but I can remove that
module and nothing seems to change (not sure what's plugging it in).
I can try using tpm_infineon, but I'm not sure how to disable tpm_tis
with it compiled in like this -- is that possible?
> Try the following before and after a suspend/resume:
>
> cd /sys
> find . | grep caps$ | xargs cat
>
> It should display manufacturer data.
>
There's only one "caps" file. Here's the before (after a fresh reboot):
# cat ./devices/pnp0/00:02/caps
Manufacturer: 0x49465800
TCG version: 1.2
Firmware version: 1.0
...after a successful suspend/resume cycle:
# cat ./devices/pnp0/00:02/caps
...it gives no output at all. Guess that lends some weight to the
theory of it not being reset properly on resume?
Thanks for the help so far...
--
Jeff Layton <jla...@poochiereds.net>
Jeff Layton
FWIW, I turned up dynamic debugging on the tpm files and got this in
the ring buffer when I tried to read from "caps":
[ 6880.495071] tpm_tis 00:02: A TPM error (38) occurred attempting to determine the manufacturer
I don't see any obvious places that return ENOSYS in the tpm code, so
I'm not clear on where that's coming from...
Sisir Koppaka
From drivers/char/tpm/tpm.c,
static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
int len, const char *desc)
{
int err;
len = tpm_transmit(chip,(u8 *) cmd, len);
if (len < 0)
return len;
if (len == TPM_ERROR_SIZE) {
err = be32_to_cpu(cmd->header.out.return_code);
dev_dbg(chip->dev, "A TPM error (%d) occurred %s\n", err, desc);
return err;
}
return 0;
}
Where, desc comes from rc = tpm_getcap(dev, TPM_CAP_PROP_MANUFACTURER,
&cap, "attempting to determine the manufacturer");
TPM_ERROR_SIZE is 10, looks like it satisfies that condition.
sk
Jeff Layton
Ahh yeah, I misread the code...
I guess then this error comes from the chip itself? Interesting that it
uses posix errors. Still though, it does seem like it's coming back
from resume in a bad state...
--
Jeff Layton <jla...@poochiereds.net>
Sisir Koppaka
Yup, it looks like the chip is at fault. The chip isn't supplying an
appropriate value for the capability TPM_CAP_PROP_MANUFACTURER (See
page 2 of [1], and compare with drivers/tpm/tpm.c). What is not clear
is whether the fault in the chip's response is due to the driver
code(maybe due to a firmware update etc.) or due to actual hardware
corruption.
sk
Stefan Berger
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. If that's verified we could
subsequently write a patch for the TPM driver to also send the
TPM_Startup(ST_STATE) to the TPM, which then in the case of most BIOSes
would be the 2nd time that the TPM receives such a command. I think TPMs
should be able to digest this 2nd TPM_Startup() well, but I'd have to
check -- but really we would ill-fix it just because of one (possibly)
buggy BIOS.
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.
Another possibility would be for you to check for BIOS updates from the
laptop manufacturer...
Stefan
Stefan Berger
#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <unistd.h>
int main(void) {
const uint8_t startup_st_state[] = {
0x00, 0xc1,
0x00, 0x00, 0x00, 0x0c,
0x00, 0x00, 0x00, 0x99,
0x00, 0x02
};
uint8_t buf[10];
int fd = open("/dev/tpm0", O_RDWR);
int len;
uint32_t err;
if (fd < 0) {
printf("Could not open /dev/tpm0\n");
return 1;
}
len = write(fd, startup_st_state, sizeof(startup_st_state));
if (len != sizeof(startup_st_state)) {
printf("Write failed.\n");
goto err_exit;
}
len = read(fd, buf, sizeof(buf));
if (len != sizeof(buf)) {
printf("Expected %d bytes bot got %d\n", (int)sizeof(buf), len);
goto err_exit;
}
if (buf[1] != 0xc4) {
printf("Response tag is bad.\n");
goto err_exit;
}
if (buf[5] != sizeof(buf)) {
printf("Response length is bad: %d\n", buf[5]);
goto err_exit;
}
err = buf[6] << 24 | buf[7] << 16 | buf[8] << 8 | buf[9];
if (err) {
printf("Got an error code in response: %u\n", err);
} else {
printf("Success!\n");
}
err_exit:
close(fd);
return 0;
}
gcc startup.c -o startup
Run it as 'root' after a resume and if that works do the 'cat ...' again.
Jeff Layton
Yep. That program fixed the problem. When I run it after a resume, I
can then cat the caps file and get output from it, and the machine will
successfully suspend again.
> Another possibility would be for you to check for BIOS updates from the
> laptop manufacturer...
>
This is actually a desktop machine and the BIOS for the motherboard is
at the latest version, though it is quite old -- 2007/09/01. For the
record this is a:
Foxconn 6150BK8MC
I'm actually not using the TPM in this thing at all. I'd be just as
happy if there were some way to disable it. Unfortunately, the option
in the BIOS to do this doesn't seem to actually work. When I set "TPM
Control" in the BIOS to "Disable" it always ends up reset back to "No
Change". I'd report both problems to the mfr, but this thing is long
out of warranty and I'm pretty sure they won't care.
Is there some way short of recompiling with CONFIG_TCG_* turned off
to disable the TPM driver at boot time?
--
Jeff Layton <jla...@poochiereds.net>
Stefan Berger
command to it and see whether it returns error code 38 and if so send
the TPM_Startup() from the driver -- as a work-around for your broken BIOS.
>> Another possibility would be for you to check for BIOS updates from the
>> laptop manufacturer...
>>
> This is actually a desktop machine and the BIOS for the motherboard is
> at the latest version, though it is quite old -- 2007/09/01. For the
> record this is a:
>
> Foxconn 6150BK8MC
>
> I'm actually not using the TPM in this thing at all. I'd be just as
> happy if there were some way to disable it. Unfortunately, the option
> in the BIOS to do this doesn't seem to actually work. When I set "TPM
> Control" in the BIOS to "Disable" it always ends up reset back to "No
> Change". I'd report both problems to the mfr, but this thing is long
> out of warranty and I'm pretty sure they won't care.
>
> Is there some way short of recompiling with CONFIG_TCG_* turned off
> to disable the TPM driver at boot time?
>
As far as I know, 'no'. I'd defer it to the maintainers as to how they
would want to solve your particular problem... either by using above
work-around, which would be more transparent, or actively having to turn
the driver off with a command line parameter.
Stefan
Jeff Layton
I'm fine with leaving it enabled as long as it doesn't get in the way
of suspend working. The scheme you mention above -- test the chip and
conditionally do a TPM_Startup() seems reasonable to me. Let me know if
you need me to test a patch...
Thanks,
--
Jeff Layton <jla...@poochiereds.net>
Rajiv Andrade
I'm handling a patch from Stefan that solves so, for now,
I'd recommend to use Stefan's tool.
Thanks,
Rajiv
Stefan Berger
> On 03/29/2011 09:25 AM, Stefan Berger wrote:
>> On 03/29/2011 08:08 AM, Jeff Layton wrote:
>>>>> Is there some way short of recompiling with CONFIG_TCG_* turned off
>>> to disable the TPM driver at boot time?
>>>
>> As far as I know, 'no'. I'd defer it to the maintainers as to how they would want to solve your particular problem... either by using above work-around, which would be more transparent, or actively having to turn the driver off with a command line parameter.
>>
>> Stefan
>>
> I'm handling a patch from Stefan that solves so, for now,
> I'd recommend to use Stefan's tool.
Well, at least none of the patches I submitted in the series solves this
particular problem.
I am not sure whether this problem should be fixed since it's hopefully
rare. If it was to be fixed, how it should be fixed. Here are a couple
of options:
- declare it a lost case due to broken out-of-spec BIOS -- don't fix it;
machine won't suspend a 2nd time
- send a command to the TPM upon resume and if TPM response returns
with error code 38 set a flag and don't send TPM_SaveState() upon the
next suspend; log this case; the TPM becomes unusable; machine will
suspend a 2nd time
- 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'
Options 2 and 3 would now also run for all the rest of the machines with
a good BIOS...
Stefan
Eric Paris
> - send a command to the TPM upon resume and if TPM response returns
> with error code 38 set a flag and don't send TPM_SaveState() upon the
> next suspend; log this case; the TPM becomes unusable; machine will
> suspend a 2nd time
I assume there is no reasonable way to detect this particular piece of
broken BIOS/hardware? If not I think this sounds like the best option
to me. If the TPM doesn't work after resume not much we can do other
than accept it doesn't work and move along.....
Jonathan Nieder
John Hughes wrote[1]:
> On a sony vaio tx3 when tpm_tis is loaded suspend only works once.
[...]
> dmesg shows
>
> [ 1859.244142] legacy_suspend(): pnp_bus_suspend+0x0/0x57 returns 38
> [ 1859.244150] PM: Device 00:07 failed to suspend: error 38
> [ 1859.456685] PM: Some devices failed to suspend
Stefan Berger wrote, in response to a similar report[2]:
> 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)
> 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. If that's
> verified we could subsequently write a patch for the TPM driver to
> also send the TPM_Startup(ST_STATE) to the TPM, which then in the
> case of most BIOSes would be the 2nd time that the TPM receives such
> a command. I think TPMs should be able to digest this 2nd
> TPM_Startup() well, but I'd have to check -- but really we would
> ill-fix it just because of one (possibly) buggy BIOS.
reliably on his machine.
[...]
> command to it and see whether it returns error code 38 and if so send
> the TPM_Startup() from the driver -- as a work-around for your broken BIOS.
- Debian 2.6.35~rc6-1~experimental.1 (close to v2.6.35-rc6)
- Debian 2.6.36-1~experimental.1 (close to v2.6.36)
- Debian 2.6.37~rc5-1~experimental.3 (close to v2.6.37-rc5)
- Debian 2.6.37-1 (close to v2.6.37)
- v3.2-rc2 + Vaio keyboard fixes
- Debian 3.2.1-1 (close to v3.2.1)
- v3.3-rc1 + Vaio keyboard fixes
Known problem? Any hints for getting this to work out of the box? (If
there's no generic fix, maybe it would be possible to use a quirks
table of some kind?)
Thanks,
Jonathan
[1] http://bugs.debian.org/591031
[2] http://thread.gmane.org/gmane.linux.kernel/1119143/focus=1119476
[3] http://thread.gmane.org/gmane.linux.kernel/1119143/focus=1119495
Stefan Berger
> Hi Stefan et al,
>
> John Hughes wrote[1]:
>
>> On a sony vaio tx3 when tpm_tis is loaded suspend only works once.
>
>> command to it and see whether it returns error code 38 and if so send
>> the TPM_Startup() from the driver -- as a work-around for your broken BIOS.
> Versions tested and found to exhibit the problem:
>
> - Debian 2.6.35~rc6-1~experimental.1 (close to v2.6.35-rc6)
> - Debian 2.6.36-1~experimental.1 (close to v2.6.36)
> - Debian 2.6.37~rc5-1~experimental.3 (close to v2.6.37-rc5)
> - Debian 2.6.37-1 (close to v2.6.37)
> - v3.2-rc2 + Vaio keyboard fixes
> - Debian 3.2.1-1 (close to v3.2.1)
> - v3.3-rc1 + Vaio keyboard fixes
>
> Known problem? Any hints for getting this to work out of the box? (If
> there's no generic fix, maybe it would be possible to use a quirks
> table of some kind?)
the kernel) and let me/us know what it reports in 'dmesg' upon a
'modprobe tpm_tis'? You can cut out serial numbers and UUIDs if you
want. I am also not sure whether it's a good idea to use DMI information
for quirks in general, but the idea would be to have a table of systems
with known problems, identify them using their SMBIOS information and
only apply the work-arounds to them. As stated previously what needs to
be sent upon resume is a TPM_Startup(ST_STATE). Even though it shouldn't
hurt to send this command two times to the TPM in general (from BIOS and
Linux) even on working machines I don't want to find out about side
effects ... for sure that would be much easier and much less code...
Stefan
---
drivers/char/tpm/tpm_tis.c | 5 +++++
1 file changed, 5 insertions(+)
Index: linux-2.6/drivers/char/tpm/tpm_tis.c
===================================================================
--- linux-2.6.orig/drivers/char/tpm/tpm_tis.c
+++ linux-2.6/drivers/char/tpm/tpm_tis.c
@@ -27,6 +27,7 @@
#include <linux/wait.h>
#include <linux/acpi.h>
#include <linux/freezer.h>
+#include <linux/dmi.h>
#include "tpm.h"
enum tis_access {
@@ -535,6 +536,10 @@ static int tpm_tis_init(struct device *d
vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
+ for (i = 0; i < DMI_STRING_MAX; i++)
+ dev_info(dev, "dmi: %d: %s\n",
+ i, dmi_get_system_info(i));
+
dev_info(dev,
"1.2 TPM (device-id 0x%X, rev-id %d)\n",
vendor >> 16, ioread8(chip->vendor.iobase + TPM_RID(0)));
John Hughes
>
> Can you apply the patch below to your tpm_tis.c (or somewhere else in
> the kernel) and let me/us know what it reports in 'dmesg' upon a
> 'modprobe tpm_tis'?
[ 48.826157] tpm_tis 00:07: dmi: 1: Phoenix Technologies LTD
[ 48.826161] tpm_tis 00:07: dmi: 2: R0021N3
[ 48.826165] tpm_tis 00:07: dmi: 3: 05/09/2006
[ 48.826169] tpm_tis 00:07: dmi: 4: Sony Corporation
[ 48.826173] tpm_tis 00:07: dmi: 5: VGN-TX3XP_B
[ 48.826177] tpm_tis 00:07: dmi: 6: J001QHZL
[ 48.826181] tpm_tis 00:07: dmi: 7: 28244651-5000176
[ 48.826186] tpm_tis 00:07: dmi: 8: DC744BA0-5B3C-11D9-8822-0013A93CCD4D
[ 48.826190] tpm_tis 00:07: dmi: 9: Sony Corporation
[ 48.826195] tpm_tis 00:07: dmi: 10: VAIO
[ 48.826199] tpm_tis 00:07: dmi: 11: N/A
[ 48.826204] tpm_tis 00:07: dmi: 12: N/A
[ 48.826208] tpm_tis 00:07: dmi: 13: N/A
[ 48.826213] tpm_tis 00:07: dmi: 14: Sony Corporation
[ 48.826217] tpm_tis 00:07: dmi: 15: 10
[ 48.826221] tpm_tis 00:07: dmi: 16: N/A
[ 48.826225] tpm_tis 00:07: dmi: 17: J001QHZL
[ 48.826229] tpm_tis 00:07: dmi: 18:
[ 48.826235] tpm_tis 00:07: 1.2 TPM (device-id 0xB, rev-id 16)
Stefan Berger
I am not sure whether this is the right way to go, though: Is it a
problem particular to this BIOS + Board or a general problem of this
BIOS? Is it specific to the TX3 or to all VAIOs?
Stefan
John Hughes
As to your questions about its applicability I'm afraid I can shed no
light. I can't even update the Bios to the latest version for the
moment as the bios updater needs windows. :-(
Jonathan Nieder
> On 29/01/12 19:22, Stefan Berger wrote:
>> Thanks. Please try the attached patch.
>>
>> I am not sure whether this is the right way to go, though: Is it a
>> problem particular to this BIOS + Board or a general problem of
>> this BIOS? Is it specific to the TX3 or to all VAIOs?
>
> I'll try the patch.
Curious,
Jonathan
John Hughes
> John Hughes wrote:
>> On 29/01/12 19:22, Stefan Berger wrote:
>>> Thanks. Please try the attached patch.
>>>
>>> I am not sure whether this is the right way to go, though: Is it a
>>> problem particular to this BIOS + Board or a general problem of
>>> this BIOS? Is it specific to the TX3 or to all VAIOs?
>> I'll try the patch.
> How did it go?
I didn't get to try the patch in the end - the disk in my Vaio died for
the second time and a replacement (1.8" disk with a funny connector) is
just too expensive to be worth it.
Thanks for your help anyway.