Description of problem:
Hitting the suspend key (or closing) the lid on my Samsung NC10 netbook does suspend the laptop but when it is woken up again the screen remains black with background light off.
Steps to Reproduce:
1. Suspend laptop
2. Wake up laptop
Screen remains black
Laptop to wake up correctly
Hardare: Intel Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics controller (rev 03)
When trying to suspend using the gnome-shell interface it only prompts me for shutdown and not for suspend.
Complete hardware profile: http://www.smolts.org/client/show_all/pub_c775bdb1-be96-47ed-8e2f-819cb3a0465a
Interesting... I'm also testing using a Samsung NC10 (using test day live CD with external USB DVD-RW):
Closing the lid suspends properly, but when I power back up I see the windows I had up minus the toolbars, and input via mouse / keyboard appears to be disabled. I then tried switching to a different VT to try to get further information, which resulted in a static colour being output to the screen which changed every few second (i.e. solid, red, green blue, grey, then various patterns). Obviously at this point the system was completely locked up.
I'll attach a couple of pictures from cameraphone to try and illustrate this better.
Created attachment 480975 [details]
Image of NC10 hanging after powering back on from suspend
Created attachment 480976 [details]
Image of NC10 after switching to VT following hang
This is most likely not Xorg issue (or not purely a Xorg issue) ... reassigning to gnome-power-manager folks for further investigation, excepting it to coming back with some pearls of wisdom from them.
FYI, it still doesn't wake up with latest kernel/X.org/Mesa auf F15 as of 2011-03-19.
Testing with beta of F15 released 19/04/2011 (after performing updates, same hardware as before) shows the following behaviour:
* Suspend using button in Gnome 3 works, as does suspending by closing the lid on the NC10, as does pm-suspend (as root).
* When powering on to come out of suspend mode, can hear CPU fan, see power LED and wireless LED come on (plus the HDD LED for a split second only).
* System does not come out of suspend mode, blank screen only, no further activity at all. CPU fan can still be heard and LED lights are still on.
As per a comment on bug 679963, I tried kernel option: acpi_sleep=nonvs
Unfortunately this made no difference, same behaviour.
As per general fault finding advice given on other testing day bugs, have done the following:
"Please add drm.debug=0x04 to the kernel command line, restart computer, and
* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)"
Attachments to follow shortly (no xorg.conf in this instance).
Created attachment 493399 [details]
Created attachment 493400 [details]
Created attachment 493401 [details]
Just for completeness, the NC10 is using the latest firmware, and has been doing so and working fine with F14 for some time. Only mention this because it's well known the NC10 needs a firmware update to get certain features working...
lshal | grep firmware
system.firmware.release_date = '09/08/2009' (string)
system.firmware.vendor = 'Phoenix Technologies Ltd.' (string)
system.firmware.version = '11CA.M015.20090908.RHU' (string)
storage.firmware_version = '11.01A11' (string)
Created attachment 495675 [details]
Created attachment 495680 [details]
pm-suspend.log output with debug mode and quirktest
Please provide output of:
Can you ssh the machine after resume?
Could you try without X (e.g. from something previously known as runlevel 3 :)?
Created attachment 495683 [details]
(In reply to comment #15)
> Please provide output of:
> # pm-utils-bugreport-info.sh
> Can you ssh the machine after resume?
> Could you try without X (e.g. from something previously known as runlevel 3 :)?
Output of script attached as requested, but unfortunately neither my attempt to
ssh to the machine nor resume under runlevel 3 was successful :(
Please retry with and without AC connected and also without pm-utils:
# echo mem > /sys/power/state
(In reply to comment #18)
> Please retry with and without AC connected and also without pm-utils:
> # echo mem > /sys/power/state
With or without AC connected, running the above command results in the same behaviour as running pm-suspend, i.e. suspend works properly but resume does not. Please can you explain what is required when you say without pm-utils? Do you mean I need to run:
# yum remove pm-utils
...as this will remove 65 packages including gnome-panel, gnome-session, gnome-shell, gdm, etc. as well?
Rob thanks for info. The "echo mem > /sys/power/state" bypassed the pm-utils and that is what I meant in comment 18. So it seems to be a problem in the kernel and according to comment 12 it is probably regression, thus reassigning to kernel.
Maybe related upstream bugzillas:
Thanks for taking a look at this - the kernel bugs listed above make for interesting reading... I also noted:
Base on this kernel bug, I've tried:
1. Setting "intel_idle.max_cstate=0" as a kernel boot parameter (as per comment 13)
2. Disabling hyper-threading in the BIOS (as per comment 18)
3. Setting "maxcpus=1 nolapic_timer" as a kernel boot parameter (as per comment 38)
4. Setting "acpi_skip_timer_override nohpet" as a kernel boot parameter (as per comment 42)
Unfortunately, there was no difference with any of the above. Either it's a different bug (the specific models of netbooks listed are different), I did something wrong, or the bug affects the NC10 differently from other models. The description in comment 2 seems to describe the problem exactly, but I have had no problems with suspend using Fedora 14 (which uses 2.6.35).
Perhaps a red herring?
Actually it works here now after upgrading the BIOS to version 11CA and with the lastest F15 kernel:
Linux idefix 184.108.40.206-32.fc15.i686.PAE #1 SMP Mon Jun 13 19:55:27 UTC 2011 i686 i686 i386 GNU/Linux
I also enabled "Data Execution Prevention" in the BIOS but I think that is totally unrelated.
Latest kernel made no difference for me, however I tried enabling the DEP as you suggested and this has resolved the suspend problem!
For reference the option in the BIOS is under the Advanced menu and is entitled: "EDB (Execute Disable Bit)".
Well done sir, problem solved, thank you very much! :D
> Latest kernel made no difference for me, however I tried enabling the DEP as
> you suggested and this has resolved the suspend problem!
> For reference the option in the BIOS is under the Advanced menu and is
> entitled: "EDB (Execute Disable Bit)".
OK, interesting. Seems like a pretty interesting side-effect of that option. Actually wondering why this option is not enabled by default in the BIOS.
This seems to be a BIOS issue, but I thought I would ask if you are seeing any problems on the 220.127.116.11 F15 kernel.
I don't know what changed in the kernel but to my surprise it works with kernel 2.6.40 regardless of the state of the "Execute Disable Bit" in the BIOS.