Red Hat Bugzilla – Bug 70154
suspend/resume hangs on dell latitude c800
Last modified: 2008-08-01 12:22:52 EDT
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:
can you try the "noapic" option at booting? Also, could you try the i586 kernel to see if that one does work
(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.
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).
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.
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)
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.
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/