Hide Forgot
Created attachment 480956 [details] pm-utils suspend log for the failed suspend Description of problem: Can not suspend Version-Release number of selected component (if applicable): $ uname -a Linux kravica.no-ip.org 2.6.34.7-66.fc13.i686 #1 SMP Wed Dec 15 07:40:25 UTC 2010 i686 i686 i386 GNU/Linux root@kravica:~ $ pm-utils-1.2.6.1-1.fc13.i686 How reproducible: Always. Steps to Reproduce: 1. Try to suspend the system. Actual results: The system tries to go asleep but wakes up after some 30 seconds. Expected results: The system goes to sleep. Additional info: Suspicious line in pm-suspend.log: /usr/lib/pm-utils/pm-functions: line 275: echo: write error: Device or resource busy See attached log for details.
From the log it seems that the hibernate was reject by the kernel. Is there any more info in syslog? This mostly mean: - there is something wrong with you swap, the kernel cannot write there, - the kernel cannot free the memory, there is a lot of mlocked memory, - there are present HW devices / modules that does not support the suspend. Please provide output of: # pm-utils-bugreport-info.sh My questions: Did it work before e.g. with older release of Fedora? Does it fail each time, e.g. no successful run so far? Could you try with nouveau driver instead of nvidia? May be newer kernel can help, could you also try with F14 live CD?
Suspend works intermittently. It used to work every time, used to work with earlier Fedoras. I don't use nouveau as it is more trouble than it is worth. Output of the command below. filip@kravica:~ $ sudo pm-utils-bugreport-info.sh [sudo] password for filip: SUSPEND LOG Initial commandline parameters: Fri Feb 25 01:13:29 PST 2011: Running hooks for suspend. /usr/lib/pm-utils/sleep.d/00auto-quirk suspend suspend: Adding quirks from HAL: --quirk-vbe-post success. /usr/lib/pm-utils/sleep.d/00logging suspend suspend: Linux kravica.no-ip.org 2.6.34.7-66.fc13.i686 #1 SMP Wed Dec 15 07:40:25 UTC 2010 i686 i686 i386 GNU/Linux Module Size Used by fuse 47899 2 rfcomm 53971 8 sco 13585 2 bridge 51954 0 stp 1403 1 bridge llc 3677 2 bridge,stp bnep 11937 2 l2cap 38986 16 rfcomm,bnep autofs4 17788 3 coretemp 4402 0 cpufreq_ondemand 6964 2 acpi_cpufreq 6601 1 ipv6 221598 30 i8k 4320 0 uinput 5287 0 snd_hda_codec_idt 45888 1 arc4 1077 2 ecb 1567 2 iwlagn 126854 0 snd_hda_intel 19875 2 iwlcore 192650 1 iwlagn nvidia 9367684 36 snd_hda_codec 70924 2 snd_hda_codec_idt,snd_hda_intel snd_hwdep 4860 1 snd_hda_codec snd_seq 42775 0 snd_seq_device 5035 1 snd_seq snd_pcm 62005 2 snd_hda_intel,snd_hda_codec snd_timer 15391 2 snd_seq,snd_pcm mac80211 181939 2 iwlagn,iwlcore snd 46603 12 snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer soundcore 4934 1 snd snd_page_alloc 6033 2 snd_hda_intel,snd_pcm uvcvideo 47316 0 videodev 29870 1 uvcvideo cfg80211 110977 3 iwlagn,iwlcore,mac80211 v4l1_compat 11354 2 uvcvideo,videodev iTCO_wdt 8928 0 iTCO_vendor_support 2027 1 iTCO_wdt btusb 12332 2 i2c_i801 8402 0 i2c_core 20553 3 nvidia,videodev,i2c_i801 bluetooth 73745 9 rfcomm,sco,bnep,l2cap,btusb dell_wmi 2555 0 dell_laptop 5370 0 sky2 36687 0 joydev 7435 0 wmi 5624 1 dell_wmi rfkill 13433 4 cfg80211,bluetooth,dell_laptop dcdbas 6504 1 dell_laptop microcode 10241 0 sdhci_pci 6003 0 sdhci 15131 1 sdhci_pci firewire_ohci 17108 0 mmc_core 51722 1 sdhci firewire_core 37499 1 firewire_ohci crc_itu_t 1227 1 firewire_core usb_storage 34964 0 video 17713 0 output 1605 1 video total used free shared buffers cached Mem: 2060720 1081428 979292 0 35388 811976 -/+ buffers/cache: 234064 1826656 Swap: 8016392 132836 7883556 success. /usr/lib/pm-utils/sleep.d/00powersave suspend suspend: success. /usr/lib/pm-utils/sleep.d/01grub suspend suspend: not applicable. /usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend: not applicable. /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: success. /usr/lib/pm-utils/sleep.d/56atd suspend suspend: success. /usr/lib/pm-utils/sleep.d/56dhclient suspend suspend: success. /usr/lib/pm-utils/sleep.d/75modules suspend suspend: not applicable. /usr/lib/pm-utils/sleep.d/90clock suspend suspend: not applicable. /usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend: success. /usr/lib/pm-utils/sleep.d/95led suspend suspend: not applicable. /usr/lib/pm-utils/sleep.d/95packagekit suspend suspend: success. /usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend suspend: success. /usr/lib/pm-utils/sleep.d/99hd-apm-restore.hook suspend suspend: HDIO_DRIVE_CMD(identify) failed: Invalid exchange Advanced Power Management not supported by device sdb. saving level 128 for device sda success. /usr/lib/pm-utils/sleep.d/99video suspend suspend: kernel.acpi_video_flags = 0 success. Fri Feb 25 01:13:29 PST 2011: performing suspend Fri Feb 25 21:04:30 PST 2011: Awake. Fri Feb 25 21:04:30 PST 2011: Running hooks for resume /usr/lib/pm-utils/sleep.d/99video resume suspend: success. /usr/lib/pm-utils/sleep.d/99hd-apm-restore.hook resume suspend: restoring level 128 for device sda /dev/sda: setting Advanced Power Management level to 0x80 (128) APM_level = 128 success. /usr/lib/pm-utils/sleep.d/98smart-kernel-video resume suspend: success. /usr/lib/pm-utils/sleep.d/95packagekit resume suspend: method return sender=:1.260 -> dest=:1.288 reply_serial=2 success. /usr/lib/pm-utils/sleep.d/95led resume suspend: not applicable. /usr/lib/pm-utils/sleep.d/94cpufreq resume suspend: success. /usr/lib/pm-utils/sleep.d/90clock resume suspend: not applicable. /usr/lib/pm-utils/sleep.d/75modules resume suspend: success. /usr/lib/pm-utils/sleep.d/56dhclient resume suspend: success. /usr/lib/pm-utils/sleep.d/56atd resume suspend: Stopping atd: [ OK ] [ OK ] atd: [ OK ] success. /usr/lib/pm-utils/sleep.d/55NetworkManager resume suspend: success. /usr/lib/pm-utils/sleep.d/49bluetooth resume suspend: not applicable. /usr/lib/pm-utils/sleep.d/01grub resume suspend: not applicable. /usr/lib/pm-utils/sleep.d/00powersave resume suspend: success. /usr/lib/pm-utils/sleep.d/00logging resume suspend: success. /usr/lib/pm-utils/sleep.d/00auto-quirk resume suspend: success. Fri Feb 25 21:04:31 PST 2011: Finished. ====== SYS POWER total 0 -rw-r--r-- 1 root root 4096 Feb 25 21:51 disk -rw-r--r-- 1 root root 4096 Feb 25 21:51 image_size -rw-r--r-- 1 root root 4096 Feb 25 21:51 pm_async -rw-r--r-- 1 root root 4096 Feb 25 21:51 pm_test -rw-r--r-- 1 root root 4096 Feb 25 21:51 pm_trace -rw-r--r-- 1 root root 4096 Feb 25 21:51 resume -rw-r--r-- 1 root root 4096 Feb 25 01:13 state ====== SYS POWER STATE mem disk ====== SYS POWER DISK [platform] test testproc shutdown reboot ====== HAL INFO power_management.quirk.vbe_post = true (bool) system.firmware.version = 'A12' (string) system.hardware.product = 'XPS M1530' (string) system.hardware.vendor = 'Dell Inc.' (string) system.hardware.version = '' (string) ====== ETC PM /etc/pm: total 24 drwxr-xr-x. 2 root root 4096 Oct 1 2009 config.d drwxr-xr-x. 2 root root 4096 Oct 1 2009 power.d drwxr-xr-x. 2 root root 4096 Oct 1 2009 sleep.d /etc/pm/config.d: total 0 /etc/pm/power.d: total 0 /etc/pm/sleep.d: total 0 DIR /etc/pm/config.d ====== DIR /etc/pm/power.d ====== DIR /etc/pm/sleep.d ====== UNAME Linux kravica.no-ip.org 2.6.34.7-66.fc13.i686 #1 SMP Wed Dec 15 07:40:25 UTC 2010 i686 i686 i386 GNU/Linux ====== RPM kernel-2.6.34.7-61.fc13 kernel-2.6.34.7-63.fc13 kernel-2.6.34.7-66.fc13 pm-utils-1.2.6.1-1.fc13 hal-0.5.14-3.fc13 hal-info-20090716-3.fc12 gnome-power-manager-2.30.1-1.fc13 vbetool-1.2.2-1.fc12 radeontool-1.5-6.fc12 hdparm-9.27-1.fc13 ====== FEDORA RELEASE Fedora release 13 (Goddard) ====== filip@kravica:~ $
Thanks for info. According to comparison of the two provided logs it seems, that it fails if there is not enough free memory. AFAIK the kernel needs half of memory free to be able to hibernate. If there is not enough memory free it tries to swap. If there is a lot of memory mlocked (non-swappable) the hibernation can fail. Please check the "top" for processes hogging the resident memory. However, it seems not to be the pm-utils fault. Please try to bypass the pm-utils by hibernating through the sys interface: # echo disk > /sys/power/state If it still fails and there is no process hogging your memory, this bug should be reassigned to kernel.
(In reply to comment #3) > Thanks for info. According to comparison of the two provided logs it seems, > that it fails if there is not enough free memory. OK, that seems to make sense, though not being able to suspend makes me sad. :) > AFAIK the kernel needs half of memory free to be able to hibernate. If there is > not enough memory free it tries to swap. If there is a lot of memory mlocked > (non-swappable) the hibernation can fail. Please check the "top" for processes > hogging the resident memory. Understood; I do however miss an UI element that will inform the user that this has happened. The current state of affairs is that a failed suspend will just bring the screen up again, leaving the user to wonder what had happened. > However, it seems not to be the pm-utils fault. Please try to bypass the That may be, but pm-utils should be responsible for reporting the failed suspend attempt. > pm-utils by hibernating through the sys interface: > # echo disk > /sys/power/state > > If it still fails and there is no process hogging your memory, this bug should > be reassigned to kernel. I'll check this out. I noticed that suspend doesn't happen if I mount a lot of drives via fuse. If I understand correctly you want me to execute the above command from the command line and see if that suspends the machine? Is that right? Otherwise, I don't see how I could circumvent pm-utils. What I do is press the 'suspend' button combo on my laptop and have no further explicit control over it. The suspend process on the laptop is fairly complex so it seems difficult to do right by hand. f
> If I understand correctly you want me to execute the above command from the > command line and see if that suspends the machine? Is that right? > Correct. > Otherwise, I don't see how I could circumvent pm-utils. What I do is press the > 'suspend' button combo on my laptop and have no further explicit control over > it. The suspend process on the laptop is fairly complex so it seems difficult > to do right by hand. > It is a bit complicated under-hood. AFAIK the upowerd calls the pm-hibernate which runs all the hooks and then requests the hibernation via the above mentioned kernel sysfs interface and the most dirty stuff is then performed by kernel. >I do however miss an UI element that will inform the user that >this has happened. The current state of affairs is that a failed suspend will >just bring the screen up again, leaving the user to wonder what had happened. > I agree. From F14 and later such errors are handled by pm-utils and catched by upowerd and AFAIK further propagated through dbus. But there is still no UI dialog or user notification. Currently this is out of my scope, but I added this request to the PM SIG todo list, so at least it is tracked from now: http://fedoraproject.org/wiki/SIGs/PowerManagement/Todos
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.