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.
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.
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 | [email protected]
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
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.
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 | [email protected]
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
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
> 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
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.