You are not logged in.
same here, it started with 3.1, but it was rare (like 1 in 20 cases). After 3.1.5, it's in all cases. I'm going to install -lts kernel, but please if some update will solve this, post it here so I'll now I can use the ARCH kernel again...
core i5 4590, x86_64, nvidia 970
Offline
@marvn: Any update from trying lts? I have the problem with both custom 3.1.5 and ARCH default. Any other suggestions? I'm at wit's end. Now that you say something, I did have some issues from suspend/resume cycles before, but it was so rare, I figured it was just a fluke. I often thought it was from many, many suspend/resumes without any power on/off cycles between...
Offline
@marvn: Any update from trying lts? I have the problem with both custom 3.1.5 and ARCH default. Any other suggestions? I'm at wit's end. Now that you say something, I did have some issues from suspend/resume cycles before, but it was so rare, I figured it was just a fluke. I often thought it was from many, many suspend/resumes without any power on/off cycles between...
downgrading kernel always helped me in the past...didn't get to it so far, so cannot be sure
core i5 4590, x86_64, nvidia 970
Offline
Samuel_Johnson wrote:Have you added resume=/path/to/swap/drive as your kernel option in menu.lst?
Hi Samuel,
Yes, I have. I am not using Grub as loader, I am using syslinux instead, and resume line is added. My syslinux.cfg is the following:
# Config file for Syslinux - # /boot/syslinux/syslinux.cfg # # Comboot modules: # * menu.c32 - provides a text menu # * vesamenu.c32 - provides a graphical menu # * chain.c32 - chainload MBRs, partition boot sectors, Windows bootloaders # * hdt.c32 - hardware detection tool # * reboot.c32 - reboots the system # * poweroff.com - shutdown the system # # To Use: Copy the respective files from /usr/lib/syslinux to /boot/syslinux. # If /usr and /boot are on the same file system, symlink the files instead # of copying them. # # If you do not use a menu, a 'boot:' prompt will be shown and the system # will boot automatically after 5 seconds. # # Please review the wiki: https://wiki.archlinux.org/index.php/Syslinux # The wiki provides further configuration examples DEFAULT arch PROMPT 0 # Change to 1 if you do not want to use a menu TIMEOUT 50 # You can create syslinux keymaps with the keytab-lilo tool #KBDMAP de.ktl # Menu Configuration # Either menu.c32 or vesamenu32.c32 must be copied to /boot/syslinux #UI menu.c32 UI vesamenu.c32 # Refer to http://syslinux.zytor.com/wiki/index.php/Doc/menu MENU TITLE Arch Linux #MENU BACKGROUND splash.png MENU COLOR border 30;44 #40ffffff #a0000000 std MENU COLOR title 1;36;44 #9033ccff #a0000000 std MENU COLOR sel 7;37;40 #e0ffffff #20ffffff all MENU COLOR unsel 37;44 #50ffffff #a0000000 std MENU COLOR help 37;40 #c0ffffff #a0000000 std MENU COLOR timeout_msg 37;40 #80ffffff #00000000 std MENU COLOR timeout 1;37;40 #c0ffffff #00000000 std MENU COLOR msg07 37;40 #90ffffff #a0000000 std MENU COLOR tabmsg 31;40 #30ffffff #00000000 std # boot sections follow # # TIP: If you want a 1024x768 framebuffer, add "vga=773" to your kernel line. # #-* # (0) Arch Linux LABEL arch MENU LABEL Arch Linux LINUX ../vmlinuz-linux APPEND root=/dev/sda8 ro resume=/dev/sda11 INITRD ../initramfs-linux.img # (1) Arch Linux Fallback LABEL archfallback MENU LABEL Arch Linux Fallback LINUX ../vmlinuz-linux APPEND root=/dev/sda8 ro resume=/dev/sda11 INITRD ../initramfs-linux-fallback.img # (2) Windows LABEL windows MENU LABEL Windows COM32 chain.c32 APPEND hd0 2 LABEL hdt MENU LABEL HDT (Hardware Detection Tool) COM32 hdt.c32 LABEL reboot MENU LABEL Reboot COM32 reboot.c32 LABEL off MENU LABEL Power Off COMBOOT poweroff.com
I think that "resume=/dev/sda11"should be put in front of "ro" like this
APPEND root=/dev/sda8 resume=/dev/sda11 ro
and by the way,it is a bad idea to turn resume on in your fallback mode,I think the fallback line should be written like this:
LABEL archfallback
MENU LABEL Arch Linux Fallback
LINUX ../vmlinuz-linux
APPEND root=/dev/sda8 ro
INITRD ../initramfs-linux-fallback.img
sorry for my poor English:-)
Archlinux+Lxde+Openbox work well on my poor ASUS eeePC 1005HA!
Offline
I have the same problem. Is there any update ?
Offline
@calyce: not that I know of, unfortunately. This is a really huge bummer for me, so I hope someone is able to track down the problem, or at least suggest how to do so.
@ferstar: this isn't necessary for those of us talking about suspend to RAM, right? I don't suspend to swap (hibernate); I just use pm-suspend.
Offline
Got it! Found another post on this issue and that thread led to the discovery that it was probably an upstream issue, as downgrading to 3.1.4 fixed the issue. Also, the OP was using nvidia, but another poster came along using ATI with the same problem, so it may be card independent (though my macbook wtih intel i915 isn't affected). In any case, the OP disabled a BIOS option for HPET on his system and this fixed the issue (or worked around it, however you want to see it).
Users with no BIOS option can append hpet=disable to their kernel line in /boot/grub/menu.lst, for example:
kernel /vmlinuz-linux root=/dev/mapper/root cryptdevice=/dev/sda3:root ro hpet=disable
I just did this and it worked for me. The OP in the other post created an Arch bug report as well, so you can track any updates/progress there.
Hope this helps!
Last edited by jwhendy (2011-12-26 02:50:39)
Offline
Users with no BIOS option can append hpet=disable to their kernel line in /boot/grub/menu.lst, for example:
kernel /vmlinuz-linux root=/dev/mapper/root cryptdevice=/dev/sda3:root ro hpet=disable
I just did this and it worked for me. The OP in the other post created an Arch bug report as well, so you can track any updates/progress there.
Thanks, jwhendy. You just made my day. Now my suspend-to-ram works again. (btw, I am using ATI, so this isn't NVIDIA specific)
toni, did this work for you? it may be helpful to put the link to the bug report and the workaround in your first post to assist future solution seekers.
Offline
@namelessone: finding that post made my day yesterday; just happy to pass it on. Not being able to suspend to RAM is pretty much a deal breaker for me, so I'm sooo glad I have a workable computer again (work machine; shutting down just to travel to another building for a meeting was just silly. I've been living in Windows since this problem came up).
Glad this is working for others as well. Hopefully it gets fixed soon, though I don't even know what HPET benefits/does! Haven't noticed a difference thus far.
Offline
It's also working for me.
Many thanks jwhendy
Offline
jwhendy wrote:Users with no BIOS option can append hpet=disable to their kernel line in /boot/grub/menu.lst, for example:
kernel /vmlinuz-linux root=/dev/mapper/root cryptdevice=/dev/sda3:root ro hpet=disable
I just did this and it worked for me. The OP in the other post created an Arch bug report as well, so you can track any updates/progress there.
Thanks, jwhendy. You just made my day. Now my suspend-to-ram works again. (btw, I am using ATI, so this isn't NVIDIA specific)
toni, did this work for you? it may be helpful to put the link to the bug report and the workaround in your first post to assist future solution seekers.
Hi namelessone,
I have added this workaround and their links in the first post to help users to find a workaround more quickly.
Regarding to me, problem continues. I have tested it by addind hpet=disabled in kernel line as I have no BIOS option in my system but with no success in kernel 3.1.5 so I have downgraded to 3.1.4 and same results, not working. Maybe there is a problem in my config files or something else or I need to update some package so currently I am trying to understand what is happening in my system.
Offline
Hi All again,
Researching on how to deal with this issue, I have encountered some errors in /var/log/pm-powersave.log that seems to be related with it:
(...)
Running hook /usr/lib/pm-utils/power.d/pcie_aspm false:
/usr/lib/pm-utils/power.d/pcie_aspm: line 9: echo: write error: Operation not permitted
(...)
Running hook /usr/lib/pm-utils/power.d/wireless false:
Turning powersave for wlan0 off...Error for wireless request "Set Power Management" (8B2C) :
SET failed on device wlan0 ; Operation not supported.
Failed.
(...)
I have googled and I have found another thread where these errors are also posted by another user with the same issue. It seems that wifi could be the problem...
Anyway I will continue investigating....
Offline
toni,
My guess is that the error you see in the powersave log is harmless (but I am occasionally wrong).
Try narrowing your problem down a little. Does your problem happen when your laptop enters powersave mode, or when it suspends to ram, or when it hibernates? You can separate the three by using the commands pm-powersave, pm-suspend, and pm-hibernate in the terminal. See which command crashes your computer. Then look at the appropriate log.
Offline
Hi all,
After researching a lot, my conclusion is that I think the awake event is not raised after pressing power button in order to resume so no log messages are written to /var/log/pm-suspend.log. If I hibernate it works as I said in a previous post here, for example, If I do a resume after hibernate, these lines are written to pm-suspend.log:
(...)
Sat Dec 31 12:24:30 CET 2011: Awake.
Sat Dec 31 12:24:30 CET 2011: Running hooks for thaw
Running hook /usr/lib/pm-utils/sleep.d/99video thaw hibernate:
/usr/lib/pm-utils/sleep.d/99video thaw hibernate: success.
(...)
After the machine has woken up again, all those hooks are executed in reverse order with the parameter thaw (resume from disk).
But similar lines are not written to log file when resuming after suspend. As I know I think lines like below should be shown in log file if resume event is being caught ok, I mean, after the machine has woken up, all those hooks should be executed in reverse order with the parameter resume (resume from RAM) instead but it is not happing, those lines are not written to log file:
(...)
Awake
Running hooks for resume
Running hook /usr/lib/pm-utils/sleep.d/99video resume suspend:
/usr/lib/pm-utils/sleep.d/99video resume suspend: success.
(...)
...so I would like to know how can I know If resume event is being caught correctly when I press power button in order to resume.
Thx
Last edited by toni (2011-12-31 12:31:09)
Offline
But similar lines are not written to log file when resuming after suspend. As I know I think lines like below should be shown in log file if resume event is being caught ok, I mean, after the machine has woken up, all those hooks should be executed in reverse order with the parameter resume (resume from RAM) instead but it is not happing, those lines are not written to log file:
(...) Awake Running hooks for resume Running hook /usr/lib/pm-utils/sleep.d/99video resume suspend: /usr/lib/pm-utils/sleep.d/99video resume suspend: success. (...)
...so I would like to know how can I know If resume event is being caught correctly when I press power button in order to resume.
Thx
Yes, the above is what your log should look like if you successfully resume from suspend.
Offline
I've got the same problem, although none of the solutions posted in this thread helps.
Asus F5R laptop
uname -r: 3.1.6-1-ARCH
radeon driver
When using pm-suspend, the computer suspends as it's supposed to do. However, when I try to resume it again, the screen is blank. HDD and fans are spinning and all the lights turn back on, but the screen is blank.
pm-suspend.log:
Initial commandline parameters:
Thu Jan 5 00:06:39 CET 2012: Running hooks for suspend.
Running hook /usr/lib/pm-utils/sleep.d/00logging suspend suspend:
Linux localhost 3.1.6-1-ARCH #1 SMP PREEMPT Thu Dec 22 08:52:33 UTC 2011 i686 Intel(R) Core(TM) Duo CPU T2450 @ 2.00GHz GenuineIntel GNU/Linux
Module Size Used by
cryptd 6925 0
aes_i586 6940 1
aes_generic 25702 1 aes_i586
ipv6 247457 10
joydev 7439 0
arc4 1086 2
b43 301586 0
mac80211 196411 1 b43
snd_hda_codec_si3054 2866 1
uas 6440 0
usb_storage 35343 0
snd_hda_codec_realtek 211044 1
cfg80211 142604 2 b43,mac80211
bcma 14319 1 b43
radeon 913985 2
ttm 45685 1 radeon
psmouse 56772 0
ssb 41907 1 b43
snd_hda_intel 19293 0
snd_hda_codec 69829 3 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 4942 1 snd_hda_codec
snd_pcm 60207 3 snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec
drm_kms_helper 22237 1 radeon
ati_agp 4545 0
drm 149266 4 radeon,ttm,drm_kms_helper
agpgart 22287 3 ttm,ati_agp,drm
serio_raw 3390 0
snd_timer 15438 1 snd_pcm
mmc_core 66997 2 b43,ssb
snd 43817 7 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
pcmcia 31534 2 b43,ssb
pcmcia_core 10114 1 pcmcia
atl2 20345 0
soundcore 5018 1 snd
i2c_piix4 7084 0
snd_page_alloc 5869 2 snd_hda_intel,snd_pcm
videodev 77028 0
media 8609 1 videodev
asus_laptop 11994 0
i2c_algo_bit 4423 1 radeon
sp5100_tco 3760 0
sparse_keymap 2660 1 asus_laptop
evdev 7278 7
shpchp 22497 0
pci_hotplug 22072 1 shpchp
processor 21844 2
i2c_core 16816 6 radeon,drm_kms_helper,drm,i2c_piix4,videodev,i2c_algo_bit
rfkill 12470 2 cfg80211,asus_laptop
thermal 6531 0
pcspkr 1375 0
button 3614 0
battery 5053 0
ac 1796 0
video 9716 0
ext4 341420 1
mbcache 4281 1 ext4
jbd2 59633 1 ext4
crc16 1091 1 ext4
sr_mod 13244 0
cdrom 31405 1 sr_mod
sd_mod 26147 3
pata_acpi 2388 0
ahci 17497 2
libahci 16783 1 ahci
pata_atiixp 2920 0
libata 146596 4 pata_acpi,ahci,libahci,pata_atiixp
ohci_hcd 19226 0
ehci_hcd 36074 0
scsi_mod 112473 5 uas,usb_storage,sr_mod,sd_mod,libata
usbcore 120796 5 uas,usb_storage,ohci_hcd,ehci_hcd
total used free shared buffers cached
Mem: 1935344 628024 1307320 0 46344 285940
-/+ buffers/cache: 295740 1639604
Swap: 1048508 0 1048508
/usr/lib/pm-utils/sleep.d/00logging suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/00powersave suspend suspend:
/usr/lib/pm-utils/sleep.d/00powersave suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/01grub suspend suspend:
/usr/lib/pm-utils/sleep.d/01grub suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/11netcfg suspend suspend:
/usr/lib/pm-utils/sleep.d/11netcfg suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend:
/usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/75modules suspend suspend:
/usr/lib/pm-utils/sleep.d/75modules suspend suspend: success.
Running hook /etc/pm/sleep.d/90alsa suspend suspend:
/etc/pm/sleep.d/90alsa suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/90clock suspend suspend:
/usr/lib/pm-utils/sleep.d/90clock suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/91wicd suspend suspend:
/usr/lib/pm-utils/sleep.d/91wicd suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend:
/usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/95led suspend suspend:
/usr/lib/pm-utils/sleep.d/95led suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend:
Kernel modesetting video driver detected, not using quirks.
/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/99video suspend suspend:
kernel.acpi_video_flags = 0
/usr/lib/pm-utils/sleep.d/99video suspend suspend: success.
Thu Jan 5 00:06:47 CET 2012: performing suspend
If you need any more info for helping me, please let me know.
Offline
@snufkin: did you try the hpet=disable option mentioned above?
Offline
I've also noticed a few reports that 3.1.7 kernel fixes this. It appears to have fixed it for me.
Before 3.1.7 I used the hpet=disable option.
Offline
@snufkin: did you try the hpet=disable option mentioned above?
Yup. As I was saying, none of the solutions posted in the thread does it for me.
Offline
@snufkin: eeks! Sorry to have missed that, which is silly as it was the first line. Have you updated to 3.1.7? That just came out and some have said it fixed it for them, though they were also able to use the hpet=disable option... it's still worth a try. I'd say if nothing works, you should definitely post in the linked bug report above or start your own as it sounds like you may have a separate issue.
Offline
I am having same issue (asus mobo, nvidia onboard, desktop) requires hard reset. Just started researching on this and wanted to say 3.1.7 or disabling hpet in bios never solved this for me. ok, I have solved my problem. upon further testing I booted win7 and sleep mode was not working there either. I went into bios/power/ACPI Suspend Type I had S3(STR) selected. Changed it to S1(POS) This solved my problem, except fans stay running. Hope this helps and good luck.
Last edited by travmon (2012-01-07 02:23:22)
foggy shades, bright outside
Offline
I have an ASUS A5E and solved it with:
https://wiki.archlinux.org/index.php/Pm … esume_Hook
João M. S. Silva
Offline
@jmss: a lot of people tried that with no success, including myself. I can report that 3.1.7 also fixed this for me, and the hpet=disable worked on 3.1.6.
Offline
I posted this in the thread that jwhendy linked to above, but for me kernel 3.1.8-1 didn't fix the issue, though disabling HPET in grub does work. Is anyone else experiencing this problem with 3.1.8-1, and also getting the HPET workaround to work for them? If so, perhaps it broke again between 3.1.7 and 3.1.8, or perhaps there's another related problem?
Offline
@mjohnson: I'm starting to think there were always two issues the whole time. One group was fixed with the hpet=disable trick on 3.1.6 and 3.1.7 fixed the issue in general.
The other group has had success with neither of these.
I feel fortunate to be in the first. I no longer have hpet=disable in my kernel line (since 3.1.7), 3.1.7 fixed the issue, and I just pm-suspended and resumed successfully on 3.1.8 (also with hpet=disable still not in my boot options). I hope you find a resolution. Living without suspend is pretty rough, and I was only doing it for about a week.
Offline