Seeing the same problem on the same Thinkpad model, also with kernel-2.6.35.6-46.fc14.x86_64

This also seems to kill the ability to hibernate to disk :-(

*** Bug 645155 has been marked as a duplicate of this bug. ***

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.

(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

Issue is also present on a Thinkpad X200t with kernel 2.6.35.6-45.fc14.x86_64

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.

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.

*** Bug 645963 has been marked as a duplicate of this bug. ***

*** Bug 645991 has been marked as a duplicate of this bug. ***

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.

It looks like I have this on my X301 also. Excuse the dupe.

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> 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. :-)

Nice! Thanks! This was a deal-breaker....

(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/

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

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

(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.

(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.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.

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

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.

-48 works on both a X200t and a T400, thanks!

I can also confirm a fix for the X301.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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.

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

(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).

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.