running pm-suspend sometimes does not work. sometimes as in works the 1st time (always), then wakes up ok, then either works or not. in those cases, i'm killing it with ctrl+c it used to work reliably before (kernel 2.6.37?) $ uname -a Linux igor 2.6.38.2-desktop-1.mga #1 SMP Mon Mar 28 11:42:53 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux here are some logs from /var/log/messages, i don't know if they are related or not: Mar 28 14:08:48 igor kernel: rtl8192_hw_sleep_down(): RF Change in progress! Mar 28 14:09:02 igor kernel: rtl8192_hw_sleep_down(): RF Change in progress! Mar 28 14:09:17 igor kernel: rtl8192_hw_sleep_down(): RF Change in progress! Mar 28 14:09:20 igor kernel: LPS leave: notify AP we are awaked ++++++++++ SendNullFunctionData Mar 28 14:09:43 igor kernel: ata2.00: configured for UDMA/100 Mar 28 14:09:43 igor kernel: ata2: EH complete Mar 28 14:09:43 igor kernel: EXT4-fs (sda1): re-mounted. Opts: commit=0 Mar 28 14:09:44 igor kernel: EXT4-fs (sda6): re-mounted. Opts: commit=0 Mar 28 14:09:44 igor kernel: ===>rtllib_wx_set_power(): power disable Mar 28 14:09:44 igor kernel: =====>rtllib_sta_ps(): no need to ps,wake up!! ieee->ps is 0,ieee->iw_mode is 2,ieee->state is 5 Mar 28 14:09:44 igor kernel: =====>rtllib_sta_ps(): no need to ps,wake up!! ieee->ps is 0,ieee->iw_mode is 2,ieee->state is 5 Mar 28 14:09:44 igor kernel: =====>rtllib_sta_ps(): no need to ps,wake up!! ieee->ps is 0,ieee->iw_mode is 2,ieee->state is 5 Mar 28 14:09:44 igor kernel: =====>rtllib_sta_ps(): no need to ps,wake up!! ieee->ps is 0,ieee->iw_mode is 2,ieee->state is 5 Mar 28 14:09:44 igor ifplugd(eth0)[12644]: Exiting. Mar 28 14:09:45 igor kernel: rtl8192_hw_sleep_down(): RF Change in progress! Reproducible: Steps to Reproduce:
CC: (none) => tmb
Please attach dmesg output in both working and not working cases
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaudSource RPM: kernel? => kernel
it's much less frequent nowadays, maybe due to new kernel? previously, at report time (2.6.38.2-desktop-1.mga), i could have 1 suspend ok and the later ones were not working, need reboot. now (2.6.38.4-desktop-1.mga), i had no problem suspending. i propose to leave the bug open just in case.
2.6.38.6-desktop-1.mga and 2.6.38.7-desktop-1.mga trigger the problem.
Created attachment 500 [details] dmesg output when non-working.
hmm, in fact it seemed to be related to a network script that took too much time. keeping open just in case.
it was definitely the case, closing bug.
Status: NEW => RESOLVEDResolution: (none) => INVALID