This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 257801

Summary: vaio-vgn-n250e pm-suspend broken on 2.6.22.4-65.fc7 vs 2.6.22.1-41.fc7
Product: [Fedora] Fedora Reporter: Jane Dogalt <jdogalt>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: 7CC: snecklifter
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-14 17:35:24 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Jane Dogalt 2007-08-27 15:40:35 EDT
Description of problem:

on a sony vaio vgn-n250e pm-suspend stopped working on 2.6.22.4-65.fc7.  It had
been working on 2.6.22.1-41.fc7, though that was the first kernel I had seen it
working on.  It seemed to go back to the same failure mode, i.e. leaving a
couple lines of text at the top of the screen saying 'stopping console' or
something (I can post a pic if need be).  And then not powering down the screen
or the system.

Of course, since 2.6.22.4-65 is the first kernel on which pm-hibernate actually
works on this laptop, I can't say I'm all that unhappy.  Still, maybe one of
these days I'll get both :)


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Christopher Brown 2007-09-30 09:10:19 EDT
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 you are, you might like
to try some of the following which may resolve the issue for you:

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

# Proprietary 3d graphics driver users should test with respective open source
drivers.

# Laptops using the nv driver should be considered hibernate-only capable as per
https://www.redhat.com/archives/fedora-test-list/2007-September/msg00365.html

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 Jane Dogalt 2007-10-02 01:48:31 EDT
I haven't tried the various tricks you mentioned, but...

2.6.22.5 seemed to actually work with both pm-suspend and pm-hibernate.

Unfortunately, I just updated to 2.6.22.9 and now pm-hibernate is broken again
(doesn't save out to disk, hangs with 4 lines of text at top of screen just
before it should start saving to disk).

Also, there is a known bug that pm-suspend jacks the screen brightness to max on
resume, though the current workaround of switching to a vt and then back to the
X vt, is easy enough for the timebeing.
Comment 3 Jane Dogalt 2007-10-03 02:48:43 EDT
further info-

I just got 2.6.22.9 to work with pm-hibernate.

I think that all along there may have just been something strange about the very
first time I try pm-hibernate on a new kernel, i.e. it hangs on the stopping
consoles text.

I'll post more success/failure info as it happens until I can figure out a clear
pattern...
Comment 4 Christopher Brown 2007-10-03 07:03:05 EDT
Okay, thanks for the update. There is a whole bunch of suspend/resume fixes
coming with 2.6.23 as well so this might stamp on the issues once and for all.
If you can post (as text/plain attachments) any debugging output such as dmesg
after sus/resume that would be good. An lsmod output would be interesting as well.
Comment 5 Christopher Brown 2008-01-13 13:37:37 EST
Hi there,

Any update on this?
Comment 6 Jane Dogalt 2008-01-14 17:35:24 EST
call it fixed.

I still have issues with the backlight brightness getting reset during sleep,
suspend, qemu, and mplayer, but thats a different thing.