Bug 243055

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.

http://fedoraproject.org/wiki/KernelBugTriage

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.

Cheers
Chris

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?

Symptoms are identical using the latest kernel (2.6.22.5-76.fc7).

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.

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

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

Can you also attach an lsmod output.

Cheers
Chris

Created attachment 196981 [details]
lsmod output

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.

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?

Created attachment 198071 [details]
dmesg output

Unloading the atheros modules did not make a difference as far as I could tell.

Thanks for all that. You might be interested in the following:

http://www.thinkwiki.org/wiki/Installation_instructions_for_the_ThinkPad_X24

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.

Cheers
Chris

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.

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.

The system does resume successfully after apm -s when not using the radeon driver.

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.

Cheers
Chris

Closing as per previous comment. Please re-open if this is still an issue for you.

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.