TPM chip prevents machine from suspending

TPM chip prevents machine from suspending

[Jeff Layton]

My wife's machine apparently has a TPM chip in it. Since I upgraded it
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.selhorst@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 <jlayton@poochiereds.net>

Re: TPM chip prevents machine from suspending

[Stefan Berger]

On 03/28/2011 10:08 AM, Jeff Layton wrote:
> My wife's machine apparently has a TPM chip in it. Since I upgraded it
> 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
Also the tpm_tis driver handles both of these. Can you confirm which 
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

Re: TPM chip prevents machine from suspending

[Jeff Layton]

On Mon, 28 Mar 2011 13:25:06 -0400
Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:

> On 03/28/2011 10:08 AM, Jeff Layton wrote:
> > My wife's machine apparently has a TPM chip in it. Since I upgraded it
> > 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
> Also the tpm_tis driver handles both of these. Can you confirm which 
> 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.
> 

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 <jlayton@poochiereds.net>

Re: TPM chip prevents machine from suspending

[Jeff Layton]

On Mon, 28 Mar 2011 14:12:41 -0400
Jeff Layton <jlayton@poochiereds.net> wrote:

> On Mon, 28 Mar 2011 13:25:06 -0400
> Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
> 
> > On 03/28/2011 10:08 AM, Jeff Layton wrote:
> > > My wife's machine apparently has a TPM chip in it. Since I upgraded it
> > > 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
> > Also the tpm_tis driver handles both of these. Can you confirm which 
> > 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.
> > 
> 
> 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...

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

-- 
Jeff Layton <jlayton@poochiereds.net>

Re: TPM chip prevents machine from suspending

[Sisir Koppaka]

On Tue, Mar 29, 2011 at 1:15 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
> On Mon, 28 Mar 2011 14:12:41 -0400
> Jeff Layton <jlayton@poochiereds.net> wrote:
>
>> On Mon, 28 Mar 2011 13:25:06 -0400
>> Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
>>
>> > On 03/28/2011 10:08 AM, Jeff Layton wrote:
>> > > My wife's machine apparently has a TPM chip in it. Since I upgraded it
>> > > 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
>> > Also the tpm_tis driver handles both of these. Can you confirm which
>> > 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.
>> >
>>
>> 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...
>
> 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...
>

>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

Re: TPM chip prevents machine from suspending

[Jeff Layton]

On Tue, 29 Mar 2011 01:27:05 +0530
Sisir Koppaka <sisir.koppaka@gmail.com> wrote:

> On Tue, Mar 29, 2011 at 1:15 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
> > On Mon, 28 Mar 2011 14:12:41 -0400
> > Jeff Layton <jlayton@poochiereds.net> wrote:
> >
> >> On Mon, 28 Mar 2011 13:25:06 -0400
> >> Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
> >>
> >> > On 03/28/2011 10:08 AM, Jeff Layton wrote:
> >> > > My wife's machine apparently has a TPM chip in it. Since I upgraded it
> >> > > 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
> >> > Also the tpm_tis driver handles both of these. Can you confirm which
> >> > 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.
> >> >
> >>
> >> 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...
> >
> > 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...
> >
> 
> 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.
> 

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 <jlayton@poochiereds.net>

Re: TPM chip prevents machine from suspending

[Sisir Koppaka]

On Tue, Mar 29, 2011 at 1:46 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
> On Tue, 29 Mar 2011 01:27:05 +0530
> Sisir Koppaka <sisir.koppaka@gmail.com> wrote:
>
>> On Tue, Mar 29, 2011 at 1:15 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
>> > On Mon, 28 Mar 2011 14:12:41 -0400
>> > Jeff Layton <jlayton@poochiereds.net> wrote:
>> >
>> >> On Mon, 28 Mar 2011 13:25:06 -0400
>> >> Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
>> >>
>> >> > On 03/28/2011 10:08 AM, Jeff Layton wrote:
>> >> > > My wife's machine apparently has a TPM chip in it. Since I upgraded it
>> >> > > 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
>> >> > Also the tpm_tis driver handles both of these. Can you confirm which
>> >> > 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.
>> >> >
>> >>
>> >> 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...
>> >
>> > 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...
>> >
>>
>> 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.
>>
>
> 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...
>

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.

