Bug 70154

Summary:	suspend/resume hangs on dell latitude c800
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <grover>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	8.0	CC:	grover, truitejeunefille, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-30 15:39:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:
Always

Steps to Reproduce:
1.Boot system using one of the limbo beta kernels
2.Suspend
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:
apm=no-allow-ints
and
apm=allow-ints

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
others)

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

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

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/