Bug 70154 - suspend/resume hangs on dell latitude c800
Summary: suspend/resume hangs on dell latitude c800
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-07-30 20:06 UTC by Need Real Name
Modified: 2008-08-01 16:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:39:47 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 Need Real Name 2002-07-30 20:06:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i586; U;) Gecko/0

Description of problem:
System is a dell latitude c800 laptop.  Doing a suspend to ram and then a resume
causes the system to hang:  doesn't respond to keyboard or mouse input.  

If I do a suspend while in X the screen is either frozen or blank when I resume.  

If I do a suspend from the console (X not running) when I resume the message:

'resume warning: bios doesn't restore PCI state properly
resume warning:  if resume failed try booting with resume=force'

is on the console and the system is still hung (won't respond to keyboard/mouse
input).  I tried booting with the 'resume=force' option, but that doesn't help
at all.

Suspend/resume on this machine worked flawlessly under RH7.2 and continues to
work flawlessly under RH7.3 (I dual boot between RH7.3 and the limbo beta),
running all of the stock and updated kernels from 7.2 and 7.3, and also running
kernels I complied from 2.4.16-2.4.18 sources from kernel.org.  

Workaround:  I recompiled the 2.4.18-5 kernel from RH7.3 under limbo, and
suspend/resume works correctly.  So the problem seems to lie in the kernels
shipped with the limbo betas.  I have tried the first and second limbo beta
kernels, and I have the same problem with both.

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

How reproducible:

Steps to Reproduce:
1.Boot system using one of the limbo beta kernels
3.Try to resume

Actual Results:  System is hung -- won't respond to keyboard or mouse input,
needs a power-off/power-on cycle to recover.

Expected Results:  System should be functional after a suspend/resume cycle.

Additional info:

Comment 1 Arjan van de Ven 2002-07-31 12:45:03 UTC
can you try the "noapic" option at booting?
Also, could you try the i586 kernel to see if that one does work

Comment 2 Need Real Name 2002-08-01 17:08:49 UTC
(1) I tried the noapic option, but it didn't help any; the system still failed
to resume after a suspend-to-ram

(2) I tried the i586 kernel with partial success.  If I suspended from the
console (X not running) then the system resumed OK (though the console messages
'resume warning: bios doesn't restore PCI state properly; resume warning:  if
resume failed try booting with resume=force' still appeared).  However, when I
tried suspending while running X, I had problems:  when the system came back up
the LCD was dark (backlight was off); I tried ctrl-alt-backspace, ctrl-alt-F2,
etc, but nothing seemed to happen (hard to tell for sure, since the LCD was
completely dark).  After several minutes the system spontaneouly did a power-off.

(3)  I tried the i386 kernel.  This kernel appears to work as expected:  I can
suspend/resume from both the console and X.

Comment 3 Need Real Name 2002-08-21 02:14:15 UTC
The same problem persists in the kernels installed by the limbo2 and null betas.
 If I do a custom config/compite of the kernels sources from these releases,
then I get working kernels.  I can also compile a working kernel from the
kernel.org 2.4.19 release.

The problem is apparently in:
(1) a RedHat applied kernel patch which is included in all the beta kernels but
wasn't included in kernels from preceeding releases
or (2) some config setting used by RedHat in compiling the beta kernels (which I
do not select when I do a custom config/compile).

Comment 4 Need Real Name 2003-06-05 20:28:25 UTC
I experienced exactly the same symptoms on my Thinkpad R31 running RH9 with the
2.4.20-6, 2.4.20-13.9, and 2.4.20-18.9 kernel rpms.  A recompile from the latest
stable Kernel.org source fixed the issue immediately.  In my config file I
turned off all APM-related options except CONFIG_APM_DO_ENABLE.

Comment 5 Arjan van de Ven 2003-06-06 11:24:45 UTC
there are 2 kernel commandline options that are worth a shot here:

which boot-time override the apm config options.
If either one works for your laptop I need the dmidecode output (part of
kernel-utils) to make it the default variant for the specific laptop.
(We default the the option that works for most laptops and then have a list of

Comment 6 Need Real Name 2003-07-18 19:23:50 UTC
Tried both allow-ints and no-allow-ints, neither made the slightest difference.
 I've also compiled a custom kernel from your sources several times, with the
same configuration options I used to get a successful apm from the stock kernel.
 Nothing I've tried gives me a working apm, except switching to the stock kernel

Comment 7 Bugzilla owner 2004-09-30 15:39:47 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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