Bug 243055 - System does not resume after apm -s on thinkpad X24
Summary: System does not resume after apm -s on thinkpad X24
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7
Hardware: i686 Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-07 03:36 UTC by Virgil King
Modified: 2008-02-21 19:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-16 02:01:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lsmod output (3.29 KB, text/plain)
2007-09-17 06:00 UTC, Virgil King
no flags Details
dmesg output (20.14 KB, text/plain)
2007-09-18 05:26 UTC, Virgil King
no flags Details

Description Virgil King 2007-06-07 03:36:27 UTC
Description of problem:

When trying to resume after suspend via 'apm -s', some activity occurs but
screen remains off and the system does not respond to input.

Version-Release number of selected component (if applicable):

F7 with all updates as of today

How reproducible: always

Steps to Reproduce:
1. Boot with apm=on acpi=off since acpi tends not to work on the system
(thinkpad X24)
2. apm -s
3. tap keys to resume
Actual results: system nonresponsive

Expected results: normal resumption

Additional info: smolt UUID is 96f45488-944e-485a-b127-f2103430cc59

Comment 1 Christopher Brown 2007-09-14 12:35:30 UTC
Hello Virgil,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.


I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel? If so, you might like to
try the following:

# Find out if the system is locked up completely by hitting the caps lock key.

    * If the capslock light doesn't toggle, the system is completely dead. Try
again, but this time before suspending, activate the pm_trace functionality with
echo 1 > /sys/power/pm_trace. This reprograms the real time clock to contain a
few bytes of information which we can use to diagnose which driver failed to
resume. After the hang, reboot, boot up again, and save the output of dmesg.

    * If the capslock light does toggle, then the system did come back up, and
it's possible that we just failed to reinitialise the video.
http://people.freedesktop.org/~hughsient/quirk may contain further useful
information to diagnose this problem. It may also be useful to initiate the
suspend from a tty (ctrl-alt-f1) and run pm-suspend ; dmesg > dmesg.out ; sync
by hand. Upon resuming you'll now have some more debug info to sift through.
Additionally, this way when it resumes, you already have a console logged in
from which you can type commands 'blind'. Trying vbetool post for example may
bring things back to life. 

# Try rmmod'ing various modules before doing the suspend. If this makes things
work again, retry with a smaller set of modules unloaded. Keep retrying until
you narrow down which module is to blame.

# Another trick that sometimes works to force video to come back up is to enable
the BIOS password. This makes the system resume in a VGA text mode that the
kernel recovers from a lot easier. Not a real solution, but it can help to
diagnose other problems.

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.


Comment 2 Virgil King 2007-09-15 07:45:16 UTC
Thanks Chris!

I did update to newer kernels a couple of times after filing this bug and
encountered the same behavior, but the machine is a little behind so I'm
updating it now and I'll let you know how that goes.

After reproducing the problem this evening the caps lock light did not respond.
I then tried suspending and resuming from a tty and the system resumed
successfully (good to know!). However, switching back to X at that point
resulted in what looked like the same hang (dead caps lock); so it looks like
the problem is a hard hang triggered by X activity?

I'll try more variations with the latest updates tomorrow. Would a dmesg
transcript still be helpful?

Comment 3 Virgil King 2007-09-15 19:50:37 UTC
Symptoms are identical using the latest kernel (

Previously I had been disabling ACPI in the boot args and using apm -s, which
worked better in older versions of Fedora, but I tried pm-suspend today and got
the same result.

quirk-checker.sh suggested '--quirk-s3-bios --quirk-s3-mode'. They didn't seem
to make a difference.

Comment 4 Christopher Brown 2007-09-16 19:33:49 UTC
(In reply to comment #2)

> I'll try more variations with the latest updates tomorrow. Would a dmesg
> transcript still be helpful?

Yes and if you can what would be really good is a dmesg output after the system
hangs by ssh'ing into the machine from another computer as this may be a

You might also want to try booting with the nolapic or nohz=off options.

Can you also attach an lsmod output.


Comment 5 Virgil King 2007-09-17 06:00:47 UTC
Created attachment 196981 [details]
lsmod output

Comment 6 Virgil King 2007-09-17 06:06:19 UTC
Thanks. I attached lsmod output.

nolapic and nohz=off did not make a difference.

While trying them I did notice that I can reproduce the problem without even
suspending, just by switching out to a virtual console and then back to X. So I
guess this is not a power management issue.

Comment 7 Christopher Brown 2007-09-17 10:14:48 UTC
If you rmmod your atheros driver as in:

# rmmod ath_pci ath_hal ath_rate_sample

and then try switching, do you still have the same issues?

Comment 8 Virgil King 2007-09-18 05:26:29 UTC
Created attachment 198071 [details]
dmesg output

Comment 9 Virgil King 2007-09-18 05:30:10 UTC
Unloading the atheros modules did not make a difference as far as I could tell.

Comment 10 Christopher Brown 2007-09-18 09:17:27 UTC
Thanks for all that. You might be interested in the following:


though clearly the X24 comes with a number of different wireless chips since it
was brought out and these are one of the usual suspects in suspend/resume
issues. If you could try the following as mentioned above it would be appreciated:

Initiate the suspend from a tty (ctrl-alt-f1) and run

pm-suspend ; dmesg > dmesg.out ; sync 

by hand. Upon resuming you'll now have some more debug info to sift through.
Additionally, this way when it resumes, you already have a console logged in
from which you can type commands 'blind'. Trying

vbetool post

for example may bring things back to life.


Comment 11 Virgil King 2007-09-19 01:17:09 UTC
I didn't attach the pm-suspend dmesg because as I mentioned above the problem
reproduces without suspending the machine at all, so I didn't think it would be
relevant. The problem occurs only when I switch to X so I doubt a blind console
will be available to me.

The system is using a PCMCIA wifi card. I'll see if the problem reproduces after
booting without the card inserted.

Comment 12 Virgil King 2007-09-22 19:44:55 UTC
I think I can isolate the problem to the 'radeon' xorg driver. After changing
the driver in xorg.conf to 'vesa', I can switch to virtual consoles and back
without hanging. pm-suspend and pm-hibernate still don't work (they just blank
the screen), but they don't result in a hang, and I suspect apm will work fully.

Comment 13 Virgil King 2007-09-22 20:43:12 UTC
The system does resume successfully after apm -s when not using the radeon driver.

Comment 14 Christopher Brown 2008-01-09 13:36:59 UTC
Hi Virgil,

No update on this for a few months - are you still having this issue with the
latest kernel? Good to hear you isolated the issue down to the graphics driver -
I'll keep this in mind for future sus/res reports I come across.


Comment 15 Christopher Brown 2008-02-16 02:01:29 UTC
Closing as per previous comment. Please re-open if this is still an issue for you.

Comment 16 Virgil King 2008-02-21 19:30:18 UTC
All updates as of a few days ago had not resolved the resume issue when using
the radeon driver. When using the vesa driver, resume worked, but the screen did
not turn off while suspended.

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