http://www.trustedcomputinggroup.org/files/resource_files/137A54A3-1A4B-B294-D088F24684D141E1/Vendor%20ID%20Registry_0.1.pdf

                sk

Re: TPM chip prevents machine from suspending

[Stefan Berger]

On 03/28/2011 03:45 PM, Jeff Layton wrote:
> On Mon, 28 Mar 2011 14:12:41 -0400
> Jeff Layton<jlayton@poochiereds.net>  wrote:
>
>> On Mon, 28 Mar 2011 13:25:06 -0400
>> Stefan Berger<stefanb@linux.vnet.ibm.com>  wrote:
>>
>>> On 03/28/2011 10:08 AM, Jeff Layton wrote:
>>>> My wife's machine apparently has a TPM chip in it. Since I upgraded it
>>>> 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
>>> Also the tpm_tis driver handles both of these. Can you confirm which
>>> 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.
>>>
>> 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...
> 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...
>
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. 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

Re: TPM chip prevents machine from suspending

[Stefan Berger]

On 03/28/2011 07:10 PM, Stefan Berger wrote:
> On 03/28/2011 03:45 PM, Jeff Layton wrote:
>> On Mon, 28 Mar 2011 14:12:41 -0400
>> Jeff Layton<jlayton@poochiereds.net>  wrote:
>>
>>> On Mon, 28 Mar 2011 13:25:06 -0400
>>> Stefan Berger<stefanb@linux.vnet.ibm.com>  wrote:
>>>
>>>> On 03/28/2011 10:08 AM, Jeff Layton wrote:
>>>>> My wife's machine apparently has a TPM chip in it. Since I 
>>>>> upgraded it
>>>>> 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
>>>> Also the tpm_tis driver handles both of these. Can you confirm which
>>>> 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.
>>>>
>>> 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...
>> 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...
>>
> 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. 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...
>
So here is this tool:

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

    Stefan

Re: TPM chip prevents machine from suspending

[Jeff Layton]

On Mon, 28 Mar 2011 19:10:55 -0400
Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:

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

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 <jlayton@poochiereds.net>

Re: TPM chip prevents machine from suspending

[Stefan Berger]

On 03/29/2011 08:08 AM, Jeff Layton wrote:
> On Mon, 28 Mar 2011 19:10:55 -0400
> Stefan Berger<stefanb@linux.vnet.ibm.com>  wrote:
>
>> 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. 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.
>>
> 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.
Well, we now could (once) probe the TPM after the resume and send a test 
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

Re: TPM chip prevents machine from suspending

[Jeff Layton]

On Tue, 29 Mar 2011 08:25:01 -0400
Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:

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

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 <jlayton@poochiereds.net>

Re: TPM chip prevents machine from suspending

[Rajiv Andrade]

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.

Thanks,
Rajiv

Re: TPM chip prevents machine from suspending

[Stefan Berger]

On 03/29/2011 10:30 AM, Rajiv Andrade wrote:
> 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

Re: [tpmdd-devel] TPM chip prevents machine from suspending

[Eric Paris]

On Tue, 2011-03-29 at 11:03 -0400, Stefan Berger wrote:

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

[Sony Vaio TX3] TPM chip prevents machine from suspending a second time

[Jonathan Nieder]

Hi Stefan et al,

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)
[...]
>                                                        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 tool is at [3].  John verified that the tool gets suspend working
reliably on his machine.

[...]
> Well, we now could (once) probe the TPM after the resume and send a test 
> 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?)

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

Re: [Sony Vaio TX3] TPM chip prevents machine from suspending a second time

[Stefan Berger]

On 01/21/2012 12:01 PM, Jonathan Nieder wrote:
> Hi Stefan et al,
>
> John Hughes wrote[1]:
>
>> On a sony vaio tx3 when tpm_tis is loaded suspend only works once.
>
>> Well, we now could (once) probe the TPM after the resume and send a test
>> 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?)

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'? 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)));

Re: [Sony Vaio TX3] TPM chip prevents machine from suspending a second time

[John Hughes]

On 23/01/12 21:52, Stefan Berger wrote:
>
> 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.826151] tpm_tis 00:07: dmi: 0: (null)
[   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)

Re: [Sony Vaio TX3] TPM chip prevents machine from suspending a second time

[Stefan Berger]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On 01/29/2012 05:49 AM, John Hughes wrote:
> On 23/01/12 21:52, Stefan Berger wrote:
>>
>> 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.826151] tpm_tis 00:07: dmi: 0: (null)
> [   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)
>
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?

   Stefan




