You are not logged in.

#1 2015-04-08 13:11:12

Dun
Member
Registered: 2014-12-28
Posts: 98

[SOLVED]systemctl suspend

So I like to use the suspend on my PC - a tower PC (I used running Windows a half year ago, there wasn't such a problem with suspending). I like to use it but it actually works infrequent. I don't know where the cause of the problem is as I don't know where to look at all. 
Sometimes, when I'm executing "systemctl suspend" the displays just turn black, the fans still spinning and I can't use any peripherals anymore. I have to do a hardware restart to continue.
Sometimes the PC turns everything off, like intended, but when I try to resume the displays will only show this line:

[   410.974110] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed

The strange thing is, that if I had e.g. a running YouTube-video with sound, the sound will continue after resuming but I don't have any way to control to PC. The playing video while suspending can't be the main reason behind this, because it often happens, that it will resume as intended even with running video.
It happens to me so randomly, every time I execute it I don't know if it works now or not. I just don't know what to do and where to search for.

Last edited by Dun (2015-05-14 21:28:01)

Offline

#2 2015-04-08 13:43:48

Xabre
Member
From: Serbia
Registered: 2009-03-19
Posts: 752

Re: [SOLVED]systemctl suspend

I heard of it being mentioned as a bug in radeon driver. Can even confirm it on my laptop with intel+radeon graphics: when discrete radeon is switched off, and only intel is being used, suspend and hibernate work just fine. As for fixing it, I can't help much, but hope it gives you enough clues where to start looking.

Offline

#3 2015-04-26 20:20:32

Dun
Member
Registered: 2014-12-28
Posts: 98

Re: [SOLVED]systemctl suspend

So I tried to fix this again. I deactivated dpm, turned msi off:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.dpm=0 pci=nomsi resume=/dev/sda2/"

And still sometimes "systemctl suspend" doesn't suspend or doesn't resume. I think it got a little bit better, sometimes I had to resume 7 times in a row to reproduce this issue. It also doesn't displays the error, so dpm wasn't the origin of this problem.

journalctl -b -r after successful suspend + resume

Apr 26 21:37:10 Arch64 kernel: parport_pc 00:04: disabled
Apr 26 21:37:10 Arch64 kernel: sd 7:0:0:0: [sdb] Stopping disk
Apr 26 21:37:10 Arch64 kernel: sd 9:0:0:0: [sdc] Stopping disk
Apr 26 21:37:10 Arch64 kernel: sd 6:0:0:0: [sda] Synchronizing SCSI cache
Apr 26 21:37:10 Arch64 kernel: sd 9:0:0:0: [sdc] Synchronizing SCSI cache
Apr 26 21:37:10 Arch64 kernel: sd 7:0:0:0: [sdb] Synchronizing SCSI cache
Apr 26 21:37:10 Arch64 kernel: Suspending console(s) (use no_console_suspend to debug)
Apr 26 21:37:10 Arch64 kernel: PM: Entering mem sleep
Apr 26 21:37:10 Arch64 kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Apr 26 21:37:10 Arch64 kernel: Freezing user space processes ... (elapsed 0.002 seconds) done.
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] protocol-native.c: Connection died.
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] client.c: Freed 129 "ALSA plug-in [amixer]"
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] module-udev-detect.c: Resuming all sinks and sources of card alsa_card.pci-0000_00_14.2.
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] module-udev-detect.c: /dev/snd/controlC1 is accessible: yes
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] module-udev-detect.c: Resuming all sinks and sources of card alsa_card.pci-0000_01_00.1.
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
Apr 26 21:37:00 Arch64 kernel: PM: Preparing system for mem sleep
Apr 26 21:37:00 Arch64 kernel: PM: Syncing filesystems ... done.
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] module-augment-properties.c: Looking for .desktop file for amixer
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] protocol-native.c: Disabling srbchannel, reason: Must be enabled by module parameter
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] protocol-native.c: Negotiated SHM: yes
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] protocol-native.c: SHM possible: yes
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] protocol-native.c: Got credentials: uid=1000 gid=100 success=1
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] protocol-native.c: Protocol version: remote 30, local 30
Apr 26 21:37:00 Arch64 pulseaudio[714]: [pulseaudio] client.c: Created 129 "Native client (UNIX socket client)"
Apr 26 21:37:00 Arch64 systemd-sleep[1374]: Suspending system...
Apr 26 21:37:00 Arch64 polkitd[474]: Unregistered Authentication Agent for unix-process:1370:17559 (system bus name :1.29, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale 
Apr 26 21:37:00 Arch64 systemd[1]: Starting Suspend...
Apr 26 21:37:00 Arch64 systemd[1]: Starting Sleep.
Apr 26 21:37:00 Arch64 systemd[1]: Reached target Sleep.

journalctl -b -1 -r suspension stuck or resume with black screen

Apr 26 21:58:07 Arch64 systemd-sleep[1143]: Suspending system...
Apr 26 21:58:07 Arch64 polkitd[478]: Unregistered Authentication Agent for unix-process:1139:11749 (system bus name :1.30, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Apr 26 21:58:07 Arch64 systemd[1]: Starting Suspend...
Apr 26 21:58:07 Arch64 systemd[1]: Starting Sleep.
Apr 26 21:58:07 Arch64 systemd[1]: Reached target Sleep.
Apr 26 21:58:07 Arch64 polkitd[478]: Registered Authentication Agent for unix-process:1139:11749 (system bus name :1.30 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)

It seems that it stucks there:
systemd-sleep[1374]: Suspending system...

I have no idea where to go from now sad

Last edited by Dun (2015-04-26 20:22:55)

Offline

#4 2015-05-14 21:27:45

Dun
Member
Registered: 2014-12-28
Posts: 98

Re: [SOLVED]systemctl suspend

Ok it seems that xf86-video-ati was the problem. The system is now running with the proprietary drivers (catalyst) and suspension works flawlessly.

Offline

Board footer

Powered by FluxBB