Received-SPF: pass (google.com: domain of linux-kernel+bounces-128600-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Martin Steigerwald <martin@lichtvoll.de>
To: linux-pm@vger.kernel.org, regressions@lists.linux.dev,
 linux-kernel@vger.kernel.org,
 Linux regressions mailing list <regressions@lists.linux.dev>
Subject:
 Re: [regression] 6.8.1: fails to hibernate with
 pm_runtime_force_suspend+0x0/0x120 returns -16
Date: Tue, 02 Apr 2024 21:42:58 +0200
Message-ID: <22240355.EfDdHjke4D@lichtvoll.de>
In-Reply-To: <be5a7213-78b3-4917-b95b-ec31cd2350e4@leemhuis.info>
References:
 <2325246.ElGaqSPkdT@lichtvoll.de> <12401263.O9o76ZdvQC@lichtvoll.de>
 <be5a7213-78b3-4917-b95b-ec31cd2350e4@leemhuis.info>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

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.
> >=20
> > 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.
> >=20
> > As for hibernation the kernel cancels the attempt and returns back to
> > user space desktop session.
> >=20
> >> Trying to use "no_console_suspend" to debug next. Will not do bisect
> >> between major kernel releases on a production machine.
>=20
> 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=20
could use for testing. Also doing a kernel bisect using a GRML live iso=E2=
=80=A6=20
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=20
between 6.7 and 6.8-rc1 is not guaranteed to be even be somewhat stable. I=
=20
am not usually installing an rc1 kernel on a production machine, but=20
rather wait for at least rc2/3 nowadays. Its a balanced risk calculation.=20
And rc2/3 or later appears to be a risk I am willing to take. But=20
something between stable and rc1? Nope.

It is not even that rare. 6.7 some rc failed with hibernation as well.=20
With exactly the same machine. I refused to do a bisect as well in that=20
case. At some later time the issue was fixed without me doing anything=20
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=20
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=20
I am not. Can you clarify?

Ciao,
=2D-=20
Martin