You are not logged in.
There was some activity on the kernel bug tracker, nothing major but they're involving other people to look into the problem.
Offline
This is great news! I updated my system and saw that dbus and the kernel had both updates. now when i suspend with
systemctl suspend
all seems to function right now!
I guess it has been fixed!
EDIT: I was too naive T-T the first suspend just gave me false hope now its stuck again.
First i suspended with systemctl, then i closed my laptop lid and opened it again. Systemctl now fails again.
EDIT2: It appears to be a problem related to my specific setup.
systemctl suspend
works flawlessly after several retries.
I suspect acpid has something to do with this but that is a story for another thread for now om just happy i can suspend succesfully.
Last edited by pepi55 (2013-10-15 09:37:59)
Offline
as far as I see in the kernel's bug tracker the problem is still under investigation and there's no indication in the 3.11.5-1 changelog that anything in this regard has been actually done. You may be encountering a placebo effect I'm afraid.
Offline
This is great news! I updated my system and saw that dbus and the kernel had both updates. now when i suspend with
systemctl suspend
all seems to function right now!
I guess it has been fixed!
EDIT: I was too naive T-T the first suspend just gave me false hope now its stuck again.
First i suspended with systemctl, then i closed my laptop lid and opened it again. Systemctl now fails again.
EDIT2: It appears to be a problem related to my specific setup.
systemctl suspend
works flawlessly after several retries.
I suspect acpid has something to do with this but that is a story for another thread for now om just happy i can suspend succesfully.
Well I used pm-suspend a couple of times and suddendly the error appeared again: I open the lid, a console is shown, have to go to X by Ctrl-Alt-F7, can't shutdown anymore (but pm-suspend works). Seems to not matter how I suspend my machine...
Offline
as far as I see in the kernel's bug tracker the problem is still under investigation and there's no indication in the 3.11.5-1 changelog that anything in this regard has been actually done. You may be encountering a placebo effect I'm afraid.
sad but true. I noticed it after a couple of retries. funny thing is that at first it wouldnt work AT ALL. I mean like one suspend ruins everything but now i am able to suspend sometimes without systemd failing on me. Thats why i got the placebo
Offline
Problem still exists with 3.11.6-1
"Conversation enriches the understanding, but solitude is the school of genius"
Offline
uname -r
3.11.6-1-ARCH
Works good.
Offline
uname -r 3.11.6-1-ARCH
Works good.
I won't believe that unless somebody tries it 10 times with zero failures Anyway, there is no info on bugtracker about this being fixed.
English isn't my first language.
Is Arch Linux user called archer? Where are our bows and arrows?
Offline
Problem still exists with 3.11.6-1
Ditto. Failed on the first attempt.
Offline
sero wrote:uname -r 3.11.6-1-ARCH
Works good.
I won't believe that unless somebody tries it 10 times with zero failures Anyway, there is no info on bugtracker about this being fixed.
the last bug report's comment made me wonder if 3.11-6 did revert the problematic code. But it seems it's still not the case. Soon.
Offline
~ $ uname -a
Linux hp2140 3.11.6-1-ARCH #1 SMP PREEMPT Sat Oct 19 00:29:46 CEST 2013 i686 GNU/Linux
~ $ pacman -Qi systemd | grep Version
Version : 208-1
The problem is still there
Offline
I have the same but I am on 64bit! Once I hibernated/suspended for a couple of times, my system would no longer shutdown/suspend/hibernate successfully when executed from the Cinnamon shutdown menu. Running these commands manually (systemctl hibernate/suspend), however, is still working and actually the only way to shutdown my system.
~ $ uname -a
Linux thinkpad 3.11.6-1-ARCH #1 SMP PREEMPT Fri Oct 18 23:22:36 CEST 2013 x86_64 GNU/Linux
~ $ pacman -Qi systemd | grep Version
Version : 208-1
Last edited by orschiro (2013-10-23 15:55:11)
Offline
I have the same but I am on 64bit!
It doesn't seem to be related, as you have x86_64 arch. You wouldn't be able to suspend at all with the bug above (on i686). Have you tried to look in to logs after the unsuccessful suspend?
Last edited by mrinx (2013-10-23 16:16:02)
English isn't my first language.
Is Arch Linux user called archer? Where are our bows and arrows?
Offline
Just updated to the lastest kernel 3.11.6-1-ARCH for i686, and still problem it is.
But the following command can help a little bit:
sync; reboot -f
Also you can change your laptop lid closer event from suspend to ignore, the options can be configured from /etc/systemd/logind.conf#HandleLidSwitch=suspend
HandleLidSwitch=ignore
For details, check here
Last edited by jazzi (2013-10-26 03:37:27)
Offline
Just a word of warning: if you plan to switch to linux-lts until this is fixed (3.10 doesn't have the sleep/resume failure) you might find that your machine won't connect to the network, this is because the interface names are different for the kernels. My wireless card is wls3 on 3.11 and wlp3s0 on 3.10 In order to get ethernet and wireless working I had to change the profiles in /etc/netctl/ to use the new interfaces, and since I'm using netctl-auto and netctl-ifplugd I had to start those with the new interface names as well.
Offline
In linux 3.12 the culprit commit should be reverted. https://bugzilla.kernel.org/show_bug.cgi?id=61781#c27
Offline
I have only problem when trying to resume from hibernate.
Few kernels back hibernate worked ok, but suspend would ONLY work once per boot. I'd need hibernate more as it doesn't take long to hibernate and resume on SSD.
K.i.s.s. <3
Offline
In linux 3.12 the culprit commit should be reverted. https://bugzilla.kernel.org/show_bug.cgi?id=61781#c27
Great! I'm on AUR linux-mainline 3.12-rc7 and the bug still present. Looking foward to 3.12 stable.
Offline
I think it was too late to be included in rc7, but these two commits will be included into the next milestone
https://git.kernel.org/cgit/linux/kerne … df590d881d
https://git.kernel.org/cgit/linux/kerne … 0811c54ab5
Offline
I would like to ask for one thing: i upgraded my system yesterday from kernel 3.9 to newest 3.11 - after this my suspend to disk doesen;t work anymore. It shuts down but when resuming i have only black screen with this sign _ on left upper corner, and system is being frozen, have to resrt it - this is kernel fault? I installed also nvidia drivers, earlier i had 3.9 kernel and nouveau drivers for GTX260 - it worked. Don't know how to fix it. I'm not that experienced, don't want to break it more than it is neccesary, also, i'm affraid that reinstalling the old kernel would bring harm to updated Arch (maybe some of the apps won't work after it).
Last edited by firekage (2013-11-01 13:15:22)
Offline
Your problem has nothing to do with this bug. To me it seems to be an Nvidia driver issue. Try to disable proprietary driver and check if with nouveau, suspend works again.
Offline
Your problem has nothing to do with this bug. To me it seems to be an Nvidia driver issue. Try to disable proprietary driver and check if with nouveau, suspend works again.
I thought that this could by a problem, but as i said, i'm not that experienced, don't know how to remove, in proper way, nvidia driver in order to install again nouveau.
Offline
Nouveau driver is included into the kernel, you have just to get rid of proprietary driver
https://wiki.archlinux.org/index.php/No … DIA_driver
Please, if you need more help with your problem, open a dedicated thread.
Last edited by 4javier (2013-11-01 13:41:28)
Offline
Nouveau driver is included into the kernel, you have just to get rid of proprietary driver
https://wiki.archlinux.org/index.php/No … DIA_driverPlease, if you need more help with your problem, open a dedicated thread.
Thank you, but it is not nvidia driver related problem. I searched how to remove it, how to restore nouveau and on nouveau it it the same result. After wake up from suspent to ram, black screen. So it it not nvidia fault, rather kernel.
Last edited by firekage (2013-11-01 13:45:24)
Offline
Thank you, but it is not nvidia driver related problem. I searched how to remove it, how to restore nouveau and on nouveau it it the same result. After wake up from suspent to ram, black screen. So it it not nvidia fault, rather kernel.
It could be a bug in kernel, or some problem with your hardware. Some archers had similar issue.
https://bbs.archlinux.org/viewtopic.php?id=157089
You could try different kernel version, maybe lts, and see if it works for you. Anyway, we are off topic here, so if you need more help, start your own thread
English isn't my first language.
Is Arch Linux user called archer? Where are our bows and arrows?
Offline