After upgrading from 2.6.37 to 2.6.37.1 there is some problem with tpm_tis. During boot I get: Feb 19 19:22:42 lipp-nb kernel: [ 9.664344] tpm_tis 00:04: 1.2 TPM (device-id 0xB, rev-id 16) Feb 19 19:22:42 lipp-nb kernel: [ 10.000017] tpm_tis 00:04: Operation Timed out The real problem occurs when I later try to go to standby: Feb 19 13:00:25 lipp-nb kernel: [ 174.292169] tpm_tis 00:04: Operation Timed out Feb 19 13:00:25 lipp-nb kernel: [ 174.292177] legacy_suspend(): pnp_bus_suspend+0x0/0x70 returns -62 Feb 19 13:00:25 lipp-nb kernel: [ 174.292181] PM: Device 00:04 failed to suspend: error -62 I'm sorry, but that's all there is. The only additional information I have is that it is an infineon device (tpm_infineon gets loaded as well). After unloading all tpm* modules, stand by works again.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). 2.6.37->2.6.37.1 tpm_tis regression. Presumably also present in 2.6.38-rcX. Presumably caused by one of commit 44489516c52b3b76d9b2a0e670a26b6e64938ddf Author: Stefan Berger <stefanb@linux.vnet.ibm.com> Date: Tue Jan 11 14:37:29 2011 -0500 tpm_tis: Use timeouts returned from TPM commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. commit 926636ad472462044f06af264031f4a776504971 Author: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Date: Fri Nov 12 22:30:02 2010 +0100 TPM: Long default timeout fix commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. On Sat, 19 Feb 2011 18:58:06 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=29452 > > Summary: 2.6.37.1 breaks tpm_tis > Product: Drivers > Version: 2.5 > Kernel Version: 2.6.37.1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: drivers_other@kernel-bugs.osdl.org > ReportedBy: mnl@mnl.de > Regression: No > > > After upgrading from 2.6.37 to 2.6.37.1 there is some problem with tpm_tis. > During boot I get: > > Feb 19 19:22:42 lipp-nb kernel: [ 9.664344] tpm_tis 00:04: 1.2 TPM > (device-id 0xB, rev-id 16) > Feb 19 19:22:42 lipp-nb kernel: [ 10.000017] tpm_tis 00:04: Operation Timed > out > > The real problem occurs when I later try to go to standby: > > > Feb 19 13:00:25 lipp-nb kernel: [ 174.292169] tpm_tis 00:04: Operation Timed > out > Feb 19 13:00:25 lipp-nb kernel: [ 174.292177] legacy_suspend(): > pnp_bus_suspend+0x0/0x70 returns -62 > Feb 19 13:00:25 lipp-nb kernel: [ 174.292181] PM: Device 00:04 failed to > suspend: error -62 > > I'm sorry, but that's all there is. The only additional information I have is > that it is an infineon device (tpm_infineon gets loaded as well). After > unloading all tpm* modules, stand by works again. >
Please verify if reverting commit 44489516c52b3b76d9b2a0e670a26b6e64938ddf fixes the problem.
On Wed, Feb 23, 2011 at 02:40:30PM -0800, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > 2.6.37->2.6.37.1 tpm_tis regression. Presumably also present in > 2.6.38-rcX. Presumably caused by one of > > commit 44489516c52b3b76d9b2a0e670a26b6e64938ddf > Author: Stefan Berger <stefanb@linux.vnet.ibm.com> > Date: Tue Jan 11 14:37:29 2011 -0500 > > tpm_tis: Use timeouts returned from TPM > > commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. > > commit 926636ad472462044f06af264031f4a776504971 > Author: Rajiv Andrade <srajiv@linux.vnet.ibm.com> > Date: Fri Nov 12 22:30:02 2010 +0100 > > TPM: Long default timeout fix > > commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. Already known, and reverted in 2.6.37.2-rc1.
On Wednesday, February 23, 2011, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > 2.6.37->2.6.37.1 tpm_tis regression. Presumably also present in > 2.6.38-rcX. Presumably caused by one of > > commit 44489516c52b3b76d9b2a0e670a26b6e64938ddf > Author: Stefan Berger <stefanb@linux.vnet.ibm.com> > Date: Tue Jan 11 14:37:29 2011 -0500 > > tpm_tis: Use timeouts returned from TPM > > commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. This one has been reverted from .38-rc and will be reverted in .37.2. So, it would be good to verify if the issue is still present in Linus' current. > commit 926636ad472462044f06af264031f4a776504971 > Author: Rajiv Andrade <srajiv@linux.vnet.ibm.com> > Date: Fri Nov 12 22:30:02 2010 +0100 > > TPM: Long default timeout fix > > commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. > > > > On Sat, 19 Feb 2011 18:58:06 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=29452 > > > > Summary: 2.6.37.1 breaks tpm_tis > > Product: Drivers > > Version: 2.5 > > Kernel Version: 2.6.37.1 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: drivers_other@kernel-bugs.osdl.org > > ReportedBy: mnl@mnl.de > > Regression: No > > > > > > After upgrading from 2.6.37 to 2.6.37.1 there is some problem with tpm_tis. > > During boot I get: > > > > Feb 19 19:22:42 lipp-nb kernel: [ 9.664344] tpm_tis 00:04: 1.2 TPM > > (device-id 0xB, rev-id 16) > > Feb 19 19:22:42 lipp-nb kernel: [ 10.000017] tpm_tis 00:04: Operation > Timed > > out > > > > The real problem occurs when I later try to go to standby: > > > > > > Feb 19 13:00:25 lipp-nb kernel: [ 174.292169] tpm_tis 00:04: Operation > Timed > > out > > Feb 19 13:00:25 lipp-nb kernel: [ 174.292177] legacy_suspend(): > > pnp_bus_suspend+0x0/0x70 returns -62 > > Feb 19 13:00:25 lipp-nb kernel: [ 174.292181] PM: Device 00:04 failed to > > suspend: error -62 > > > > I'm sorry, but that's all there is. The only additional information I have > is > > that it is an infineon device (tpm_infineon gets loaded as well). After > > unloading all tpm* modules, stand by works again. > > > >
I'd like to take another attempt at having the patch applied - likely once the next window opens. The crux here is with non-compliant devices that return timeouts in milliseconds rather than microseconds, so timeouts are a factor of 1000 shorter than they are supposed to be. I didn't know that the Infineon TPM had the same problem. Would it be possible that you then show the output of the following sysfs entries cat /sys/devince/pnp0/00:06/pcrs cat /sys/devince/pnp0/00:06/caps to verify that the device works and cat /sys/devices/pnp0/00:06/timeouts to see what its timeouts are? That would be helpful. Thanks.
OK, I loaded the modules manually (I have them blacklisted currently). syslog says Feb 24 08:53:21 lipp-nb kernel: [69439.820201] tpm_inf_pnp 00:04: Found GTPM with ID IFX0102 Feb 24 08:53:21 lipp-nb kernel: [69439.820255] tpm_inf_pnp 00:04: TPM found: config base 0xfe00, data base 0xfe80, chip version 0x000b, vendor id 0x15d1 (Infineon), product id 0x000b (SLB 9635 TT 1.2) $ cat /sys/devices/pnp0/00:04/pcrs does not show anything $ cat /sys/devices/pnp0/00:04/caps Manufacturer: 0x49465800 TCG version: 1.1 Firmware version: 0.0
Fixed by: 8d1dc20 Revert "TPM: Long default timeout fix" e587137 Revert "tpm_tis: Use timeouts returned from TPM"