Bug#782290: /lib/systemd/systemd-sleep: On suspend, "Freezing of tasks failed", systemd-sleep "blocked for more than 120 seconds"

[Michael Biebl]

Hi,

Am 10.04.2015 um 03:59 schrieb nandhp:
> At 17:45 today I put my laptop (MacbookAir5,2) into suspend by closing
> the lid, and then I put it in my bag. When I removed it at 19:55, I
> noticed the fan was running. I opened the lid, and the laptop appeared
> to enter suspend almost immediately. When I tapped on the keyboard to
> resume it, I was surprised to see no obvious evidence the system had
> been running while in my bag -- for example, my thermal logger
> recorded no data between 17:45 and 19:55. However, I found some
> suspicicous messages in the kernel log:
> 
>     Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
>     freeze, wq_busy=0)

That message is not coming from the systemd-sleep task.

> and:
> 
>     INFO: task systemd-sleep:12830 blocked for more than 120 seconds.
> 
> I have attached excerpts from daemon.log and kern.log, which include
> stack traces for these messages.
> 
> This is the first time I have experienced this issue. However, I have
> previously encountered issues with the system not entering suspend
> correctly: after closing the lid it enters suspend, but then resumes a
> few seconds later (this can be identified by the Apple logo lighting
> up again). This behavior is different, because the system is fully
> functional when it resumes and it does not try to reenter suspend when
> I open the lid. This problem occurs with some regularity, but
> intermittently, and has no characteristic messages in the error log.
> 
> Note that I have written two custom scripts that systemd runs on
> resume from suspend:
> 
>   - nandhp-wl-rescan is run on resume to cause the wireless adapter to
>     agressively rescan for Wi-Fi networks when resuming from suspend
>     (this improves the time to reconnection).
> 
>   - nandhp-lid-check tries to work around the previously experienced
>     suspend issue by checking if the lid of the computer is closed and
>     tries to return to suspend if it is (unless the script has already
>     triggered recently). This script was installed about a month ago,
>     and the problem has mysteriously failed to occur ever since (the
>     script has not activated).
> 
> Neither of the scripts performed any interesting actions during this
> event because the Wi-Fi was disabled and the lid open at the time that
> they ran (see daemon.log). However, I'd be happy to provide more
> details about these scripts if desired.
> 
> System uptime is 44 days, but systemd was upgraded from 215-12 to
> 215-14 yesterday.
> 

Is this problem reproducible, can you trigger it again, even after a reboot?

To me, this looks more like a kernel issue then a systemd-sleep issue.
systemd-sleep basically just does 'echo "mem" > /sys/power/state'.

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150410/b4876c8a/attachment-0002.sig>