Bug 644842 - tpm prevents suspend
tpm prevents suspend
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Regression
: 645155 645963 645991 (view as bug list)
Depends On:
Blocks: F14-accepted/F14FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2010-10-20 08:35 EDT by Amit Shah
Modified: 2011-04-19 20:18 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-25 11:24:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Amit Shah 2010-10-20 08:35:45 EDT
Description of problem:

I'm using 2.6.35.6-46.fc14.x86_64 on an F13 userspace on ThinkPad X200.  The F13 kernels suspend/resume fine.  The F14 kernel gives me:

[ 1142.403672] PM: Syncing filesystems ... done.
[ 1142.409830] PM: Preparing system for mem sleep
[ 1142.480292] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 1142.491155] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 1142.502051] PM: Entering mem sleep
[ 1142.502174] Suspending console(s) (use no_console_suspend to debug)
[ 1142.502697] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1142.660916] sd 0:0:0:0: [sda] Stopping disk
[ 1144.956125] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5
[ 1144.956141] legacy_suspend(): pnp_bus_suspend+0x0/0x85 returns -5
[ 1144.956145] PM: Device 00:0a failed to suspend: error -5
[ 1144.956147] PM: Some devices failed to suspend
Comment 1 Bryan O'Sullivan 2010-10-21 18:44:23 EDT
Seeing the same problem on the same Thinkpad model, also with kernel-2.6.35.6-46.fc14.x86_64
Comment 2 Bryan O'Sullivan 2010-10-21 18:47:02 EDT
This also seems to kill the ability to hibernate to disk :-(
Comment 3 Bryan O'Sullivan 2010-10-21 19:06:11 EDT
*** Bug 645155 has been marked as a duplicate of this bug. ***
Comment 4 Bryan O'Sullivan 2010-10-21 19:07:31 EDT
I'm now running kernel-2.6.35.4-28.fc14.x86_64 (the F14 beta kernel) which suspends happily, so this was introduced quite recently.
Comment 5 James M. Leddy 2010-10-22 09:44:42 EDT
(In reply to comment #4)
I got one better ;) 

Regression introduced somewhere between -39 and -46

$ rpm -q kernel
kernel-2.6.35.4-28.fc14.x86_64
kernel-2.6.35.6-39.fc14.x86_64
kernel-2.6.35.6-46.fc14.x86_64
james@xander xchatlogs$ uname -r
2.6.35.6-39.fc14.x86_64
Comment 6 Daniel Meyer 2010-10-23 05:06:49 EDT
Issue is also present on a Thinkpad X200t with kernel 2.6.35.6-45.fc14.x86_64
Comment 7 Daniel Meyer 2010-10-23 11:37:12 EDT
Since i couldn't find kernel-2.6.35.6-39.fc14.x86_64 or anything else between .39 and .45 I grabbed .28 from the beta-release. Suspend/Resume works like a charm.

If someone can point me to download locations for releases between .39 and .45 (both kernel and kernel-devel pleasem, preferebly also the srcrpm) I can check where the regression was introduced.
Comment 8 Evan McNabb 2010-10-25 10:30:06 EDT
Also hitting this on a Thinkpad W500 with 2.6.35.6-46.fc14.x86_64:

[ 4218.517390] PM: Syncing filesystems ... done.
[ 4219.151019] PM: Preparing system for mem sleep
[ 4219.195859] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 4219.207182] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 4219.218157] PM: Entering mem sleep
[ 4219.218282] Suspending console(s) (use no_console_suspend to debug)
[ 4219.390282] btusb_intr_complete: hci0 urb ffff8801346db240 failed to resubmit (1)
[ 4219.391284] btusb_bulk_complete: hci0 urb ffff880134d1f6c0 failed to resubmit (1)
[ 4219.392280] btusb_bulk_complete: hci0 urb ffff880133b6e000 failed to resubmit (1)
[ 4219.414190] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 4219.414492] sd 0:0:0:0: [sda] Stopping disk
[ 4220.474154] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5
[ 4220.474170] legacy_suspend(): pnp_bus_suspend+0x0/0x85 returns -5
[ 4220.474176] PM: Device 00:0a failed to suspend: error -5
[ 4220.474182] PM: Some devices failed to suspend
[ 4220.736106] sd 0:0:0:0: [sda] Starting disk
[ 4222.351866] PM: resume of devices complete after 1877.675 msecs
[ 4222.353167] PM: Finishing wakeup.
[ 4222.353172] Restarting tasks ... done.
[ 4222.371688] video LNXVIDEO:00: Restoring backlight state

