Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64

[Achille L]

Hello,

I suppose I have identified that the issue was related to the
activation of the config parameter CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
in Debian Kernel 5.10.0-8-amd64 from Debian Bullseye 11.0 (it was
disabled in the Debian kernel 4.19.0 from Debian Buster 10.11). This
parameter was activated in Debian with linux (5.8.3-1~exp1)
experimental on Mon, 24 Aug 2020 01:23:22 +0100 (see
https://metadata.ftp-master.debian.org/changelogs//main/l/linux/linux_5.10.46-4_changelog)

I discovered it bisecting (by hand) the diff of a working kernel
config file for Debian Kernel 5.10.0-8-amd64 (generated by me from
Debian kernel source code with make makeoldconfig using as template
the Debian kernel config-4.19.0-11-amd64) and the default kernel
config file from stock Debian Kernel 5.10.0-8-amd64 (see attachment);
the "hunk" of the diff that I detected was the number 151:

--- linux-source-5.10/.config 2021-08-13 17:24:22.386243765 +0200
+++ /boot/config-5.10.46 2021-08-01 10:27:12.000000000 +0200
@@ -9063,7 +9063,7 @@
# Memory initialization
#
CONFIG_INIT_STACK_NONE=y
-CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
+# CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set
# CONFIG_INIT_ON_FREE_DEFAULT_ON is not set
# end of Memory initialization
# end of Kernel hardening options

To verify this finding, I configured grub to start the kernel with the
parameter init_on_alloc=0:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="no_console_suspend nouveau.debug=warn
init_on_alloc=0"
[...missing...]

After that, of course, I update the grub with kernel boot
configuration with the command:

update-grub2

The test with the stock Debian Bullseye (11.0) Kernel 5.10.0-8-amd64
was successful: I'm repeatedly able to suspend to ram and suspend to
disk with parameter init_on_alloc set to 0 with the same kernel that
freeze with init_on_alloc set to 1. I haven't deepened yet in kernel
source code, but in theory the kernel feature activated by this
parameter [1] (erase area of newly allocated memory) could have side
effects with the buffer handling/eviction of memory from video memory
to system memory during suspend to ram or suspend to disk.

You could give it a try, even if your GPU is two year younger then
mine (but they use the same nv50 kernel drm module).

Let me know.

[1] https://patchwork.kernel.org/project/linux-security-module/patch/20190626121943....@google.com/

[Jens Kaupp]

Hello,

I have the same suspend issue with newer Kernels.

System:
Thinkpad T410

Intel i5 M 

So I'm reluctant to upgrade my system to Debian 11.

<<... I configured grub to start the kernel with the parameter init_on_alloc=0 >>

This method worked on my system (tryed with EndevourOS).

Thanks AchilleL.

Now I have to investigate what the purpose of init_on_alloc=0 is ;-)

Cheers!

Jens

[Computer Enthusiastic]

Hello,

