Bug 236783 - Suspend leaves laptop in unusable state
Summary: Suspend leaves laptop in unusable state
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: rawhide
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-17 17:04 UTC by Adam Huffman
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-13 23:06:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output (28.63 KB, text/plain)
2007-04-17 17:04 UTC, Adam Huffman
no flags Details
lspci output (2.14 KB, text/plain)
2007-04-17 17:05 UTC, Adam Huffman
no flags Details

Description Adam Huffman 2007-04-17 17:04:39 UTC
Description of problem:

Last night I installed rawhide on a Sony Vaio SZ3 which had been running FC6
previously.  Under FC6 I was able to suspend to RAM and resume quite happily. 
Occasionally I had to restart NetworkManager to reconnect to wireless networks,
but everything else seemed to work fine.

However, with the latest rawhide kernel it goes quite seriously wrong.  The
suspend phase seems to work and the power LED flashes amber indicating this. 
However, when I switch it back on, the NumLock and CapsLock LEDs start flashing
and it fails to respond to any commands, even the power switch.  The only way to
get it out of this state is to remove the battery.

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

How reproducible:
Every time

Steps to Reproduce:
1. Suspend to RAM, using menu item
2. Attempt to resume
3.
  
Actual results:

Laptop is left in unusable state

Expected results:

Laptop resumes normally

Additional info:

Comment 1 Adam Huffman 2007-04-17 17:04:39 UTC
Created attachment 152836 [details]
dmesg output

Comment 2 Adam Huffman 2007-04-17 17:05:30 UTC
Created attachment 152837 [details]
lspci output

Comment 3 Adam Huffman 2007-04-18 07:11:55 UTC
I haven't had the chance to test this yet, but could the problem be related to
what's described in http://lkml.org/lkml/2007/4/17/41?

Comment 4 Dave Jones 2007-04-23 15:57:17 UTC
the cpuidle code referenced there is only in -mm right now, so no, that's unrelated.

The flashing keyboard LEDs that you see are an indication that the kernel
'oopsed'.  Unfortunatly, getting debug info out of the kernel when it does this
is extremely difficult, as not much of the system is 'up' at that stage, so
networking, console etc aren't back.

I'm debugging a number of other suspend related issues at the moment, so it's
possible that at some stage this will get fixed as fallout from that, but
without a serial console or similar, there's not much to go on from this bug.

Comment 5 cje 2007-05-23 12:51:51 UTC
have a look at this: http://people.freedesktop.org/~hughsient/quirk/

Comment 6 Adam Huffman 2007-05-28 23:04:45 UTC
I have looked at that link.  The easy fixes don't seem to help much, so I tried
using 'pm_trace' with a patched 2.6.22-rc3 kernel.  I had already put iwl3945 into 
/etc/pm/config.d/unload_modules.  Here's the output I got:

hash matches drivers/base/power/resume.c:57

Comment 7 Adam Huffman 2007-07-16 22:39:21 UTC
This particular problem seems to have been solved.  With kernel 2.6.22-8.fc7 the
laptop suspends and resumes, though the backlight level is far too dim.

Comment 8 Adam Huffman 2007-08-13 23:06:12 UTC
The laptop is now running rawhide and the on-resume oops hasn't re-appeared.


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