Suspend and resume from ram seems to work mostly on my new computer. But after resume from acpi S3 mode the keyboard is dead. I still can press the "reboot" button in gnome, but the system doesn't reboot than. The last line I see in the reboot process is "Sending all processes the TERM signal" - On this point the system waits forever.
Will attach the config and a dmesg.
Created attachment 23802 [details]
Created attachment 23803 [details]
dmesg - Fresh boot - No s2r cycle
Created attachment 23805 [details]
One s2r cycle - system and keyboard seems to be okay
Okay, it doesn't seem to be a keyboard problem at all!
After the second s2r cycle the system behaves strangley:
- gnome screensaver password logon: I can enter my password
- Firefox: I can enter this bug report
- gnome-terminal doesn't seems to react to the keyboard anymore! Also killing the gnome-terminal and restarting it again doesn't seem to help
- The nm-applet doesn't seem to reconnect after the second s3r cycle.
- I cannot switch away from X server to virtual console 2, etc. E.g. pressing Ctrl+Alt+F2 doesn't seem to do anything!
- Trying to execute a command from gnome with Alt+F2 opens the command line window, but it doesn't seem to matter what I enter, all commands seems to do nothing
- gnome process monitor shows that the process "bash" is in zombie state and the processes "nm-applet and "gnome-terminal" are state "not interruptbile".
Any help appreciated!
maybe related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/468772
Created attachment 23833 [details]
dmesg after one s2r cycle
One S2R cycle with PM debug. Everything seemed to work after this cycle. The second s2r cycle left the machine in the strange state. I'll try to get the dmesg from the second cycle.
I switched to 126.96.36.199. Here I need to boot with the "nomodeset" option as something in the intel driver broke. But suspend and resume from ram started to work properly with this kernel version.
I tested 188.8.131.52 with the "nomodeset" option, but still got the strange system behaviour/error after resume from ram.
So good news 184.108.40.206 seems to suspend and resume correctly!
Shall I provide dmesg and config of this kernel?
Close this bug report as the bug has been fixed in the upstream kernel.