You are not logged in.

#1 2015-03-23 14:11:53

Xieshichen
Member
Registered: 2012-01-17
Posts: 12

[SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

The computer starts to supend then hanges with black screen and message:
Freezing of tasks failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0)

The Keyboard and mouse are unresponsive, and I not able to connect using ssh. It requires a reboot.

journalctl -b -1 shows:

Mar 21 10:25:00 HTPC sudo[944]: Xiesh : TTY=unknown ; PWD=/home/Xiesh ; USER=root ; COMMAND=/usr/bin/systemctl suspend
Mar 21 10:25:00 HTPC sudo[944]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mar 21 10:25:00 HTPC systemd[1]: Cannot add dependency job for unit acpid.socket, ignoring: Unit acpid.socket failed to load: No such file or directory.
Mar 21 10:25:00 HTPC systemd[1]: Starting ## lirc irsend sleep hook...
Mar 21 10:25:00 HTPC irsend[946]: lirc_command_run: Sending: SIMULATE 00000000000017df 00 Back/Exit hpg
Mar 21 10:25:00 HTPC irsend[946]: lirc_command_run, state: 0, input: "00000000000017df 00 Back/Exit hpg"
Mar 21 10:25:00 HTPC irsend[946]: lirc_command_run, state: 0, input: "BEGIN"
Mar 21 10:25:00 HTPC irsend[946]: lirc_command_run, state: 1, input: "SIMULATE 00000000000017df 00 Back/Exit hpg"
Mar 21 10:25:00 HTPC irsend[946]: lirc_command_run, state: 2, input: "SUCCESS"
Mar 21 10:25:00 HTPC irsend[946]: lirc_command_run, state: 3, input: "END"
Mar 21 10:25:00 HTPC irsend[946]: lirc_command_run: data:END, status:0
Mar 21 10:25:00 HTPC irsend[948]: lirc_command_run: Sending: SIMULATE 00000000000017c0 00 0 hpg
Mar 21 10:25:00 HTPC irsend[948]: lirc_command_run, state: 0, input: "00000000000017c0 00 0 hpg"
Mar 21 10:25:00 HTPC irsend[948]: lirc_command_run, state: 0, input: "BEGIN"
Mar 21 10:25:00 HTPC irsend[948]: lirc_command_run, state: 1, input: "SIMULATE 00000000000017c0 00 0 hpg"
Mar 21 10:25:00 HTPC irsend[948]: lirc_command_run, state: 2, input: "SUCCESS"
Mar 21 10:25:00 HTPC irsend[948]: lirc_command_run, state: 3, input: "END"
Mar 21 10:25:00 HTPC irsend[948]: lirc_command_run: data:END, status:0
Mar 21 10:25:00 HTPC systemd[1]: Started ## lirc irsend sleep hook.
Mar 21 10:25:00 HTPC systemd[1]: Starting Sleep.
Mar 21 10:25:00 HTPC systemd[1]: Reached target Sleep.
Mar 21 10:25:00 HTPC systemd[1]: Starting Suspend...
Mar 21 10:25:00 HTPC systemd-sleep[950]: Suspending system...
Mar 21 10:25:01 HTPC kernel: PM: Syncing filesystems ... done.
Mar 21 10:25:01 HTPC kernel: PM: Preparing system for mem sleep
Mar 21 10:25:01 HTPC logger[955]: ACPI group/action undefined: jack/lineout / LINEOUT
Mar 21 10:25:01 HTPC logger[957]: ACPI group/action undefined: jack/videoout / VIDEOOUT
Mar 21 10:25:21 HTPC kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Mar 21 10:25:21 HTPC kernel: Freezing remaining freezable tasks ... 
Mar 21 10:25:21 HTPC kernel: Freezing of tasks failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
Mar 21 10:25:21 HTPC kernel: nfsv4.1-svc     D f024be4c     0   435      2 0x00000000
Mar 21 10:25:21 HTPC kernel:  f024bec0 00000046 f023df80 f024be4c f8267e8a 00000000 c16f4680 bf4d94e7
Mar 21 10:25:21 HTPC kernel:  0000039a c16f4680 f5bd7340 000001cd f6034680 f0203200 f023dfb8 00000000
Mar 21 10:25:21 HTPC kernel:  00000000 f8268210 f024be8c 00000286 c17914c0 c17914c0 f024bea4 c10b1833
Mar 21 10:25:21 HTPC kernel: Call Trace:
Mar 21 10:25:21 HTPC kernel:  [<f8267e8a>] ? rpc_release_resources_task+0x2a/0x30 [sunrpc]
Mar 21 10:25:21 HTPC kernel:  [<f8268210>] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
Mar 21 10:25:21 HTPC kernel:  [<c10b1833>] ? lock_timer_base.isra.41+0x23/0x50
Mar 21 10:25:21 HTPC kernel:  [<c1485003>] schedule+0x23/0x60
Mar 21 10:25:21 HTPC kernel:  [<c1487430>] schedule_timeout+0xf0/0x1e0
Mar 21 10:25:21 HTPC kernel:  [<c10b12d0>] ? migrate_timer_list+0xa0/0xa0
Mar 21 10:25:21 HTPC kernel:  [<f993aa99>] nfs41_callback_svc+0x169/0x1a0 [nfsv4]
Mar 21 10:25:21 HTPC kernel:  [<c108bd90>] ? wait_woken+0x70/0x70
Mar 21 10:25:21 HTPC kernel:  [<f993a930>] ? nfs4_callback_svc+0x50/0x50 [nfsv4]
Mar 21 10:25:21 HTPC kernel:  [<c106caf6>] kthread+0xa6/0xc0
Mar 21 10:25:21 HTPC kernel:  [<c1070000>] ? groups_alloc+0xd0/0xd0
Mar 21 10:25:21 HTPC kernel:  [<c1488541>] ret_from_kernel_thread+0x21/0x30
Mar 21 10:25:21 HTPC kernel:  [<c106ca50>] ? kthread_create_on_node+0x130/0x130
Mar 21 10:25:21 HTPC kernel: 
Mar 21 10:25:21 HTPC kernel: Restarting kernel threads ... done.
Mar 21 10:25:21 HTPC kernel: Restarting tasks ... done.
Mar 21 10:25:21 HTPC acpid[327]: client 444[0:0] has disconnected
Mar 21 10:25:21 HTPC acpid[327]: client 444[0:0] has disconnected
Mar 21 10:25:21 HTPC acpid[327]: client connected from 444[0:0]
Mar 21 10:25:21 HTPC acpid[327]: 1 client rule loaded
Mar 21 10:25:21 HTPC acpid[327]: client connected from 444[0:0]
Mar 21 10:25:21 HTPC acpid[327]: 1 client rule loaded
Mar 21 10:25:21 HTPC kernel: PM: Syncing filesystems ... done.
Mar 21 10:25:21 HTPC kernel: PM: Preparing system for standby sleep
Mar 21 10:25:21 HTPC kernel: sound hdaudioC1D1: HDMI: invalid ELD data byte 31
Mar 21 10:25:42 HTPC kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Mar 21 10:25:42 HTPC kernel: Freezing remaining freezable tasks ... 
Mar 21 10:25:42 HTPC kernel: Freezing of tasks failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
Mar 21 10:25:42 HTPC kernel: nfsv4.1-svc     D f024be4c     0   435      2 0x00000000
Mar 21 10:25:42 HTPC kernel:  f024bec0 00000046 f023df80 f024be4c f8267e8a 00000000 c16f4680 bf4d94e7
Mar 21 10:25:42 HTPC kernel:  0000039a c16f4680 f5bd7340 000001cd f6034680 f0203200 f023dfb8 00000000
Mar 21 10:25:42 HTPC kernel:  00000000 f8268210 f024be8c 00000286 c17914c0 c17914c0 f024bea4 c10b1833
Mar 21 10:25:42 HTPC kernel: Call Trace:
Mar 21 10:25:42 HTPC kernel:  [<f8267e8a>] ? rpc_release_resources_task+0x2a/0x30 [sunrpc]
Mar 21 10:25:42 HTPC kernel:  [<f8268210>] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
Mar 21 10:25:42 HTPC kernel:  [<c10b1833>] ? lock_timer_base.isra.41+0x23/0x50
Mar 21 10:25:42 HTPC kernel:  [<c1485003>] schedule+0x23/0x60
Mar 21 10:25:42 HTPC kernel:  [<c1487430>] schedule_timeout+0xf0/0x1e0
Mar 21 10:25:42 HTPC kernel:  [<c10b12d0>] ? migrate_timer_list+0xa0/0xa0
Mar 21 10:25:42 HTPC kernel:  [<f993aa99>] nfs41_callback_svc+0x169/0x1a0 [nfsv4]
Mar 21 10:25:42 HTPC kernel:  [<c108bd90>] ? wait_woken+0x70/0x70
Mar 21 10:25:42 HTPC kernel:  [<f993a930>] ? nfs4_callback_svc+0x50/0x50 [nfsv4]
Mar 21 10:25:42 HTPC kernel:  [<c106caf6>] kthread+0xa6/0xc0
Mar 21 10:25:42 HTPC kernel:  [<c1070000>] ? groups_alloc+0xd0/0xd0
Mar 21 10:25:42 HTPC kernel:  [<c1488541>] ret_from_kernel_thread+0x21/0x30
Mar 21 10:25:42 HTPC kernel:  [<c106ca50>] ? kthread_create_on_node+0x130/0x130
Mar 21 10:25:42 HTPC kernel: 
Mar 21 10:25:42 HTPC kernel: Restarting kernel threads ... done.
Mar 21 10:25:42 HTPC kernel: Restarting tasks ... done.

