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

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

On Tue, 31 Aug 2021 23:13:33 +0200 Achille L <computer.enthusiastic@gmail.com> wrote:
> 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 wit

h 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).