Bug 36482
|
Description
Patrick
2011-06-01 20:36:13 UTC
Created attachment 60452 [details] Old bug report on launchpad that might contain relevant information Have a look at the screenshot in comment #5 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/757921/comments/5 Created attachment 60462 [details]
A dmesg after an unsucessful hibernation attemt - could be unrelated
Created attachment 60472 [details]
A dmesg after an unsucessful resume - no idea how I landed in that busybox shell from where I saved it ...
Created attachment 60482 [details]
screenshot after unsuccessful resume, with Xorg running, after hibernate from vt1
Created attachment 60492 [details]
screenshot after unsuccessful resume, with Xorg NOT running, after hibernate from vt1
This is probably the most valueable screenshot. When resuming, this time, after the ram image was loaded from the hd, several oops messages appeared on the screen. They came in ~3 series of ~~5 oops messages and with pauses of ~1s in between each bunch. This is a screenshot of the last message seen. I could still switch vts and reboot with Alt-SysReq b here.
does the problem go away if "maxcpus=1" is always used? does suspend to ram work any better? please attach the dmesg from a SUCCESSFUL hibernate/resume. Created attachment 61582 [details]
dmesg of successful hibernate / resume
this succeeded, even though i had a second monitor connected to hdmi output during resume (the external monitor is "causing trouble" for other resons then hibernate/resume as well, like closing the laptop lid... but that's a different bug)
Created attachment 61592 [details]
dmesg of successful suspend-to-ram / resume (continuation of the last one)
suspend to ram tends to work, generally, for as far as the kernel is concerned, at least.
the x server / driver / compiz / unity quartet is sometimes cousing trouble though which i think could be related to suspend/resume (maybe): the x session tends to lock up after 2 or 3 suspend/resume cycles. first, the screen is not beeing properly updated, e.g. some windows are visible but not responsing to mouse/keyboard input. sometimes the screensaver unlock dialog is not visible, etc. - finally i loose patience and hard-switch it off. but this, as said, are actually different issues, i guess
next, i will boot and test with maxcpus=1 ...
Created attachment 61602 [details]
dmesg of successful hibernate / resume (including unrelated cfg80211 log spam)
attachment id 61582: "dmesg of successful hibernate / resume" is filtered with
$ dmesg | egrep cfg80211:\|wlan0:\|Associated:
because i think those lines are superfluous but here is the original dmesg output just in case i'm wrong
No, maxcpus=1 doesn't have any noticeable effects.
First it worked once. Then failed on the second try. After that I booted again, tried to hibernate: Failure because of firefox-bin "refusing to freeze after 20 seconds" or something along that line. Tried again. Hibernated. Booting (always using maxcpus=1), failure. No signs of x any more. No possibility to get a text console. Ctrl-Alt-F1 not showing any effect. Alt-SysReq-{s,u,b} - reboot. Last try, again maxcpus=1. (It's working, there is only one cpu e.g. in htop) Hibernate. Success onn first try. Reboot - maxcpus=1 - failure. Managed to switch to vt1 somehow by pressing Ctrl-Alt-F1 at the right time. Now, the "tty1" login prompt was visible with cursor blinking but no letters appearing when trying to type my login. Switching to tty2 works - "tty2" login prompt visible, but same problem: can't type my login name - no response to letter keys and no response to return key. Out of ideas. Alt-SysRq-{s,u,b}. Reboot.
Any other ideas ?
So the funny thing after the last unsuccessful resume was that I could switch between tty1-6 but at the same time couldn't type anything to the "Login: _" - even though the cursor was blinking and the process waiting for input there. ... When i finally tried to switch back to X with Ctrl-Alt-F7, the screen just went black and I couldn't swich back any more. Then I rebooted with Alt-SysRq-b... This bug is fixed in 3.2.1 Hibernate / Resume and Suspend / Wakeup work reliably and fast. Somebody with the proper permissions could set the appropriate status. (In reply to comment #12) > This bug is fixed in 3.2.1 > > Hibernate / Resume and Suspend / Wakeup work reliably and fast. > > Somebody with the proper permissions could set the appropriate status. Good to know. Bug closed. :) |