[REGRESSION] Suspend fails because of TPM modules

[REGRESSION] Suspend fails because of TPM modules

[Jiri Kosina]

Hi,

on my thinkpad x200s (and I have seen reports on different HW as well), 
suspend fails when TPM modules are loaded.

	tpm_tis 00:0a: tpm_transmit: tpm_send: error -5
	legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5
	PM: Device 00:0a failed to suspend: error -5
	PM: Some devices failed to suspend

Once tpm, tpm_bios, tpm_tis and tpm modules are unloaded, suspend/resume 
works.

This is a regression. It definitely worked on this very same hardware on 
2.6.34. Any kernel between .34 and .37 wasn't booted there, so I don't 
have any data of that kind.

I can try bisecting it, but if anyone sees immediately what the culprit 
might be, that'd be helpful.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [REGRESSION] Suspend fails because of TPM modules

[Jiri Kosina]

On Mon, 29 Nov 2010, Jiri Kosina wrote:

> Hi,
> 
> on my thinkpad x200s (and I have seen reports on different HW as well), 
> suspend fails when TPM modules are loaded.
> 
> 	tpm_tis 00:0a: tpm_transmit: tpm_send: error -5
> 	legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5
> 	PM: Device 00:0a failed to suspend: error -5
> 	PM: Some devices failed to suspend
> 
> Once tpm, tpm_bios, tpm_tis and tpm modules are unloaded, suspend/resume 
> works.
> 
> This is a regression. It definitely worked on this very same hardware on 
> 2.6.34. Any kernel between .34 and .37 wasn't booted there, so I don't 
> have any data of that kind.
> 
> I can try bisecting it, but if anyone sees immediately what the culprit 
> might be, that'd be helpful.

I just found out, that if I modprobe tpm_tis module with

	itpm=1

parameter, the problem doesn't happen any more and suspend works fine.

This definitely wasn't needed on older kernels though, so I'd consider 
that still a regression.

Also, can't we make the module automatically detect the machines on which 
to apply the workaround? Let's say, based on DMI?

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [REGRESSION] Suspend fails because of TPM modules

[Matthew Garrett]

On Mon, Nov 29, 2010 at 04:15:21PM +0100, Jiri Kosina wrote:

> I just found out, that if I modprobe tpm_tis module with
> 
> 	itpm=1
> 
> parameter, the problem doesn't happen any more and suspend works fine.
> 
> This definitely wasn't needed on older kernels though, so I'd consider 
> that still a regression.
> 
> Also, can't we make the module automatically detect the machines on which 
> to apply the workaround? Let's say, based on DMI?

http://lkml.org/lkml/2010/10/21/456

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [REGRESSION] Suspend fails because of TPM modules

[Rajiv Andrade]

On 11/29/2010 01:15 PM, Jiri Kosina wrote:
> On Mon, 29 Nov 2010, Jiri Kosina wrote:
>
>> Hi,
>>
>> on my thinkpad x200s (and I have seen reports on different HW as well),
>> suspend fails when TPM modules are loaded.
>>
>> 	tpm_tis 00:0a: tpm_transmit: tpm_send: error -5
>> 	legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5
>> 	PM: Device 00:0a failed to suspend: error -5
>> 	PM: Some devices failed to suspend
>>
>> Once tpm, tpm_bios, tpm_tis and tpm modules are unloaded, suspend/resume
>> works.
>>
>> This is a regression. It definitely worked on this very same hardware on
>> 2.6.34. Any kernel between .34 and .37 wasn't booted there, so I don't
>> have any data of that kind.
>>
>> I can try bisecting it, but if anyone sees immediately what the culprit
>> might be, that'd be helpful.
> I just found out, that if I modprobe tpm_tis module with
>
> 	itpm=1
>
> parameter, the problem doesn't happen any more and suspend works fine.
>
> This definitely wasn't needed on older kernels though, so I'd consider
> that still a regression.
>
> Also, can't we make the module automatically detect the machines on which
> to apply the workaround? Let's say, based on DMI?
>
There's a patch already submitted that solves this:
http://marc.info/?l=linux-kernel&m=128769741101534&w=2 
<http://marc.info/?l=linux-kernel&m=128769741101534&w=2>

