Bug 133671 - APM suspend works fine but resume refuses to actually resume
Summary: APM suspend works fine but resume refuses to actually resume
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-26 00:41 UTC by Jason 'vanRijn' Kasper
Modified: 2015-01-04 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-10 14:25:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jason 'vanRijn' Kasper 2004-09-26 00:41:20 UTC
Description of problem:
I have an IBM thinkpad A31 laptop.  `apm -s` works fine, as far as it
actually does seem to suspend the laptop and the little moon light
lights up.  But when I lift the lid, the laptop does not resume/power
back on.  I can't wake it up by pressing the power button either. 
It's hard-locked-up and can only be disturbed by holding down the
power button for ~ 10 seconds and powering the little guy off.

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

How reproducible:
every time.

Steps to Reproduce:
1. run 'apm -s'
2. watch laptop power down/suspend
3. lift lid, which normally wakes laptop out of suspend
4. observe laptop not waking up.  =:)
Actual results:
frozen laptop, have to hold power button down for 10 seconds to power
it off.

Expected results:
laptop should resume properly.

Additional info:

Comment 1 Bill Nottingham 2004-09-26 20:38:01 UTC
This is an interaction between the kernel and your BIOS.

Comment 2 cleith 2004-09-27 19:53:20 UTC
I have a T41 ThinkPad and have noticed the same symptoms with kernel
2.6.8-1.541 using APM. However, I do not believe the system locks when
it tries to resume, rather, I think there is no trigger to tell the
system to resume. That is, opening the lid, which used to be an event
that triggered the resume, no longer does so. Similarily, pressing and
holding the function key no longer initiates a resume (as it did
previously for me).

My belief is based on the fact that while I can suspend the machine by
issuing apm -s (as the above poster noted), things are "broken" well
before the suspend. In particular, my Fn key has no effect. For
example, Fn+F4 will not suspend my machine and Fn+F5 will not toggle
the Bluetooth radio. Also, closing the lid will not suspend the machine.

So I believe the machine is just happily suspended after apm -s, with
no way to wake it, not frozen or locked. Interestingly, my Fn key (and
combinations) do work with the same kernel using ACPI. But suspending
and resuming with ACPI is still a bit suspect so I would rather use
APM, which until now worked flawlessly.

-Chris Leith

Comment 3 cleith 2004-09-28 02:32:34 UTC
Just tested kernel 2.6.8-1.521. APM (acpi=off) works as I expect with
the Fn key and lid as triggers. Not sure if there are were other
kernels between 521 and 541 to check, but this seems to narrow the
time when the problem was introduced.

-Chris Leith

Comment 4 D. K. Smetters 2004-09-30 17:31:50 UTC
Actually, I see the same problem (correct suspend but hang on resume)
with 2.6.8-1.521 on a T30, though it does not appear to happen every
time. (I have a vague feeling that the likelihood of it happening is
correlated with how long the laptop is suspended, but I'm not sure
that's real.) I am not running the latest BIOS, but will try an
upgrade to see if it helps. ACPI suspend works correctly once, and
afterwards fails to turn off the screen. APM worked flawlessly on this
machine under a stock RH9 2.4.20 kernel.

--Diana Smetters

Comment 5 Jason 'vanRijn' Kasper 2004-10-01 21:09:12 UTC
I just updated to vmlinuz-2.6.8-1.590 and the same problem occurs with
this kernel--suspends fine, but when resume is attempted, the machine
hangs/locks with no resume.

Comment 6 Jason 'vanRijn' Kasper 2004-10-12 00:54:38 UTC
problem still happens with kernel-2.6.8-1.603.  Um.  Is this even being read by anyone?

Comment 7 Jason 'vanRijn' Kasper 2004-10-14 00:39:03 UTC
this looks to be fixed with kernel-2.6.8-1.610?!?  woot!  =:)

Comment 8 Jason 'vanRijn' Kasper 2005-02-10 14:25:51 UTC
this is fixed now.  marking as...  =:)

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