Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Suspend fails on Samsung NC10 when NX is disabled in the BIOS|
|Product:||[Fedora] Fedora||Reporter:||Johannes Schmid <jhs>|
|Component:||kernel||Assignee:||Kernel Maintainer List <kernel-maint>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||a9016009, ajax, gansalmon, itamar, jonathan, jskarvad, kernel-maint, madhu.chinakonda, mail, mcepl, michelduquaine, opensource, pknirsch, rhughes, richard, speed47_redhat, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-10-31 14:11:31 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Johannes Schmid 2011-02-24 06:07:32 EST
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. How reproducible: Happens always Steps to Reproduce: 1. Suspend laptop 2. Wake up laptop 3. fail Actual results: Screen remains black Expected results: Laptop to wake up correctly Additional info: 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.
Comment 1 Johannes Schmid 2011-02-24 06:18:30 EST
Complete hardware profile: http://www.smolts.org/client/show_all/pub_c775bdb1-be96-47ed-8e2f-819cb3a0465a
Comment 2 Michel Duquaine 2011-02-24 12:50:56 EST
Comment 3 Rob Whalley 2011-02-25 06:47:49 EST
Interesting... I'm also testing using a Samsung NC10 (using test day live CD with external USB DVD-RW): http://www.smolts.org/client/show/pub_6addbf83-d0f4-47c5-8219-d88d2c00e5aa 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.
Comment 4 Rob Whalley 2011-02-25 06:50:47 EST
Created attachment 480975 [details] Image of NC10 hanging after powering back on from suspend
Comment 5 Rob Whalley 2011-02-25 06:51:42 EST
Created attachment 480976 [details] Image of NC10 after switching to VT following hang
Comment 6 Matěj Cepl 2011-02-25 09:16:01 EST
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.
Comment 7 Johannes Schmid 2011-03-20 00:32:09 EDT
FYI, it still doesn't wake up with latest kernel/X.org/Mesa auf F15 as of 2011-03-19.
Comment 8 Rob Whalley 2011-04-20 05:08:42 EDT
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 attach * 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).
Comment 10 Rob Whalley 2011-04-20 05:10:16 EDT
Created attachment 493400 [details] /var/log/messages output
Comment 11 Rob Whalley 2011-04-20 05:11:09 EDT
Created attachment 493401 [details] /var/log/Xorg.0.log output
Comment 12 Rob Whalley 2011-04-20 05:28:25 EDT
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) See also: https://help.ubuntu.com/community/NC10#BIOS http://smorgasbord.gavagai.nl/2009/05/flash-your-samsung-nc10-bios-from-linux/
Comment 13 Rob Whalley 2011-04-28 18:04:58 EDT
Created attachment 495675 [details] pm-suspend.log output
Comment 14 Rob Whalley 2011-04-28 18:24:57 EDT
Created attachment 495680 [details] pm-suspend.log output with debug mode and quirktest
Comment 15 Jaroslav Škarvada 2011-04-28 18:32:22 EDT
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 :)?
Comment 16 Rob Whalley 2011-04-28 18:41:24 EDT
Created attachment 495683 [details] pm-utils-bugreport-info output
Comment 17 Rob Whalley 2011-04-28 18:50:48 EDT
(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 :(
Comment 18 Jaroslav Škarvada 2011-04-29 04:17:02 EDT
Please retry with and without AC connected and also without pm-utils: # echo mem > /sys/power/state
Comment 19 Rob Whalley 2011-04-29 15:40:31 EDT
(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?
Comment 20 Jaroslav Škarvada 2011-05-01 16:46:06 EDT
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.
Comment 21 Jaroslav Škarvada 2011-05-01 17:11:45 EDT
Maybe related upstream bugzillas: https://bugzilla.kernel.org/show_bug.cgi?id=32522 https://bugzilla.kernel.org/show_bug.cgi?id=31522
Comment 22 Rob Whalley 2011-05-01 19:26:24 EDT
Thanks for taking a look at this - the kernel bugs listed above make for interesting reading... I also noted: https://bugzilla.kernel.org/show_bug.cgi?id=21952 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?
Comment 23 Johannes Schmid 2011-06-25 05:42:58 EDT
Actually it works here now after upgrading the BIOS to version 11CA and with the lastest F15 kernel: Linux idefix 220.127.116.11-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.
Comment 24 Rob Whalley 2011-06-25 17:11:18 EDT
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
Comment 25 Johannes Schmid 2011-06-26 04:47:06 EDT
> 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.
Comment 26 Josh Boyer 2011-10-11 16:44:37 EDT
This seems to be a BIOS issue, but I thought I would ask if you are seeing any problems on the 18.104.22.168 F15 kernel.
Comment 27 Johannes Schmid 2011-10-30 14:40:45 EDT
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.
Comment 28 Josh Boyer 2011-10-31 14:11:31 EDT