This side effect (to solve the suspend issue) should increase its 
urgency I think.
James, any thoughts?

Rajiv

Re: [REGRESSION] Suspend fails because of TPM modules

[Jiri Kosina]

On Mon, 29 Nov 2010, Rajiv Andrade wrote:

> > > on my thinkpad x200s (and I have seen reports on different HW as well),
> > > suspend fails when TPM modules are loaded.
> > > 
> > > 	tpm_tis 00:0a: tpm_transmit: tpm_send: error -5
> > > 	legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5
> > > 	PM: Device 00:0a failed to suspend: error -5
> > > 	PM: Some devices failed to suspend
> > > 
> > > Once tpm, tpm_bios, tpm_tis and tpm modules are unloaded, suspend/resume
> > > works.
> > > 
> > > This is a regression. It definitely worked on this very same hardware on
> > > 2.6.34. Any kernel between .34 and .37 wasn't booted there, so I don't
> > > have any data of that kind.
> > > 
> > > I can try bisecting it, but if anyone sees immediately what the culprit
> > > might be, that'd be helpful.
> > I just found out, that if I modprobe tpm_tis module with
> > 
> > 	itpm=1
> > 
> > parameter, the problem doesn't happen any more and suspend works fine.
> > 
> > This definitely wasn't needed on older kernels though, so I'd consider
> > that still a regression.
> > 
> > Also, can't we make the module automatically detect the machines on which
> > to apply the workaround? Let's say, based on DMI?
> > 
> There's a patch already submitted that solves this:
> http://marc.info/?l=linux-kernel&m=128769741101534&w=2
> <http://marc.info/?l=linux-kernel&m=128769741101534&w=2>
> 
> This side effect (to solve the suspend issue) should increase its urgency I
> think.
> James, any thoughts?

Yeah, Matthew has already pointed me to that patch, thanks. I will be 
testing it shortly and providing my Tested-by: eventually.

Any ideas why other kernels were OK (.34) and didn't require this quirk on 
my machine at all?

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [REGRESSION] Suspend fails because of TPM modules

[Matthew Garrett]

On Mon, Nov 29, 2010 at 04:26:19PM +0100, Jiri Kosina wrote:

> Any ideas why other kernels were OK (.34) and didn't require this quirk on 
> my machine at all?

We previously ignored devices that had an invalid PNP ID in _HID, 
whereas now we still pay attention to them if they have a valid ID in 
_CID.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [REGRESSION] Suspend fails because of TPM modules

[Rajiv Andrade]

On 11/29/2010 01:32 PM, Matthew Garrett wrote:
> On Mon, Nov 29, 2010 at 04:26:19PM +0100, Jiri Kosina wrote:
>
>> Any ideas why other kernels were OK (.34) and didn't require this quirk on
>> my machine at all?
> We previously ignored devices that had an invalid PNP ID in _HID,
> whereas now we still pay attention to them if they have a valid ID in
> _CID.
>
Yeah, and to make sense with my previous post, the workaround I 
mentioned depended on a module option given that the device couldn't be 
detected without having to send it commands.

Rajiv

Re: [REGRESSION] Suspend fails because of TPM modules

[Rajiv Andrade]

