Dear Maintainer,
* What led up to the situation?
The kernel update from linux-image-6.1.0-44-amd64 to linux-image-6.1.0-45-amd64.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Hibernate, poweroff or reboot my system after an hour of using it. Initially
after booting it seems to work, but no longer after an hour or so. (To me it
seems as if the acpi kernel modules are unloaded over time and not reloaded
when needed.)
* What was the outcome of this action?
I could switch off my system only by using the power button.
* What outcome did you expect instead?
Poweroff, reboot or suspend my system without using the power button.
Best regards,
Floris Jan Sicking
f.j.sicking@issc.leidenuniv.nl
Hi Floris,
When you have a failure in hibernate, can you provide the full kernel
log after the problem was triggered please?
As this is a regression from the 6.1.164-1 to 6.1.170-1 update, might
you bisect the issue to identify the breaking commit. The procedure,
which involves compiling a couple of kernels and testing them would
look as follows:
git clone --single-branch -b linux-6.1.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.1.164
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_defconfig
# test 6.1.164 to ensure this is "good"
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem does
not exist. Unfortunately I understand you need to wait enough
long? This makes testing bit harder as we need to be sure you
would have triggered the problem.
# test 6.1.170 to ensure this is "bad"
git checkout v6.1.170
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm it problem
exists (see above ...)
With that confirmed, the bisection can start:
git bisect start
git bisect good v6.1.164
git bisect bad v6.1.170
In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:
make my_defconfig
make -j $(nproc) bindeb-pkg
... install, verify if problem exists
and if the problem is hit run:
git bisect bad
and if the problem doesn't trigger run:
git bisect good
. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.
Iterate until git announces to have identified the first bad commit.
Then provide the output of
git bisect log
In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.
Let me know if that helps or need to be clarified. The arder bit here
is the unclear reproduciblity time if you say that it works
immediately after reboot and have to wait enough long. The initial
asked log might still give us some hints.
Regards,
Salvatore
Forwarding to the BTS:----- Forwarded message from "Sicking, F.J. (Floris Jan)" <f.j.sicking@issc.leidenuniv.nl> ----- From: "Sicking, F.J. (Floris Jan)" <f.j.sicking@issc.leidenuniv.nl> Date: Sun, 10 May 2026 22:33:04 +0000 To: Salvatore Bonaccorso <carnil@debian.org> Subject: Re: Bug#1135817: linux-image-6.1.0-45-amd64: multiple failures in power management Delivered-To: salvatore.bonaccorso@gmail.com Message-ID: <AM5PR09MB80163C19E7B27971878F9739873B2@AM5PR09MB8016.eurprd09.prod.outlook.com> Hi Salvatore, See the attached file. For one of the kernels I did an extra "make": $ make my_defconfig $ make -j $(nproc) # gave a kernel $ make -j $(nproc) bindeb-pkg Please let me know if this can be an issue or if there are any other issues with the log. Best regards, Floris Jan----- End forwarded message -----
Control: tags -1 + moreinfo Hmm, that is very odd since the 'bad commit' points to a driver we do not even enable, so something went wrong in the bisect. Can you please redo? You need to pay attention to wait "long enough" for the suspected 'good cases". The reason is, you will know if things fail, but if things do not fail it might be possible to not have waited long enough. So when you have the issue not triggering, let's try to give it more time before determining if it is "good". Can you retry with that? Regards, Salvatore
Control: tags -1 + moreinfo Hmm, that is very odd since the 'bad commit' points to a driver we do not even enable, so something went wrong in the bisect. Can you please redo? You need to pay attention to wait "long enough" for the suspected 'good cases". The reason is, you will know if things fail, but if things do not fail it might be possible to not have waited long enough. So when you have the issue not triggering, let's try to give it more time before determining if it is "good". Can you retry with that? Regards, Salvatore
Hi, problem, might you please as well attach a netconsole so when then problem is hit we might get useful log information? On how to do that: https://docs.kernel.org/networking/netconsole.html#netconsole Can you additionally please provide the list of loaded module on the system? Regards, Salvatore
Hi, problem, might you please as well attach a netconsole so when then problem is hit we might get useful log information? On how to do that: https://docs.kernel.org/networking/netconsole.html#netconsole Can you additionally please provide the list of loaded module on the system? Regards, Salvatore