Bug 249966

I forgot to add the smolt UUID: 4fb2471c-99b5-45aa-8c73-0336dd90e7f2

Hello,

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 some of the following which will help us to resolve the issue:

# 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

Created attachment 202571 [details]
dmesg output after resume with pm_trace enabled

Created attachment 202581 [details]
dmesg output after reboot with pm_trace enabled

Created attachment 202591 [details]
dmesg output after reboot after suspend from virtual console

With an up-to-date system (I just did a yum update, kernel is 2.6.22.5-76.fc7,
xorg-x11-drv-nv is 2.0.96-2.fc7), I still have the same problem.

After resume, hitting the Caps Lock key does not result in the appropriate LED
to turn on/off (normally it does work).  I can, however, login remotely with
ssh, so the system does work somewhat.

I enabled the pm_trace functionality and suspended.  I attach two files with
dmesg output.  One (dmesg-after-resume) was obtained directly after the resume
by logging in remotely and saving the output of dmesg.  The other
(dmesg-after-reboot) was obtained after a reboot into run level 1 after this resume.

Doing the suspend from a virtual console (Ctrl-Alt-F1) doesn't change anything.
 Where can I find vbetool?  I have pm-utils installed, but I don't have vbetool.
The dmesg output is in dmesg-after-reboot-on-vc.

The other tests have to be done another time, since I am running out of time
now.  I can say that I had looked at the quirks page and also ran the script
that is provided to see if any quirks are needed.  It said everything was just
fine.  I also tried most (if not all) of the kernel command line options that
are suggested there, all to no avail.

Thanks for some awesome debugging there Sjoerd. This might be of some interest
to you:

https://www.redhat.com/archives/fedora-test-list/2007-September/msg00365.html

though its not really good news. I take it pm-hibernate works okay for you?

vbtool is indeed in pm-utils. You may need to run it as:

/usr/sbin/vbetool

I also wonder if running:

# rmmod orinoco_cs

prior to suspend would help. If you have any cardbus cards you could try
removing them as well.

Cheers
Chris

About vbetool: it is not on my system.  I have pm-utils-0.99.3-6.fc7 installed,
but looking at the pm-utils RPMs that come with Fedora 7, I notice something
very strange.  vbetool and radeontool are present in the i386 RPM, but they are
*not* present in any of the others (i486, i586, i686).  I have the i686 version
installed on my system.  I guess I have to install the i386 version.

I don't have time at the moment to do any experiments.

Now that I have installed the i386 version of pm-utils I can experiment with
vbetool.

When I run
pm-suspend; vbetool post
on a vritual console (Ctrl-Alt-F1), then the system suspends and comes back up
normally!  I tried this twice in quick succession, and both times the system
came up normally.

When I try this from a gnome-terminal in X, the old symptoms (98% CPU or Xorg,
black screen, unresponsive keyboard) return.

However, doing
pm-suspend --quirk-vbe-post
seems to work, both from the virtual console and in a gnome-terminal.

I think I tried this when I first opened this report, or else I tried adding
something to the fdi file as suggested by the quirk web page you quoted.

I'll try doing that again.  Perhaps it didn't work because I didn't have vbetool.

By the way, I BZ-ed the vbetool problem in 303831.

Created attachment 204451 [details]
patch with quirk definition for Dell i8200

The attached patch to
/usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-dell.fdi makes
my system suspend and resume properly.

The key is to make sure pm-utils for i386 (and not i686) is installed.

Sjoerd,

Has this patch been accepted upstream and are you still having the issue? If not
please let me know and I'll chase it up.

Cheers
Chris

Created attachment 291334 [details]
Patch with quirk definition for Dell i8200 on Fedora 8

I have no idea whether the patch has been accepted upstream.  I haven't seen it
in Fedora 8 yet.

I am currently running with this slightly different patch to
/usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-dell.fdi. 
Hibernate to disk and suspend to ram both work fine now (that is, if I use the
nv video driver--I have tried once with the nVidia driver but returning from
suspend caused the same sort of problem I had originally).

Thanks Sjoerd,

I'm changing component to hal-info which will notify the maintainer of the file
you're patching and hopefully get this included. I will stay CC'd to this bug.

Regards
Chris

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I changed the version to Fedora 9 since I still need to patch the
20-video-quirk-pm-dell.fdi file to add the Inspiron 8200 to it.
With the patch, the system suspends and resumes without problem.

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.