The irsend commands come from an edited "Combined Suspend/resume" service file described in arch wiki Power_management_with_systemd.
It seems these commands execute, then the system fails, possibly because of the nfs client.

Additionally there is no problem with the nfs server suspending to ram using the updated kernel 3.19.2-1-ARCH.

Downgrade kernel on the client and resume works.
pacman -U linux-3.18.6-1-i686.pkg.tar.xz linux-headers-3.18.6-1-i686.pkg.tar.xz nvidia-340xx-340.76-2-i686.pkg.tar.xz

Last edited by Xieshichen (2015-04-06 18:01:28)

Offline

#2 2015-03-24 16:23:31

bjo
Member
Registered: 2011-09-10
Posts: 80

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

I have the same issue, also with 3.19.2. Downgrading to 3.18.6 helps.

Edit: created a bugreport: https://bugs.archlinux.org/task/44323

Last edited by bjo (2015-03-24 16:48:20)

Offline

#3 2015-03-25 11:05:18

firekage
Member
From: Eastern Europe, Poland
Registered: 2013-06-30
Posts: 617

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

The same thing happens with suspend to disk. Funny thing, noticed this now, when, in fact, i tried to suspend for several days and had to put always password in veracrypt...

Last edited by firekage (2015-03-25 11:06:08)

