Distribution: Debian unstable
Hardware Environment: HP compaq nc4010 notebook
Software Environment: Tried booting with init=/bin/bash ... so very little :)
When put into S3 sleep (echo 3 > /proc/acpi/sleep) the laptop seems to enter
sleep properly; it says a couple of things on the console and powers off. The
wireless light goes out and the power light goes from steady to flashing.
All the signs of a laptop in slumber.
Press the power button to wake the laptop again, the wireless light comes on and
the power light goes steady and the fans power up and I think the hard drive
sounds like its spinning up too.
That's it though; nothing else comes back. The screen backlight remains off,
typing on the keyboard has no effect (Caps Lock doesn't toggle the light) and
neither the wireless nor internal network cards seem to join the network again.
I've tried this with a plan-old VGA console and no modules loaded, and it still
does the same.
A hard power-down (button for 7s) is needed to switch it off, and when booted
again there's nothing in the logs during the time it was supposed to be waking up.
Steps to reproduce:
1. Boot machine
2. echo 3 > /proc/acpi/sleep
3. Wake machine my pushing power button
4. Laptop wakes, but Linux remains catatonic.
Created attachment 2824 [details]
Output of dmesg
Created attachment 2825 [details]
Output of lspci -vv
Created attachment 2826 [details]
Output of dmidecode
Created attachment 2827 [details]
Output of acpidmp
Created attachment 2828 [details]
Content of /proc/interrupts
My Compaq Armada E500 seems to suffer from the same (or a similar) problem.
Putting it to sleep (either to S3 or S4, and either through the /proc interface
or the /sys interface) ssems to work fine, and the laptop enters sleep mode
(power led goed from lit to flashing). However, pressing the suspend button
again seems to turn off the computer: the battery led flashed a few times and
then the power seems to be cut. Pressing the button again turns on the computer
again and leads it through the normal boot procedure.
I tested both kernel 2.6.3 (vanilla) and 2.6.6-mm2.
firstname.lastname@example.org -- that just sounds like your computer doesn't know that button
needs to wake the machine again; there's a patch for that elsewhere on this
My problem is that the computer *is* being woken up, but just isn't waking up.
Could you please try the patch in Bug 1415
I tried that patch, but that didn't change matters -- the computer is physically
waking up (power light, etc.) but Linux isn't.
I also get this (after applying the 20040715 ACPI patch against 22.214.171.124 to get
it to respond to the sleep button) on my Compaq Evo N600c. Would the output of
dmidecode/acpidmp/etc. be of use?
Is the problem still there with latest 2.6 kernel?
If yes, can you make sure whether the problem is only with restore of the
video (try connecting through network or serial after resume).
If it is only the video problem,
- Please try the options in Documentation/power/video.txt
- Try the workaround in bug #3670
Yeah, I'm certain that it's not due to restoration of the video ...
The keyboard doesn't work, even pushing things like the Caps Lock key doesn't
cause the light to light up.
If I switch all the fans off, and suspend it, they don't come back on resume
(I'd expect the kernel to spin them back up again as it restored state).
Sleeping with "echo 3 > /proc/acpi/sleep && logger AWAKE" never logs the "AWAKE".
We even tried adding some assembler to the wake-up routine to emit a beep out of
the speaker, and that didn't work either.
Does this system have serial port by any chance? That may help us debug
No, sadly not. Or a parallel port.
I have the same exact problem with Compaq Presario R3000 (Bug #3455). I assume
the problem is one of the drivers those laptops use does not support
suspend/resume correctly? (maybe more than one)
Have tried with init=/bin/sh and just about everything as a module, and a
totally stripped-out kernel -- it'd have to be a pretty critical driver to be
not waking up.
And debugging through adding beep code seems to indicate the wakeup routine is
What else could be the problem? has anyone tried with 2.6.10-rc1 or -rc2 or
maybe even -mm?
Could it be the DSDT/SSDT?
I'm convinced this isn't just a video problem, as nothing comes back (no
keyboard, network, etc.)
From the symptom you reported, the system did suspend correctly. Could you
please unload some driver before suspend, such as sound card and EHCI driver?
Except if you look in the comments, you'll see I made a totally stripped-out
kernel with no drivers in it (even booted from a ramdisk so I didn't need the
IDE driver) and no software loaded.
It still doesn't resume,
any change with the patch from bug #3599 applied?
Already commented on that bug, I applied the "don't disable the bus arbiter"
patch and didn't see any change.
Though the nc4010 is technically within the same family of laptops, for whatever
reason HP decided not to go the Centrino route like they did with the others --
and instead it has an ATI/ALi chipset throughout.
I own a Compaq Presario 900 laptop computer, and I have had the *exact* same
problem as described by the original poster for as long as I can remember.
Pretty much from the 2.6.0-tests till 126.96.36.199 now -- the same problem has occurred.
FWIW, I do have a parallel and serial port on mine; Venkatesh Pallipadi
mentioned that it could help debug further -- just tell me what to do and I'll
do it :)
But yeah, I figured I'd redescribe the problem:
$ echo -n "mem" > /sys/power/state
Goes to sleep. In Windows I can touch the touchpad, hit buttons on the
keyboard, or (IIRC) press the power button to wake it up.
In Linux, moving the touchpad does nothing, as with pressing buttons on the
keyboard. Pressing the power button makes the machine "wake up" -- the LED goes
from blinking to solid, PCMCIA devices light up again, etc -- but the kernel
seems to panic. PowerNOW! and CPU frequency scaling seem to die because the fan
goes berserk. The only thing left to do is hold the power button down to shut
it down, and start it up again.
using S4 works in console mode, but freezes the computer if using X. This,
OTOH, is a very different issue and should probably not be discussed much here
though. Just thought I'd bring it up though.
This bug appears to have been dormant for a few months -- hopefully someone can
advise on what to do with the serial port to gather more info to help out.
That must be the same problem as I have.
Anyone has any progress about that bug ?
In my tests, if I unload all modules before suspending, then the power button
will bring it back on (except it doesn't really resume), but if I leave the
mouse module/s (evdev too?) I can also just touch the touchpad to get the same
result of quasi-wake-up.
I have the same problem (kernel 188.8.131.52) on a Dell Inspiron 600m.
"echo 4 > /proc/acpi/sleep" works fine.
"echo 3 > /proc/acpi/sleep" suspends correctly but after powering back up the
resume fails early on. No network access, no display, no keyboard (CAPS lock
light) or mouse.
This problem has always affected my system. I also have a serial port if it
would help with debugging.
I tried suspend to ram on 2.6.13-rc6-git6 and the problem still occurs.
The same for me. My laptop is a Compaq Presario 2532EA, with hardware similar to
nc4010. I tried with kernel 2.6.13-rc5, with "init=/bin/sh", no framebuffer and
the beep code at the beginning of wakeup routine. System hangs on resume and I
can't hear beep; it seems that the wakeup code (wakeup.S) is not reached.
Same behavior for me. Suspend appears to work, but resume seems to do little
more than apply power to various parts of the system -- HD, fan, LEDs -- and
leaves the computer otherwise unresponsive. CTRL-ALT-DEL does nothing, caps
lock and numlock don't toggle the keyboard LEDs, and the screen remains
powered down. Meanwhile, the fan is running at full blast, and all that's
left is for a hard shutdown with the power button.
This is kernel 2.6.17 on an HP Compaq TC4200.
Suspend2 works beautifully, repeatedly.
I have HP compaq nc4000 laptop and it is exhibiting the same problem. suspend to
ram works but resume never reaches the linux kernel.
I am following LKML and http://bugzilla.kernel.org/show_bug.cgi?id=3691 points
to some quirk that should worked out in recent acpi versions. Anyone has a clue
as to what acpi patch to apply ?
Please re-open if problem is still present in 2.6.21