On 11/29/2010 01:26 PM, Jiri Kosina wrote:
> On Mon, 29 Nov 2010, Rajiv Andrade wrote:
>
>>>> on my thinkpad x200s (and I have seen reports on different HW as well),
>>>> suspend fails when TPM modules are loaded.
>>>>
>>>> 	tpm_tis 00:0a: tpm_transmit: tpm_send: error -5
>>>> 	legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5
>>>> 	PM: Device 00:0a failed to suspend: error -5
>>>> 	PM: Some devices failed to suspend
>>>>
>>>> Once tpm, tpm_bios, tpm_tis and tpm modules are unloaded, suspend/resume
>>>> works.
>>>>
>>>> This is a regression. It definitely worked on this very same hardware on
>>>> 2.6.34. Any kernel between .34 and .37 wasn't booted there, so I don't
>>>> have any data of that kind.
>>>>
>>>> I can try bisecting it, but if anyone sees immediately what the culprit
>>>> might be, that'd be helpful.
>>> I just found out, that if I modprobe tpm_tis module with
>>>
>>> 	itpm=1
>>>
>>> parameter, the problem doesn't happen any more and suspend works fine.
>>>
>>> This definitely wasn't needed on older kernels though, so I'd consider
>>> that still a regression.
>>>
>>> Also, can't we make the module automatically detect the machines on which
>>> to apply the workaround? Let's say, based on DMI?
>>>
>> There's a patch already submitted that solves this:
>> http://marc.info/?l=linux-kernel&m=128769741101534&w=2
>> <http://marc.info/?l=linux-kernel&m=128769741101534&w=2>
>>
>> This side effect (to solve the suspend issue) should increase its urgency I
>> think.
>> James, any thoughts?
> Yeah, Matthew has already pointed me to that patch, thanks. I will be
> testing it shortly and providing my Tested-by: eventually.
>
> Any ideas why other kernels were OK (.34) and didn't require this quirk on
> my machine at all?
>
The TPM device driver wasn't probably being built/loaded, can you check 
that?
The device driver must send the TPM a command prior to suspend to save 
its state, what's happening here is that this particular model, iTPM, 
doesn't change the status register as expected to acknowledge the code 
that a send command operation finished successfully, the driver then 
returns -EIO. The same obviously happens during suspend, returning 
failure to save its state, since the command the driver sent to do so 
failed, halting the suspend operation.

Matthew's patch implements automatic detection of such TPMs so that a 
workaround implemented in a previous commit can be activated to bypass 
that status register check, making the device usable and therefore able 
to save its state when asked to by the device driver during suspend.

Rajiv

Re: [tpmdd-devel] [REGRESSION] Suspend fails because of TPM modules

[Michael Doube]

> I just found out, that if I modprobe tpm_tis module with
> 
> 	itpm=1
> 
> parameter, the problem doesn't happen any more and suspend works fine.

Not here unfortunately. Suspend still fails with itpm=1, and I get this
in my logs

Nov 29 15:52:32 doris kernel: [  649.110527] resource map sanity check
conflict: 0xfed40000 0xfed44fff 0xfed43000 0xfed43fff Intel Flush Page
Nov 29 15:52:32 doris kernel: [  649.110923] tpm_tis 00:09: 1.2 TPM
(device-id 0xB, rev-id 16)
Nov 29 15:52:32 doris kernel: [  649.110929] tpm_tis 00:09: Intel iTPM
workaround enabled
Nov 29 15:54:34 doris kernel: [  771.360067] tpm_tis 00:09:
tpm_transmit: tpm_send: error -62

Also, this patch:
http://marc.info/?l=linux-kernel&m=128769741101534&w=2

Looks for a string that is absent from my Vaio SZ650, so the workaround
is not applied (and if it was, it probably wouldn't work, right?).

I posted my DSDT to bugzilla:
https://bugzilla.kernel.org/attachment.cgi?id=38072

Michael

Re: [tpmdd-devel] [REGRESSION] Suspend fails because of TPM modules

[Jiri Kosina]

On Mon, 29 Nov 2010, Michael Doube wrote:

> > I just found out, that if I modprobe tpm_tis module with
> > 
> > 	itpm=1
> > 
> > parameter, the problem doesn't happen any more and suspend works fine.
> 
> Not here unfortunately. Suspend still fails with itpm=1, and I get this
> in my logs
> 
> Nov 29 15:52:32 doris kernel: [  649.110923] tpm_tis 00:09: 1.2 TPM (device-id 0xB, rev-id 16)
> Nov 29 15:52:32 doris kernel: [  649.110929] tpm_tis 00:09: Intel iTPM workaround enabled
> Nov 29 15:54:34 doris kernel: [  771.360067] tpm_tis 00:09: tpm_transmit: tpm_send: error -62

That looks like a completely separate issue -- in your case, 
wait_for_stat() times out while waiting for _READY.

Is this regressions from older kernels as well?

> Looks for a string that is absent from my Vaio SZ650, so the workaround
> is not applied (and if it was, it probably wouldn't work, right?).

Yeah, it's workaround for symptoms different from than what you are 
seeing.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.