Bug 680104

Complete hardware profile: http://www.smolts.org/client/show_all/pub_c775bdb1-be96-47ed-8e2f-819cb3a0465a

Same problem

http://www.smolts.org/client/show/pub_709eb022-6dcc-461e-8e6b-5ff8432280e8

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.

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

Created attachment 493399 [details]
dmesg output

Created attachment 493400 [details]
/var/log/messages output

Created attachment 493401 [details]
/var/log/Xorg.0.log output

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/

Created attachment 495675 [details]
pm-suspend.log output

Created attachment 495680 [details]
pm-suspend.log output with debug mode and quirktest

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 :)?

Created attachment 495683 [details]
pm-utils-bugreport-info output

(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:
https://bugzilla.kernel.org/show_bug.cgi?id=32522
https://bugzilla.kernel.org/show_bug.cgi?id=31522

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?

Actually it works here now after upgrading the BIOS to version 11CA and with the lastest F15 kernel:

Linux idefix 2.6.38.8-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 2.6.40.6 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.

Thanks Johannes.