#1130605 linux-image-6.19.6+deb14-amd64: hangs with kernel call trace when trying to sleep

Package:
src:linux
Source:
src:linux
Submitter:
Sanjoy Mahajan
Date:
2026-03-14 10:21:01 UTC
Severity:
normal
Tags:
#1130605#5
Date:
2026-03-13 15:18:42 UTC
From:
To:
Since running the 6.19 kernel package after a reboot (the previous boot
was using 6.16, I think), putting the laptop to sleep would hang and
eventually produce a kernel call trace.  In the syslog, the first sign
of the error is

  kernel: INFO: task kworker/u16:0:13041 blocked for more than 120 seconds.
  kernel:       Tainted: G          I         6.19.6+deb14-amd64 #1 Debian 6.19.6-1

(Syslog extract attached.)

It never unblocks, and I have to reboot.  Also the X screen is blank
(with backlight), I guess because the laptop has halfway gone to sleep
and is stuck there.

I tried the 6.18 kernel package, which produced a similar problem:
Putting the laptop to sleep also would hang, but in that case the syslog
lists systemd-sleep as the blocked task.

Until rebooting, which booted the 6.19 kernel, I have not had this
problem.  The previous working kernel was 6.16, I think.  However, that
boot had such a long uptime (months) that none of my rotated
/var/log/syslog.n files show the boot (so I am not sure of the kernel
version).

#1130605#12
Date:
2026-03-14 07:21:21 UTC
From:
To:
I've done more testing, and the problem now happens with all the kernel
packages that I've tried:

linux-image-6.12.63+deb13-amd64
linux-image-6.17.11+deb14-amd64
linux-image-6.18.5+deb14-amd64
linux-image-6.19.6+deb14-amd64

So, the problem is probably due to an upgrade to another package.  One
guess is systemd, because many of the error messages say that
the hung process is systemd-sleep .

#1130605#17
Date:
2026-03-14 10:19:41 UTC
From:
To:
The following solution, or workaround, works for me (found on
<https://bbs.archlinux.org/viewtopic.php?id=296954>).  I made a file
/etc/systemd/system/systemd-suspend.service.d/override.conf containing
these two lines:

[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"

(I did so via "systemctl edit systemd-suspend.service")

Now suspend works reliably.  Apparently this new behavior, of freezing
the user slice, was introduced in systemd 256, so I must have been
running an earlier version for a while.  Anyway, now I am running
systemd 260~rc4-1 (kernel 6.19.6+deb14-amd64).

This solution was proposed first to solve suspend problems with properietary
NVIDIA drivers.  However, I had similar suspend problems without any
proprietary drivers (the laptop uses intel graphics), and the same
solution worked for me as for the NVIDIA users.