Bug 249966 - [PATCH] resume hangs X server
Summary: [PATCH] resume hangs X server
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: hal-info
Version: 9
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-28 17:44 UTC by Sjoerd Mullender
Modified: 2009-07-15 08:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-15 08:16:59 UTC


Attachments (Terms of Use)
dmesg output after resume with pm_trace enabled (33.13 KB, text/plain)
2007-09-21 16:50 UTC, Sjoerd Mullender
no flags Details
dmesg output after reboot with pm_trace enabled (20.62 KB, text/plain)
2007-09-21 16:50 UTC, Sjoerd Mullender
no flags Details
dmesg output after reboot after suspend from virtual console (33.13 KB, text/plain)
2007-09-21 16:51 UTC, Sjoerd Mullender
no flags Details
patch with quirk definition for Dell i8200 (636 bytes, patch)
2007-09-24 19:26 UTC, Sjoerd Mullender
no flags Details | Diff
Patch with quirk definition for Dell i8200 on Fedora 8 (689 bytes, patch)
2008-01-10 21:54 UTC, Sjoerd Mullender
no flags Details | Diff

Description Sjoerd Mullender 2007-07-28 17:44:23 UTC
Description of problem:
I am able to suspend-to-ram my system (Dell Inspiron 8200), but when I resume
the system, the screen does not turn back on and keyboard commands such as
Ctrl-Alt-Backspace do not work.

I'm not sure whether this is a kernel problem, one in the X server, or in the
driver.

I am (usually) able to login remotely on the system, so I was able to do more
investigation.

top shows the Xorg process takes 95 to 100 % of the CPU.  strace -p <Xorg-pid>
shows a rapidly scrolling list of just the two lines
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])

pstack show this:
# pstack 3804
#0  0x0022cb62 in NVSync () from /usr/lib/xorg/modules/drivers//nv_drv.so
#1  0x002c8392 in ?? () from /usr/lib/xorg/modules//libxaa.so
#2  0x002c9657 in XAACopyArea () from /usr/lib/xorg/modules//libxaa.so
#3  0x08178cea in ?? ()
#4  0x08174ce5 in ?? ()
#5  0x08087b8a in ProcCopyArea ()
#6  0x081523c1 in ?? ()
#7  0x080899fa in Dispatch ()
#8  0x08071735 in main ()

The hardware: Dell Inspiron 8200 laptop with nVidia GeForce4 440 Go video card,
using the nv driver (i.e. the OSS driver, not the proprietary driver, although
that gives the same problem with a slightly different stack trace).

Version-Release number of selected component (if applicable):
kernel-2.6.22.1-33.fc7.i686
xorg-x11-drv-nv-2.0.96-2.fc7.i386
xorg-x11-server-Xorg-1.3.0.0-9.fc7.i386

How reproducible:
Always, although sometimes I can't login remotely.

Steps to Reproduce:
1. run pm-suspend or click on suspend entry in Gnome panel
2. wait until system powers off
3. push power button
  
Actual results:
A quick flash, and then a completely black screen.


Expected results:
My session restored.

Additional info:

Comment 1 Sjoerd Mullender 2007-07-28 17:50:55 UTC
I forgot to add the smolt UUID: 4fb2471c-99b5-45aa-8c73-0336dd90e7f2

Comment 2 Christopher Brown 2007-09-21 12:31:26 UTC
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

Comment 3 Sjoerd Mullender 2007-09-21 16:50:04 UTC
Created attachment 202571 [details]
dmesg output after resume with pm_trace enabled

Comment 4 Sjoerd Mullender 2007-09-21 16:50:52 UTC
Created attachment 202581 [details]
dmesg output after reboot with pm_trace enabled

Comment 5 Sjoerd Mullender 2007-09-21 16:51:35 UTC
Created attachment 202591 [details]
dmesg output after reboot after suspend from virtual console

Comment 6 Sjoerd Mullender 2007-09-21 16:57:49 UTC
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.

Comment 7 Christopher Brown 2007-09-21 23:22:58 UTC
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

Comment 8 Sjoerd Mullender 2007-09-23 20:44:15 UTC
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.

Comment 9 Sjoerd Mullender 2007-09-24 19:16:40 UTC
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.

Comment 10 Sjoerd Mullender 2007-09-24 19:26:33 UTC
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.

Comment 11 Christopher Brown 2008-01-10 18:50:33 UTC
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

Comment 12 Sjoerd Mullender 2008-01-10 21:54:46 UTC
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).

Comment 13 Christopher Brown 2008-01-10 22:40:17 UTC
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

Comment 14 Bug Zapper 2008-05-14 13:43:25 UTC
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

Comment 15 Sjoerd Mullender 2008-06-16 20:52:31 UTC
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.

Comment 16 Bug Zapper 2009-06-09 22:43:47 UTC
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

Comment 17 Bug Zapper 2009-07-15 08:16:59 UTC
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.


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