You are not logged in.
Hey guys,
I installed Arch on my laptop about a month ago, and almost everything works correctly without much hassle. Unfortunately, I'm experiencing some odd issues with suspend and hibernate.
Before Arch I used Ubuntu on this machine, and suspend worked correctly "out of the box" as far as I remember. Hibernate did not work correctly, but I didn't spend too much time trying to fix that.
With my Arch install I've tried setting up pm-utils and s2ram as per the Arch wiki. pm-hibernate basically works; though I often have to manually powerdown the laptop after hibernating, it always resumes correctly. Attempting to suspend, either using pm-utils or s2ram, always works the first time. That is, after booting Arch, I can suspend or hibernate once (using either method for suspend) and it works correctly. The second time I attempt to suspend, the screen goes black, the backlight stays on, and the fan kicks into high gear until I manually powerdown.
Here is my /var/log/pm-suspend.log from a successful suspend:
Initial commandline parameters:
Fri Aug 1 12:04:31 EDT 2008: Running hooks for suspend.
/usr/lib/pm-utils/sleep.d/00clear suspend: success.
/usr/lib/pm-utils/sleep.d/01grub suspend: not applicable.
/usr/lib/pm-utils/sleep.d/05led suspend: not applicable.
/usr/lib/pm-utils/sleep.d/10NetworkManager suspend: success.
/usr/lib/pm-utils/sleep.d/11netcfg suspend: success.
/usr/lib/pm-utils/sleep.d/49bluetooth suspend: not applicable.
/usr/lib/pm-utils/sleep.d/50modules suspend: success.
/usr/lib/pm-utils/sleep.d/55battery suspend: success.
/usr/lib/pm-utils/sleep.d/65alsa suspend: success.
/usr/lib/pm-utils/sleep.d/90clock suspend: success.
/usr/lib/pm-utils/sleep.d/94cpufreq suspend: success.
/usr/lib/pm-utils/sleep.d/95led suspend: not applicable.
/usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend: success.
/usr/lib/pm-utils/sleep.d/99video suspend: success.
Fri Aug 1 12:04:35 EDT 2008: performing suspend
Fri Aug 1 12:04:53 EDT 2008: Awake.
Fri Aug 1 12:04:53 EDT 2008: Running hooks for resume
/usr/lib/pm-utils/sleep.d/99video resume: success.
/usr/lib/pm-utils/sleep.d/98smart-kernel-video resume: success.
/usr/lib/pm-utils/sleep.d/95led resume: not applicable.
/usr/lib/pm-utils/sleep.d/94cpufreq resume: success.
/usr/lib/pm-utils/sleep.d/90clock resume: success.
/usr/lib/pm-utils/sleep.d/65alsa resume: success.
/usr/lib/pm-utils/sleep.d/55battery resume: success.
/usr/lib/pm-utils/sleep.d/50modules resume: success.
/usr/lib/pm-utils/sleep.d/49bluetooth resume: not applicable.
/usr/lib/pm-utils/sleep.d/11netcfg resume: success.
/usr/lib/pm-utils/sleep.d/10NetworkManager resume: success.
/usr/lib/pm-utils/sleep.d/05led resume: not applicable.
/usr/lib/pm-utils/sleep.d/01grub resume: not applicable.
/usr/lib/pm-utils/sleep.d/00clear resume: VT_DISALLOCATE: Device or resource busy
deallocvt: could not deallocate console 63
Returned exit code 1.
Fri Aug 1 12:04:55 EDT 2008: Finished.
And for a failed suspend:
Initial commandline parameters:
Fri Aug 1 12:11:25 EDT 2008: Running hooks for suspend.
/usr/lib/pm-utils/sleep.d/00clear suspend: success.
/usr/lib/pm-utils/sleep.d/01grub suspend: not applicable.
/usr/lib/pm-utils/sleep.d/05led suspend: not applicable.
/usr/lib/pm-utils/sleep.d/10NetworkManager suspend: success.
/usr/lib/pm-utils/sleep.d/11netcfg suspend: success.
/usr/lib/pm-utils/sleep.d/49bluetooth suspend: not applicable.
/usr/lib/pm-utils/sleep.d/50modules suspend: success.
/usr/lib/pm-utils/sleep.d/55battery suspend: success.
/usr/lib/pm-utils/sleep.d/65alsa suspend: success.
/usr/lib/pm-utils/sleep.d/90clock suspend: success.
/usr/lib/pm-utils/sleep.d/94cpufreq suspend: success.
/usr/lib/pm-utils/sleep.d/95led suspend: not applicable.
/usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend: success.
/usr/lib/pm-utils/sleep.d/99video suspend: success.
Fri Aug 1 12:11:29 EDT 2008: performing suspend
My suspicion is that the dealocvt error at the end of a 'successful' resume is what is hosing up the next suspend. I've tried manually doing "dealocvt 63" and get the same error.
What else can I try? Any help in resolving this would be greatly appreciated.
Offline
Bump...?
Offline
I'm not sure how to solve the problem, but I believe your suspicion is correct. I have an HP dv6000 , suspend works correctly, my /var/log/pm-suspend.log is the same as yours except without the error at the last step. I didn't do anything with s2ram, but do have pm-utils. Not sure how much that helps you
Offline
Thanks for the reply, jraab. That does at least more or less confirm that the deallocvt error is causing the problem. I'll start looking into ways to fix that error. Unfortunately the deallocvt man page is painfully sparse.
Any more ideas/suggestions would certainly still be welcome.
--edit--
Deallocvt is not causing the problem, though it might be affected by whatever is. After disabling all of the "not applicable" hooks and the 00clear hook for pm-suspend (which was originally switching to vt 63) I am still experiencing the same behavior: it works the first time, and not the second. Interestingly, the new /var/log/pm-suspend.log shows no errors either the first or second time:
Initial commandline parameters:
Blacklisting 00clear.
Blacklisting 01grub.
Blacklisting 05led.
Blacklisting 49bluetooth.
Blacklisting 95led.
Sat Aug 9 15:17:34 EDT 2008: Running hooks for suspend.
/usr/lib/pm-utils/sleep.d/00clear suspend: disabled.
/usr/lib/pm-utils/sleep.d/01grub suspend: disabled.
/usr/lib/pm-utils/sleep.d/05led suspend: disabled.
/usr/lib/pm-utils/sleep.d/10NetworkManager suspend: success.
/usr/lib/pm-utils/sleep.d/11netcfg suspend: success.
/usr/lib/pm-utils/sleep.d/49bluetooth suspend: disabled.
/usr/lib/pm-utils/sleep.d/50modules suspend: success.
/usr/lib/pm-utils/sleep.d/55battery suspend: success.
/usr/lib/pm-utils/sleep.d/65alsa suspend: success.
/usr/lib/pm-utils/sleep.d/90clock suspend: success.
/usr/lib/pm-utils/sleep.d/94cpufreq suspend: success.
/usr/lib/pm-utils/sleep.d/95led suspend: disabled.
/usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend: success.
/usr/lib/pm-utils/sleep.d/99video suspend: success.
Sat Aug 9 15:17:36 EDT 2008: performing suspend
#---NOTE--- when the suspend fails, the log is identical to this one up to this point.
Sat Aug 9 15:17:54 EDT 2008: Awake.
Sat Aug 9 15:17:54 EDT 2008: Running hooks for resume
/usr/lib/pm-utils/sleep.d/99video resume: success.
/usr/lib/pm-utils/sleep.d/98smart-kernel-video resume: success.
/usr/lib/pm-utils/sleep.d/95led resume: disabled.
/usr/lib/pm-utils/sleep.d/94cpufreq resume: success.
/usr/lib/pm-utils/sleep.d/90clock resume: success.
/usr/lib/pm-utils/sleep.d/65alsa resume: success.
/usr/lib/pm-utils/sleep.d/55battery resume: success.
/usr/lib/pm-utils/sleep.d/50modules resume: success.
/usr/lib/pm-utils/sleep.d/49bluetooth resume: disabled.
/usr/lib/pm-utils/sleep.d/11netcfg resume: success.
/usr/lib/pm-utils/sleep.d/10NetworkManager resume: success.
/usr/lib/pm-utils/sleep.d/05led resume: disabled.
/usr/lib/pm-utils/sleep.d/01grub resume: disabled.
/usr/lib/pm-utils/sleep.d/00clear resume: disabled.
Sat Aug 9 15:17:55 EDT 2008: Finished.
I can do a raw "echo mem >/sys/power/state" and, lo and behold, the exact same thing happens. I'm currently using the latest Arch kernel... could this be a problem with the kernel anyway?
Last edited by ladr0n (2008-08-09 19:23:34)
Offline
take anything I say with a grain of salt, my linux knowledge is pretty limuted, and this is just my first week with arch (also switching over from ubuntu). How are you initiating the suspend. I always had problems on ubuntu with just closing the lid. I haven't actually tested that with arch yet, but have been using pm-suspend.
Offline
I don't have it set to do anything on a lid close event: that's always given me trouble too. I don't think it even worked on the braindead OS they gave me with the thing . Calling pm-suspend or s2ram from the command line or calling them through hal from gnome give the same result.
I've tried basically every combination of pm-suspend hooks (including the exact set Ubuntu was successfully using, as far as i can tell from non-bootable Ubuntu partition) to no avail.
The thing that confuses me the most is that according to the logs, pm-suspend seems to think it's working perfectly, even when it obviously fails.
Does anyone have any idea what might be causing this?
Offline
I have the dv6058cl, and I have to use s2ram -f (in the uswsusp package) to get suspend to ram working. pm-suspend will suspend, but only resume to a black screen. I also have to have the nvidia drivers installed. I haven't tried in a long time now, but with the nv (open source) driver, suspend wouldn't work at all.
To get suspend to work when the lid is closed, add s2ram -f in /etc/acpi/handler.sh under the button/lid entry.
s2disk and s2both also work on my machine.
Good luck (I know this post may be a little late!)
Scott
Offline