I've been successfully used an experimental "work in progress" patch
with the kernel version 5.10.113 since last 25 may (see
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/547#note_1438950)
.

I suspended and hibernated the system (Debian GNU/Linux 11.3 with the
aforementioned patch) many times without any issue :
# journalctl -S 2022-05-25 --no-pager | grep -e "PM: suspend
entry\|hibernation: hibernation entry"
May 25 08:39:48 debian kernel: PM: hibernation: hibernation entry
May 26 08:05:44 debian kernel: PM: hibernation: hibernation entry
May 28 12:28:50 debian kernel: PM: suspend entry (deep)
May 28 12:39:52 debian kernel: PM: suspend entry (deep)
May 28 13:34:55 debian kernel: PM: hibernation: hibernation entry
May 28 18:17:35 debian kernel: PM: hibernation: hibernation entry
May 30 08:56:31 debian kernel: PM: hibernation: hibernation entry
Jun 01 22:54:45 debian kernel: PM: hibernation: hibernation entry
Jun 02 17:44:35 debian kernel: PM: suspend entry (deep)
Jun 02 23:49:38 debian kernel: PM: hibernation: hibernation entry
Jun 04 10:54:04 debian kernel: PM: hibernation: hibernation entry
Jun 05 17:34:17 debian kernel: PM: hibernation: hibernation entry
Jun 06 08:18:21 debian kernel: PM: hibernation: hibernation entry
Jun 06 18:11:40 debian kernel: PM: suspend entry (deep)
Jun 06 19:27:39 debian kernel: PM: suspend entry (deep)
Jun 06 23:02:24 debian kernel: PM: hibernation: hibernation entry
Jun 08 08:53:02 debian kernel: PM: hibernation: hibernation entry
Jun 08 08:58:41 debian kernel: PM: suspend entry (deep)
Jun 08 08:59:32 debian kernel: PM: hibernation: hibernation entry
Jun 09 01:11:56 debian kernel: PM: hibernation: hibernation entry
Jun 09 21:08:22 debian kernel: PM: hibernation: hibernation entry
Jun 11 09:00:25 debian kernel: PM: hibernation: hibernation entry
Jun 21 23:35:30 debian kernel: PM: hibernation: hibernation entry

I've successful tested the patch at least one time with upstream
kernels version 5.10.117, 5.16.14 and 5.17.9, too.

Using this patch, the workaround cited in previous messages is not
required anymore with my hardware.
$ inxi -G
Graphics: Device-1: NVIDIA G96CM [GeForce 9600M GT] driver: nouveau v: kernel
Display: x11 server: X.Org 1.20.11 driver: loaded:
modesetting unloaded: fbdev,vesa resolution: 1280x800~60Hz
OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5
The root cause of the issue is probably the cause, at least another,
of other different issue (see
https://gitlab.freedesktop.org/drm/nouveau/-/issues/156#note_1383820 )

It probably be useful to test the patch with different affected nvidia
graphic cards.

Hope that helps.

[Computer Enthusiastic]

Hello,

To whom it may interests, I've successful tested the patch (see
previous message [0]) with Debian
kernels version 5.10.0-16-amd64 [1] from bullseye-security and,
5.18.0-0 [2] from bullseye-backports

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#64
[1] http://security.debian.org/debian-security/pool/main/l/linux/linux-image-5.10.0-16-amd64-unsigned_5.10.127-2_amd64.deb
[2] https://packages.debian.org/bullseye-backports/linux-image-amd64
.

[rudu]

Hi,

Thanks to Computer Enthusiastic for reporting this bug.
I've been hit too for quite a long time so I had to stick to an ancient
kernel to keep the hibernation ability functional.
$ cat /etc/debian_version
bookworm/sid

$ dpkg -l linux-image-* | grep ^ii
ii  linux-image-5.10.0-13-amd64          5.10.106-1   amd64 Linux 5.10
for 64-bit PCs (signed)
ii  linux-image-5.10.0-16-amd64          5.10.127-1   amd64 Linux 5.10
for 64-bit PCs (signed)
ii  linux-image-5.18.0-4-amd64           5.18.16-1    amd64 Linux 5.18
for 64-bit PCs (signed)
ii  linux-image-5.7.0-2-amd64            5.7.10-1     amd64 Linux 5.7
for 64-bit PCs (signed)
ii  linux-image-5.7.0-3-amd64            5.7.17-1     amd64 Linux 5.7
for 64-bit PCs (signed)

The kernel versions 5.7 executed the hibernation process properly.
The later ones did not until I had the init_on_alloc=0 to my grub
parameters.

$ inxi -G
Graphics:
  Device-1: NVIDIA G96C [GeForce 9400 GT] driver: nouveau v: kernel
  Display: x11 server: X.Org v: 1.20.11 with: Xwayland driver: X:
    loaded: modesetting gpu: nouveau resolution: 1920x1080~60Hz

  OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5

$ uname -a
Linux birdynam 5.18.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1
(2022-08-10) x86_64 GNU/Linux

HTH
Rudu

[Computer Enthusiastic]

Hello,

An upstream patch has been released [1]

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.0-rc5&id=6b04ce966a738ecdd9294c9593e48513c0dc90aa

[Diederik de Haas]

Control: fixed -1 5.19.6-1

That commit is part of v6.0-rc3

Fixed in 5.19 with commit 8e3ba23a67de984f4156f0663f1f603ff6c15815 which is
part of 5.19.6.