Confirmed that 2.6.35.6-39.fc14.x86_64 works correctly.
Comment 9 Evan McNabb 2010-10-25 10:35:16 EDT
*** Bug 645963 has been marked as a duplicate of this bug. ***
Comment 10 Evan McNabb 2010-10-25 10:38:41 EDT
*** Bug 645991 has been marked as a duplicate of this bug. ***
Comment 11 James Laska 2010-10-25 10:59:15 EDT
Adding to nice-to-have list.  Per discussion with Evan, it appears he suspects a specific patch and also feels this might impact a large number of lenovo laptops.
Comment 12 Fabian A. Scherschel 2010-10-25 11:22:22 EDT
It looks like I have this on my X301 also. Excuse the dupe.
Comment 13 Evan McNabb 2010-10-25 11:24:57 EDT
Looks like this has been addressed:

$ rpm -q --changelog kernel-2.6.35.6-48.fc14.x86_64
...
* Fri Oct 22 2010 Kyle McMartin <kyle@redhat.com> 2.6.35.6-47
- tpm-autodetect-itpm-devices.patch: Auto-fix TPM issues on various
  laptops which prevented suspend/resume.
...

Testing on my W500 with -48 confirmed suspend/resume now works. I assume it
will for others too so closing now. Re-open if it doesn't. :-)
Comment 14 Fabian A. Scherschel 2010-10-25 11:26:47 EDT
Nice! Thanks! This was a deal-breaker....
Comment 15 James M. Leddy 2010-10-25 13:35:56 EDT
(In reply to comment #7)
> Since i couldn't find kernel-2.6.35.6-39.fc14.x86_64 or anything else between
> .39 and .45 I grabbed .28 from the beta-release. Suspend/Resume works like a
> charm.
> 
> If someone can point me to download locations for releases between .39 and .45
> (both kernel and kernel-devel pleasem, preferebly also the srcrpm) I can check
> where the regression was introduced.

I think I was subbed to the testing repo in yum, but in general you can find any pakage at http://koji.fedoraproject.org/koji/
Comment 16 Adam Williamson 2010-10-25 15:07:14 EDT
yeah. for the record, kernel team proposed respinning for the -48 kernel, but we rejected it, partly on the basis that suspend/resume isn't blocker functionality. at present it's likely that f14 will ship with kernel -45 so this will be broken ootb but will be fixed as soon as you update (assuming we get -48 into update repos before release). We can probably throw it in commonbugs.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Fabian A. Scherschel 2010-10-25 15:10:27 EDT
Wow.... Am I the only one who thinks breaking such an integral feature (most people run laptops these days which aren't mobile at all without this) should be a blocker? Oo
Comment 18 Bryan O'Sullivan 2010-10-25 15:26:21 EDT
(In reply to comment #17)

> Am I the only one who thinks breaking such an integral feature (most
> people run laptops these days which aren't mobile at all without this) should
> be a blocker?

I completely agree, but this late in the release process isn't the time to be making that policy change. It should definitely be the case for F-15, though.
Comment 19 James Laska 2010-10-25 15:46:55 EDT
(In reply to comment #18)
> (In reply to comment #17)
> 
> > Am I the only one who thinks breaking such an integral feature (most
> > people run laptops these days which aren't mobile at all without this) should
> > be a blocker?
> 
> I completely agree, but this late in the release process isn't the time to be
> making that policy change. It should definitely be the case for F-15, though.

Come take part in the discussion on test@lists.fedoraproject.org or record your ideas at https://fedoraproject.org/wiki/Fedora_14_QA_Retrospective.

We've historically had a hard time blocking a release for hardware specific, or local site configuration specific failures unless they did not have a reasonable workaround or carried certainty that the issue impacted a *large* number of users systems.  In this case, the issue alone doesn't warrant a slip in the release given that a fix will be available (along with several CVE's) in a day-0 kernel package update.
Comment 20 Adam Williamson 2010-10-25 16:36:30 EDT
fabian: in theory, we agree completely. the problem is that in practice, suspend/resume is such a thorny area that if we made it a blocker, we'd never get a release out (I would make a small bet that we've never made a release which didn't regress suspend/resume for *some* hardware somewhere). It's also something that can be fixed very cleanly by an official update, so the blocker rationale is less clear...what we really want to do is have the kernel team assign a high priority to suspend/resume regressions, and I'm trying to move away from using 'release blocker' as a proxy for 'high development priority' as they're not exactly the same thing (although the first should always imply the second, the second does not necessarily imply the first).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Fabian A. Scherschel 2010-10-25 16:59:47 EDT
Yeah, that sounds reasonable. If we can get the fix out fast, that's cool. Would be nice to get it on the CD but I understand we'd be hard pressed to change the kernel this late in the release/testing cycle. Thanks for explaining it so eloquently.
Comment 22 Daniel Meyer 2010-10-29 08:06:30 EDT
-48 works on both a X200t and a T400, thanks!
Comment 23 Fabian A. Scherschel 2010-10-29 08:21:33 EDT
I can also confirm a fix for the X301.
Comment 24 Adam Williamson 2010-11-01 20:44:39 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 25 Mike Snitzer 2010-11-03 16:44:06 EDT
I can't suspend with my Lenovo T500 using 2.6.35.6-48.fc14.x86_64.  Screen blanks and crescent moon icon just blinks when I attempt to suspend.

Don't have anything in /var/log/messages related to the failed suspend (no trace of suspend at all other than NetworkManager taking down the network interfaces).

I'm stopping short of reopening this BZ.  I'm hoping others have suggestions for how I could verify/capture _why_ the suspend is failing.  Is my only hope a usb-serial console?

I've reverted to the 2.6.34.7-61.fc13.x86_64 kernel for now.
Comment 26 Adam Williamson 2010-11-03 16:53:52 EDT
Given the amount of people who confirmed the fix for this bug in -48, I think what you have almost certainly has to be a different bug, so it'd be best to open a new report.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 27 Mike Snitzer 2010-11-04 10:48:00 EDT
(In reply to comment #25)
> I can't suspend with my Lenovo T500 using 2.6.35.6-48.fc14.x86_64.  Screen
> blanks and crescent moon icon just blinks when I attempt to suspend.

Quick update:
I updated to the latest T500 bios and tried suspending: suspend still failed but the crescent moon icon remained illuminated rather than blinking (forcing me to poweroff).  I then went into the bios setup and disabled the "security chip" and retried suspending and it worked (I've suspended and resumed a couple times now).
Comment 28 Vall 2011-04-19 20:18:37 EDT
I am not sure if this should be a new bug report, but here you go. 
I run F14, kernel-2.6.35.12-88.fc14.x86_64 on Sony Vaio SR49VN/H laptop. With the previous kernels, about 1 out 3 attempts to suspend resulted in a black screen and non-responding system.I had to do a cold shutdown. With the new kernel, the system tries to suspend, a black screen appears,  but after a second the system returns to the previous stars. Here is the relevant part from the dmesg:

[    1.019048] tpm_tis 00:09: Operation Timed out
........
[  716.397890] PM: Syncing filesystems ... done.
[  716.399713] PM: Preparing system for mem sleep
[  716.399722] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  716.411041] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[  716.422078] PM: Entering mem sleep
[  716.422091] Suspending console(s) (use no_console_suspend to debug)
[  716.424453] btusb_intr_complete: hci0 urb ffff88012518d3c0 failed to resubmit (1)
[  716.425450] btusb_bulk_complete: hci0 urb ffff88012518d780 failed to resubmit (1)
[  716.426459] btusb_bulk_complete: hci0 urb ffff88012518d300 failed to resubmit (1)
[  716.437118] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  716.558530] sd 0:0:0:0: [sda] Stopping disk
[  717.104888] ACPI handle has no context!
[  717.128065] tpm_tis 00:09: Operation Timed out
[  717.128072] legacy_suspend(): pnp_bus_suspend+0x0/0x85 returns -62
[  717.128074] PM: Device 00:09 failed to suspend: error -62
[  717.128076] PM: Some devices failed to suspend

in pm-suspend.log I find this:

Wed Apr 20 00:33:03 WEST 2011: performing suspend
/usr/lib64/pm-utils/pm-functions: line 295: echo: write error: Timer expired

and line 295 in /usr/lib64/pm-utils/pm-functions reads:

if [ -z "$SUSPEND_MODULE" ]; then
        if grep -q mem /sys/power/state; then
                SUSPEND_MODULE="kernel"
                do_suspend() { echo -n "mem" >/sys/power/state; }   <<<line 295
        elif [ -c /dev/pmu ] && pm-pmu --check; then
                SUSPEND_MODULE="kernel"
                do_suspend() { pm-pmu --suspend; }
        fi
fi

It seems to be a known problem with some claims it was fixed in some kernel versions. Other claim it is tpm_tis problem and suggested passing tpm_tis.itpm=1 and/or tpm_tis.interrupts=0 to the kernel, but none of them work for me.

Note You need to log in before you can comment on or make changes to this bug.