On Thu, Oct 21, 2010 at 05:42:40PM -0400, Matthew Garrett wrote:
> Some Lenovos have TPMs that require a quirk to function correctly. This can
> be autodetected by checking whether the device has a _HID of INTC0102. This
> is an invalid PNPid, and as such is discarded by the pnp layer - however
> it's still present in the ACPI code, so we can pull it out that way. This
> means that the quirk won't be automatically applied on non-ACPI systems,
> but without ACPI we don't have any way to identify the chip anyway so I
> don't think that's a great concern.
Matthew,
Thanks for coming up with a clean way to integrate this iTPM support!
Unfortunately, automagically loading tpm_tis results in a suspend
regression on my X200:
(hand-transcribed, sorry for any typos)
[ 16.759044] tpm_tis 00:0a: 1.2 TPM (device-id 0x1020, rev-id 6)
[ 7537.636134] PM: Entering mem sleep
[ 7537.636221] Suspending console(s) (use no_console_suspend to debug)
[ 7537.636668] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 7537.658111] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5
[ 7537.658119] legacy_suspend(): pnp_bus_suspend+0x0/0x6a returns -5
[ 7537.658122] PM: Device 00:0a failed to suspend: error -5
[ 7537.681940] sd 0:0:0:0: [sda] Stopping disk
[ 7538.564024] PM: Some devices failed to suspend
I suspect that it would have failed previously if I'd forced the module
to load, but since tpm_tis now loads automatically as of 2.6.37-rc1, I
have to "rmmod tpm_tis" for suspend to work.
-andy
On Mon, Nov 01, 2010 at 02:19:48PM -0700, Andy Isaacson wrote:
> I suspect that it would have failed previously if I'd forced the module
> to load, but since tpm_tis now loads automatically as of 2.6.37-rc1, I
> have to "rmmod tpm_tis" for suspend to work.
Hm. That's what this patch was intended to fix. Can you check that the
tree you're using has it merged? The autoloading comes from the fix to
the pnp code to use _CID even if _HID is malformed, so now we have a pnp
device when we previously didn't.
--
Matthew Garrett | [email protected]
On Mon, Nov 01, 2010 at 09:32:24PM +0000, Matthew Garrett wrote:
> On Mon, Nov 01, 2010 at 02:19:48PM -0700, Andy Isaacson wrote:
> > I suspect that it would have failed previously if I'd forced the module
> > to load, but since tpm_tis now loads automatically as of 2.6.37-rc1, I
> > have to "rmmod tpm_tis" for suspend to work.
>
> Hm. That's what this patch was intended to fix. Can you check that the
> tree you're using has it merged? The autoloading comes from the fix to
> the pnp code to use _CID even if _HID is malformed, so now we have a pnp
> device when we previously didn't.
Hmmm, I am testing with straight-up .37-rc1, c8ddb2713c62. It does not
include your patch.
This time around, still running -rc1, I ran pm-suspend and it suspended
+ resumed fine. The second time I ran pm-suspend, it switched to text
console and started flashing the moon LED, but hung there with the LCD
backlight still on and the LED moon flashing.
So, definitely something exciting going on... and not a simple
suspend regression, and definitely not caused by this patch, my
apologies. Subject line updated accordingly.
I'll try applying "Autodetect itpm devices" and report back.
-andy
On Mon, Nov 01, 2010 at 06:31:06PM -0700, Andy Isaacson wrote:
> On Mon, Nov 01, 2010 at 09:32:24PM +0000, Matthew Garrett wrote:
> > On Mon, Nov 01, 2010 at 02:19:48PM -0700, Andy Isaacson wrote:
> > > I suspect that it would have failed previously if I'd forced the module
> > > to load, but since tpm_tis now loads automatically as of 2.6.37-rc1, I
> > > have to "rmmod tpm_tis" for suspend to work.
> >
> > Hm. That's what this patch was intended to fix. Can you check that the
> > tree you're using has it merged? The autoloading comes from the fix to
> > the pnp code to use _CID even if _HID is malformed, so now we have a pnp
> > device when we previously didn't.
>
> Hmmm, I am testing with straight-up .37-rc1, c8ddb2713c62. It does not
> include your patch.
>
> This time around, still running -rc1, I ran pm-suspend and it suspended
> + resumed fine. The second time I ran pm-suspend, it switched to text
> console and started flashing the moon LED, but hung there with the LCD
> backlight still on and the LED moon flashing.
>
> So, definitely something exciting going on... and not a simple
> suspend regression, and definitely not caused by this patch, my
> apologies. Subject line updated accordingly.
>
> I'll try applying "Autodetect itpm devices" and report back.
With your patch applied on top of -rc1, suspend + resume seems to work
fine, and I don't have any error messages from tpm in dmesg.
Thanks, problem solved. (Still no idea what caused that one
hang-with-blinking-moon, but it doesn't appear to be connected.)
-andy
On Tuesday, November 02, 2010, Andy Isaacson wrote:
> On Mon, Nov 01, 2010 at 06:31:06PM -0700, Andy Isaacson wrote:
> > On Mon, Nov 01, 2010 at 09:32:24PM +0000, Matthew Garrett wrote:
> > > On Mon, Nov 01, 2010 at 02:19:48PM -0700, Andy Isaacson wrote:
> > > > I suspect that it would have failed previously if I'd forced the module
> > > > to load, but since tpm_tis now loads automatically as of 2.6.37-rc1, I
> > > > have to "rmmod tpm_tis" for suspend to work.
> > >
> > > Hm. That's what this patch was intended to fix. Can you check that the
> > > tree you're using has it merged? The autoloading comes from the fix to
> > > the pnp code to use _CID even if _HID is malformed, so now we have a pnp
> > > device when we previously didn't.
> >
> > Hmmm, I am testing with straight-up .37-rc1, c8ddb2713c62. It does not
> > include your patch.
> >
> > This time around, still running -rc1, I ran pm-suspend and it suspended
> > + resumed fine. The second time I ran pm-suspend, it switched to text
> > console and started flashing the moon LED, but hung there with the LCD
> > backlight still on and the LED moon flashing.
> >
> > So, definitely something exciting going on... and not a simple
> > suspend regression, and definitely not caused by this patch, my
> > apologies. Subject line updated accordingly.
> >
> > I'll try applying "Autodetect itpm devices" and report back.
>
> With your patch applied on top of -rc1, suspend + resume seems to work
> fine, and I don't have any error messages from tpm in dmesg.
>
> Thanks, problem solved. (Still no idea what caused that one
> hang-with-blinking-moon, but it doesn't appear to be connected.)
Please give us a pointer to the patch, there are other users experiencing this issue.
Thanks,
Rafael
On Tue, Nov 02, 2010 at 04:47:53AM +0100, Rafael J. Wysocki wrote:
> > > So, definitely something exciting going on... and not a simple
> > > suspend regression, and definitely not caused by this patch, my
> > > apologies. Subject line updated accordingly.
> > >
> > > I'll try applying "Autodetect itpm devices" and report back.
> >
> > With your patch applied on top of -rc1, suspend + resume seems to work
> > fine, and I don't have any error messages from tpm in dmesg.
> >
> > Thanks, problem solved. (Still no idea what caused that one
> > hang-with-blinking-moon, but it doesn't appear to be connected.)
>
> Please give us a pointer to the patch, there are other users
> experiencing this issue.
My iTPM-causes-suspend-to-fail is fixed by the head message in this
thread, <[email protected]>,
http://lkml.org/lkml/2010/10/21/456
-andy