[-- Attachment #2: tpm_resume_quirks.diff --]
[-- Type: text/plain, Size: 5699 bytes --]

Add a TPM resume quirk for machines where the BIOS doesn't send the
TPM_Startup(ST_STATE) to the TPM and subsequent suspends fail due
to this. Identify machines by their SMBIOS data and only apply the quirk
on those known to need it.

Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>

---
 drivers/char/tpm/tpm.c |  153 +++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/char/tpm/tpm.h |    8 ++
 2 files changed, 161 insertions(+)

Index: linux-2.6/drivers/char/tpm/tpm.c
===================================================================
--- linux-2.6.orig/drivers/char/tpm/tpm.c
+++ linux-2.6/drivers/char/tpm/tpm.c
@@ -28,6 +28,7 @@
 #include <linux/mutex.h>
 #include <linux/spinlock.h>
 #include <linux/freezer.h>
+#include <linux/dmi.h>
 
 #include "tpm.h"
 
@@ -62,6 +63,131 @@ static LIST_HEAD(tpm_chip_list);
 static DEFINE_SPINLOCK(driver_lock);
 static DECLARE_BITMAP(dev_mask, TPM_NUM_DEVICES);
 
+/***** tpm quirks *****/
+
+#ifdef CONFIG_DMI
+
+struct tpm_dmi_entry {
+	enum dmi_field id;
+	const char **value;
+};
+
+struct tpm_resume_quirks {
+	const char *quirk_name;
+	const struct tpm_dmi_entry *dmi_entry;
+};
+
+#define TPM_DMI_ENTRY_LAST \
+	{ .id = DMI_NONE, .value = (const char*[]) { NULL }, }
+
+static const struct tpm_resume_quirks tpm_resume_quirks[] = {
+	{
+		.quirk_name = "Sony Vaio TX3",
+		.dmi_entry = (struct tpm_dmi_entry[]) {
+			{
+				.id = DMI_BIOS_VENDOR,
+				.value = (const char*[]) {
+					"Phoenix Technologies LTD",
+					NULL,
+				},
+			},
+			{
+				.id = DMI_SYS_VENDOR,
+				.value = (const char*[]) {
+					"Sony Corporation",
+					NULL,
+				},
+			},
+			{
+				.id = DMI_PRODUCT_NAME,
+				.value = (const char*[]) {
+					"VGN-TX3XP_B",
+					NULL,
+				},
+			},
+			{
+				.id = DMI_BOARD_NAME,
+				.value = (const char*[]) {
+					"VAIO",
+					NULL,
+				},
+			},
+			TPM_DMI_ENTRY_LAST
+		}
+	}
+};
+
+bool find_str_in_array(const char **array, const char *val)
+{
+	int i = 0;
+
+	while (array[i]) {
+		if (!strcmp(array[i++], val))
+			return true;
+	}
+
+	return false;
+}
+
+static bool tpm_resume_quirk_dmi(struct tpm_chip *chip)
+{
+	int i, j, rc;
+	bool found = false, handled = false;
+	const char *val;
+	const struct tpm_dmi_entry *dmi_entry;
+
+	for (i = 0; i < ARRAY_SIZE(tpm_resume_quirks) && !handled; i++) {
+		j = 0;
+		found = true;
+
+		while (true) {
+			dmi_entry = &tpm_resume_quirks[i].dmi_entry[j];
+
+			if (dmi_entry->id == DMI_NONE)
+				break;
+
+			val = dmi_get_system_info(dmi_entry->id);
+			if (!val) {
+				found = false;
+				break;
+			}
+
+			found = find_str_in_array(dmi_entry->value, val);
+			if (!found)
+				break;
+			j++;
+		}
+
+		if (found) {
+			dev_info(chip->dev,
+				 "Using tpm resume quirk '%s'.\n",
+				 tpm_resume_quirks[i].quirk_name);
+			rc = tpm_startup_ststate(chip);
+			if (rc < 0)
+				dev_err(chip->dev,
+					"quirk: TPM startup(ST_STATE) "
+					"failed.\n");
+			handled = true;
+			break;
+		}
+	}
+	return handled;
+}
+
+#else
+
+static bool tpm_resume_quirk_dmi(struct tpm_chip *tpm_chip)
+{
+	return false;
+}
+
+#endif
+
+static void tpm_resume_quirk(struct tpm_chip *tpm_chip)
+{
+	tpm_resume_quirk_dmi(tpm_chip);
+}
+
 /*
  * Array with one entry per ordinal defining the maximum amount
  * of time the chip could take to return the result.  The ordinal
@@ -864,6 +990,31 @@ int tpm_do_selftest(struct tpm_chip *chi
 }
 EXPORT_SYMBOL_GPL(tpm_do_selftest);
 
+/**
+ * tpm_startup_ststate - send a ststartup to the TPM
+ */
+#define TPM_ORD_STARTUP 153
+#define STARTUP_RESULT_SIZE 10
+
+static struct tpm_input_header startup_ststate_header = {
+	.tag = TPM_TAG_RQU_COMMAND,
+	.length = cpu_to_be32(10),
+	.ordinal = cpu_to_be32(TPM_ORD_STARTUP),
+};
+
+int tpm_startup_ststate(struct tpm_chip *chip)
+{
+	int rc;
+	struct tpm_cmd_t cmd;
+
+	cmd.header.in = startup_ststate_header;
+	cmd.params.startup_in.state = cpu_to_be16(TPM_ST_STATE);
+	rc = transmit_cmd(chip, &cmd, STARTUP_RESULT_SIZE,
+			  "startup(st_state)");
+	return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_startup_ststate);
+
 int tpm_send(u32 chip_num, void *cmd, size_t buflen)
 {
 	struct tpm_chip *chip;
@@ -1313,6 +1464,8 @@ int tpm_pm_resume(struct device *dev)
 	if (chip == NULL)
 		return -ENODEV;
 
+	tpm_resume_quirk(chip);
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(tpm_pm_resume);
Index: linux-2.6/drivers/char/tpm/tpm.h
===================================================================
--- linux-2.6.orig/drivers/char/tpm/tpm.h
+++ linux-2.6/drivers/char/tpm/tpm.h
@@ -42,6 +42,8 @@ enum tpm_addr {
 #define TPM_ERR_DEACTIVATED     0x6
 #define TPM_ERR_DISABLED        0x7
 
+#define TPM_ST_STATE            0x2
+
 #define TPM_HEADER_SIZE		10
 extern ssize_t tpm_show_pubek(struct device *, struct device_attribute *attr,
 				char *);
@@ -269,6 +271,10 @@ struct tpm_pcrextend_in {
 	u8	hash[TPM_DIGEST_SIZE];
 }__attribute__((packed));
 
+struct tpm_startup_in {
+	__be16 state;
+} __packed;
+
 typedef union {
 	struct	tpm_getcap_params_out getcap_out;
 	struct	tpm_readpubek_params_out readpubek_out;
@@ -277,6 +283,7 @@ typedef union {
 	struct	tpm_pcrread_in	pcrread_in;
 	struct	tpm_pcrread_out	pcrread_out;
 	struct	tpm_pcrextend_in pcrextend_in;
+	struct  tpm_startup_in startup_in;
 } tpm_cmd_params;
 
 struct tpm_cmd_t {
@@ -289,6 +296,7 @@ ssize_t	tpm_getcap(struct device *, __be
 extern int tpm_get_timeouts(struct tpm_chip *);
 extern void tpm_gen_interrupt(struct tpm_chip *);
 extern int tpm_do_selftest(struct tpm_chip *);
+extern int tpm_startup_ststate(struct tpm_chip *);
 extern unsigned long tpm_calc_ordinal_duration(struct tpm_chip *, u32);
 extern struct tpm_chip* tpm_register_hardware(struct device *,
 				 const struct tpm_vendor_specific *);

Re: [Sony Vaio TX3] TPM chip prevents machine from suspending a second time

[John Hughes]

On 29/01/12 19:22, Stefan Berger wrote:
> On 01/29/2012 05:49 AM, John Hughes 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.

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

Re: [Sony Vaio TX3] TPM chip prevents machine from suspending a second time

[Jonathan Nieder]

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?

Curious,
Jonathan

Re: [Sony Vaio TX3] TPM chip prevents machine from suspending a second time

[John Hughes]

On 26/02/12 16:44, Jonathan Nieder wrote:
> 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?

Sorry for the radio silence.

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.