Offline

#4 2015-03-26 22:42:41

bjo
Member
Registered: 2011-09-10
Posts: 80

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

According to a post in the manjaro bbs, downgrading nfs-utils to 1.3.1-1 helps. In my case, I can suspend with 3.19.2 and mounted nfs now.

Edit: Is it a kernelbug or a bug a bug in nfs-utils?

Last edited by bjo (2015-03-27 13:13:04)

Offline

#5 2015-03-31 22:37:40

DaMadOne
Member
Registered: 2014-07-30
Posts: 15

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

I also *had* this issue. Downgrading nfs-utils to 1.3.1 seems to have fixed it for now.

This ONLY affected my main rig, my laptop has been fine. So lets see what kind of configs we are dealing with here and see if we can find a common denominator.

*Main rig (has the issue)
MSI X99S Mpower
Intel i7-5930k
32gb Corsair Vengeance LPX DDR4 @ 2666
Nvidia GTX 970 x3 (I don't have SLI enabled...)
XFCE

*Lenovo Yoga 2 13 (fine)
Specs http://www.bestbuy.com/site/lenovo-yoga … Id=6071000
Also running XFCE.

Offline

#6 2015-04-02 00:58:01

mrbrich
Member
Registered: 2010-04-24
Posts: 42

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

After a relatively recent system update, I am having a problem suspending to disk on my laptop (Thinkpad t400s, pretty old). It sounds like it could be the same issue, but I'm not sure. Actually, everything seems to work except that the laptop doesn't power off like it used to, the power LED just starts flashing and I have to hold to power button to turn it off.  I will try downgrading nfs-utils as suggested and see if that helps.

Update: turns out I don't even have nfs-utils installed. So probably a different issue.

Last edited by mrbrich (2015-04-02 01:02:06)

Offline

#7 2015-04-02 09:48:32

firekage
Member
From: Eastern Europe, Poland
Registered: 2013-06-30
Posts: 617

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

If you use uswsusp or uswsusp-git add "shutdown method = shutdown" to /etc/suspend.conf.

Offline

#8 2015-04-02 11:43:17

mrbrich
Member
Registered: 2010-04-24
Posts: 42

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

Thanks for the tip. Turns out I don't use uswsusp, but could there be a similar trick for other methods? Funny thing is, I don't know which method I am using. As far as I remember (it's been a while), GNOME automatically mapped the hibernate key on my laptop and it just worked. I thought it might be pm-utils, so I followed the instructions at https://wiki.archlinux.org/index.php/Pm … figuration, and created the file

/etc/pm/config.d/config

HIBERNATE_MODE="shutdown"

This didn't help.

Update:

Looks like it could be systemd related.

journalctl -b -u systemd-hibernate

-- Logs begin at Wed 2014-05-14 13:45:06 EDT, end at Thu 2015-04-02 07:59:35 EDT. --
Apr 01 23:50:18 t400s systemd[1]: Starting Hibernate...
Apr 01 23:50:18 t400s systemd-sleep[2056]: Suspending system...
Apr 02 07:40:27 t400s systemd[1]: Started Hibernate.
Apr 02 07:50:13 t400s systemd[1]: Starting Hibernate...
Apr 02 07:50:13 t400s systemd-sleep[4372]: Suspending system...
Apr 02 07:51:11 t400s systemd[1]: Started Hibernate.

Last edited by mrbrich (2015-04-02 11:48:02)

Offline

#9 2015-04-02 20:41:13

firekage
Member
From: Eastern Europe, Poland
Registered: 2013-06-30
Posts: 617

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

If you don't use pm-utils or uswsusp than you could only use systemd suspend and hiberation (systemctl suspend and systemctl hibernate) but in my case, it won't work at all.

Offline

#10 2015-04-06 00:05:38

dbourgeo
Member
Registered: 2012-11-26
Posts: 30

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

I have the same issue as mrbrich, although my journalctl only has the "Suspending system..." line. lxde used to run hibernate for me (I am assuming), when I called it on their menu. Manually running systemctl hibernate seems to give the usual behaviour, one screen flash, then one big long write to disc. The screen blanks, but the power button and power lights (eg. wifi light and power button light) remain on.

The system seems to suspend fine, and restarts. However, I do have to manually hold down the power button to accomplish this. Systemd/lxde used to turn the power off, now it seems to suspend, shut down, stop the kernel, but the power remains on.

I get no response from SysRq (REISUB), so it does seem the kernel is stopped.

This happens on an old ASUS EEE PC Seashell series, running fully up to date arch, as of yesterday. I update each week, and I think this started a couple of weeks ago, as a minor annoyance for me.

[Later] I should add: that sudo systemctl suspend works fine for me.
[Later] I also don't have nfs-utils. journalctl -b -1 looks fine (I normally see watchdog0 refusing to stop. Maybe that is now an issue. In any case, my hibernate logs all look identical going back months.)

Last edited by dbourgeo (2015-04-06 00:27:35)

Offline

#11 2015-04-06 17:58:41

Xieshichen
Member
Registered: 2012-01-17
Posts: 12

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

I currently am running nfs-utils to 1.3.1-1 while using the latest kernel with success. I have also briefly tested pm-utils which also works on this computer, as I originally was using pm-utils.

My rig circa 2011
ASUS M4A78LT-M
CPU AMD|ATH II X2 250 3.0G AM3 RT
MEM 2 x Kingston KVR1066D3N7/1G
VGA ZOTAC|ZT-20309-10L GT210 512M R
XFCE

The nfs mailing list also has several recent posts with a similar description of this shutdown problem.

I will mark this thread as solved as the above is working. Maybe someone will have the answer for the mrbrich's Think Pad; such a common old laptop.  It should still be able to enter sleep mode.

Offline

#12 2015-04-19 13:28:55

madalu
Member
Registered: 2009-05-05
Posts: 217

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

As an alternative to downgrading to nfs-utils 1.3.1, you can also edit /etc/nfsmount.conf on the client machine to force protocol version 4.0, since this bug affects nfs protocol versions 4.1 and higher.

The relevant line should read:

Defaultvers=4.0

Last edited by madalu (2015-04-19 13:29:51)

Offline

#13 2015-04-21 13:32:30

mrbrich
Member
Registered: 2010-04-24
Posts: 42

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

It looks like my issue has been resolved in a more recent update. System is powering off as expected.

Offline

#14 2015-04-23 23:09:46

Carl Karl
Member
Registered: 2013-06-12
Posts: 231

Re: [SOLVED] Suspend to Ram issue with kernel 3.19.2-1 Update

madalu wrote:

As an alternative to downgrading to nfs-utils 1.3.1, you can also edit /etc/nfsmount.conf on the client machine to force protocol version 4.0, since this bug affects nfs protocol versions 4.1 and higher.

The relevant line should read:

Defaultvers=4.0

Many thanks, works like a charm for me!

PS:
See
https://bugs.archlinux.org/task/44323 and
https://bugzilla.kernel.org/show_bug.cgi?id=95561

Last edited by Carl Karl (2015-04-23 23:19:37)

Offline

Board footer

Powered by FluxBB