linux-kernel - Re: [regression] 6.8.1: fails to hibernate with pm_runtime_force

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <22240355.EfDdHjke4D@lichtvoll.de>
Date: Tue, 02 Apr 2024 21:42:58 +0200
From: Martin Steigerwald <martin@...htvoll.de>
To: linux-pm@...r.kernel.org, regressions@...ts.linux.dev,
 linux-kernel@...r.kernel.org,
 Linux regressions mailing list <regressions@...ts.linux.dev>
Subject:
 Re: [regression] 6.8.1: fails to hibernate with
 pm_runtime_force_suspend+0x0/0x120 returns -16

Hi Thorsten, hi,

Linux regression tracking (Thorsten Leemhuis) - 19.03.24, 09:40:06 CEST:
> On 16.03.24 17:12, Martin Steigerwald wrote:
> > Martin Steigerwald - 16.03.24, 17:02:44 CET:
> >> ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1.
> >> Hibernation works correctly with self-compiled 6.7.9.
> > 
> > Apparently 6.8.1 does not even reboot correctly anymore. runit on
> > Devuan. It says it is doing the system reboot but then nothing
> > happens.
> > 
> > As for hibernation the kernel cancels the attempt and returns back to
> > user space desktop session.
> > 
> >> Trying to use "no_console_suspend" to debug next. Will not do bisect
> >> between major kernel releases on a production machine.
> 
> FWIW, without a bisection I guess no developer will take a closer look
> (but I might be wrong and you lucky here!), as any change in those
> hundreds of drivers used on that machine can possibly lead to problems
> like yours. So without a bisection we are likely stuck here, unless
> someone else runs into the same problem and bisects or fixes it. Sorry,
> but that's just how it is.

I have been asked this repeatedly with previous bug reports. My issue
with bisecting between major kernel versions is this:

When I look around here I see no second ThinkPad T14 AMD Gen 1 here I 
could use for testing. Also doing a kernel bisect using a GRML live iso… 
not really.

The one I reported this from is a production machine with a 4 TB NVMe
SSD which contains a lot of data. I am not willing to risk data loss or
(silent) file system corruption by bisecting between major kernel
releases. Bisecting between major kernel releases in my understanding
would require to test various releases between in this example 6.7 and
6.8 and even between 6.7 and 6.8-rc1. At least in my understand anything 
between 6.7 and 6.8-rc1 is not guaranteed to be even be somewhat stable. I 
am not usually installing an rc1 kernel on a production machine, but 
rather wait for at least rc2/3 nowadays. Its a balanced risk calculation. 
And rc2/3 or later appears to be a risk I am willing to take. But 
something between stable and rc1? Nope.

It is not even that rare. 6.7 some rc failed with hibernation as well. 
With exactly the same machine. I refused to do a bisect as well in that 
case. At some later time the issue was fixed without me doing anything 
more.

Now my question is this: Without me willing to bisect in that case, is
a bug report even useful? Otherwise I may just switch this last machine
to distribution kernels. It would save a lot of time for me. This private 
and freelancer production machine is the last left-over machine with self-
compiled kernels.

So far I still thought I would somehow be contributing to Linux kernel
quality with detailed bug reports that take time to write, but apparently 
I am not. Can you clarify?

Ciao,
-- 
Martin