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.enthusias...@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).