Hi!
ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1.
Hibernation works correctly with self-compiled 6.7.9.
Trying to use "no_console_suspend" to debug next. Will not do bisect
between major kernel releases on a production machine.
[ 409.847217] PM: hibernation: hibernation entry
[ 409.874672] Filesystems sync: 0.027 seconds
[ 409.875204] Freezing user space processes
[ 409.877765] Freezing user space processes completed (elapsed 0.002 seconds)
[ 409.877770] OOM killer disabled.
[ 409.878027] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
[ 409.878031] PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff]
[ 409.878034] PM: hibernation: Marking nosave pages: [mem 0x09c00000-0x09d00fff]
[ 409.878039] PM: hibernation: Marking nosave pages: [mem 0x09f00000-0x09f0ffff]
[ 409.878041] PM: hibernation: Marking nosave pages: [mem 0xa2356000-0xa2356fff]
[ 409.878042] PM: hibernation: Marking nosave pages: [mem 0xa2363000-0xa2364fff]
[ 409.878043] PM: hibernation: Marking nosave pages: [mem 0xa2372000-0xa2373fff]
[ 409.878045] PM: hibernation: Marking nosave pages: [mem 0xa2384000-0xa2384fff]
[ 409.878046] PM: hibernation: Marking nosave pages: [mem 0xb9c57000-0xb9ce7fff]
[ 409.878049] PM: hibernation: Marking nosave pages: [mem 0xbd9de000-0xcc3fdfff]
[ 409.878530] PM: hibernation: Marking nosave pages: [mem 0xce000000-0xffffffff]
[ 409.879306] PM: hibernation: Basic memory bitmaps created
[ 409.884500] PM: hibernation: Preallocating image memory
[ 412.146014] PM: hibernation: Allocated 2800864 pages for snapshot
[ 412.146022] PM: hibernation: Allocated 11203456 kbytes in 2.26 seconds (4957.28 MB/s)
[ 412.146025] Freezing remaining freezable tasks
[ 412.147610] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 412.147829] printk: Suspending console(s) (use no_console_suspend to debug)
[ 412.158400] port 0000:02:00.1:0.0: PM: dpm_run_callback(): pm_runtime_force_suspend+0x0/0x120 returns -16
[ 412.158418] port 0000:02:00.1:0.0: PM: failed to freeze: error -16
[ 413.879379] PM: hibernation: Basic memory bitmaps freed
[ 413.879847] OOM killer enabled.
[ 413.879852] Restarting tasks ... done.
[ 413.882304] PM: hibernation: hibernation exit
Best,
--
Martin
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.
Output with "no_console_suspend":
[ 82.593360] r8169 0000:05:00.0 en1: Link is Down
[ 83.196401] PM: hibernation: hibernation entry
[ 83.671489] Filesystems sync: 0.121 seconds
[ 83.671977] Freezing user space processes
[ 83.674855] Freezing user space processes completed (elapsed 0.002 seconds)
[ 83.674879] OOM killer disabled.
[ 83.675111] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
[ 83.675114] PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff]
[ 83.675117] PM: hibernation: Marking nosave pages: [mem 0x09c00000-0x09d00fff]
[ 83.675122] PM: hibernation: Marking nosave pages: [mem 0x09f00000-0x09f0ffff]
[ 83.675123] PM: hibernation: Marking nosave pages: [mem 0xa2357000-0xa2357fff]
[ 83.675125] PM: hibernation: Marking nosave pages: [mem 0xa2364000-0xa2365fff]
[ 83.675126] PM: hibernation: Marking nosave pages: [mem 0xa2373000-0xa2374fff]
[ 83.675128] PM: hibernation: Marking nosave pages: [mem 0xa2385000-0xa2385fff]
[ 83.675129] PM: hibernation: Marking nosave pages: [mem 0xb9532000-0xb95c2fff]
[ 83.675132] PM: hibernation: Marking nosave pages: [mem 0xbd9de000-0xcc3fdfff]
[ 83.675620] PM: hibernation: Marking nosave pages: [mem 0xce000000-0xffffffff]
[ 83.676393] PM: hibernation: Basic memory bitmaps created
[ 83.681188] PM: hibernation: Preallocating image memory
[ 85.599072] PM: hibernation: Allocated 2043901 pages for snapshot
[ 85.599105] PM: hibernation: Allocated 8175604 kbytes in 1.91 seconds (4280.42 MB/s)
[ 85.599125] Freezing remaining freezable tasks
[ 85.600726] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 85.611679] port 0000:02:00.1:0.0: PM: dpm_run_callback(): pm_runtime_force_suspend+0x0/0x120 returns -16
[ 85.611709] port 0000:02:00.1:0.0: PM: failed to freeze: error -16
[ 86.303477] PM: hibernation: Basic memory bitmaps freed
[ 86.304003] OOM killer enabled.
[ 86.304582] Restarting tasks ... done.
[ 86.307452] thermal thermal_zone0: failed to read out thermal zone (-61)
[ 86.307507] PM: hibernation: hibernation exit
[ 86.331566] Generic FE-GE Realtek PHY r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC)
[ 86.932558] r8169 0000:02:00.0 en0: rtl_ep_ocp_read_cond == 0 (loop: 30, delay: 10000).
[ 87.004862] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694]
[ 87.038125] r8169 0000:02:00.0 en0: Link is Down
[ 87.043559] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..]
[ 87.067568] Generic FE-GE Realtek PHY r8169-0-500:00: attached PHY driver (mii_bus:phy_addr=r8169-0-500:00, irq=MAC)
[ 87.204101] r8169 0000:05:00.0 en1: Link is Down
[ 90.639039] r8169 0000:05:00.0 en1: Link is Up - 1Gbps/Full - flow control rx/tx
Downgrading to 6.7.
Thanks.
--
Martin
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.
> [...]
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
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
On 02.04.24 21:42, Martin Steigerwald wrote:
> 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.
It's hard to qualify and always a matter of personal viewpoint/opinion,
but I'd say: kernel from the merge window are pretty stable and
reliable. But sure, accidents that eat data happen and they happen
slightly more often during merge windows because the rate of change is
higher. But in the end they do not happen often, which is why Fedora
rawhide for example ships merge window kernels all the time.
> 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.
Well, that's up to you -- but the reality is also that developers are
not obliged to look into regressions report closely, unless someone
bisected it.
> It is not even that rare. 6.7 some rc failed with hibernation as well.
Maybe too few people (or too few of those that run the latest kernels)
use hibernate these days (I haven't for more than 15 years), which is
why it's not tested much.
> 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.
Maybe you were lucky, maybe someone else bisected and reported the problem.
> 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?
Not really, as it always depends on the situation. There are bugs (like
https://lore.kernel.org/all/[email protected]/
) where a report without a bisection is enough. But there are others
where it's unlikely that anyone will take a closer look; a lot of those
reg. suspend/hibernate fall into this category, as problems in that area
can be cause by any subsystem and its drivers -- which is why the power
management people can't look into most of those, as then they quickly
wouldn't get anything else done while spending time on bugs most of the
time other people caused.
Ciao, Thorsten
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.
The plot thickens, now 6.7.12 as compared to 6.7.11 which failed hibernation
with busy work queues? and 6.7.9 + bcachefs downgrade fixes fails
hibernation with the same error message than 6.8.1:
[ 74.330285] PM: hibernation: hibernation entry
[ 74.617009] Filesystems sync: 0.097 seconds
[ 74.617309] Freezing user space processes
[ 74.620021] Freezing user space processes completed (elapsed 0.002 seconds)
[ 74.620048] OOM killer disabled.
[ 74.620250] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
[ 74.620253] PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff]
[ 74.620256] PM: hibernation: Marking nosave pages: [mem 0x09c00000-0x09d00fff]
[ 74.620261] PM: hibernation: Marking nosave pages: [mem 0x09f00000-0x09f0ffff]
[ 74.620263] PM: hibernation: Marking nosave pages: [mem 0xa22b7000-0xa22b7fff]
[ 74.620264] PM: hibernation: Marking nosave pages: [mem 0xa22c4000-0xa22c5fff]
[ 74.620266] PM: hibernation: Marking nosave pages: [mem 0xa22d3000-0xa22d4fff]
[ 74.620267] PM: hibernation: Marking nosave pages: [mem 0xa22e5000-0xa22e5fff]
[ 74.620269] PM: hibernation: Marking nosave pages: [mem 0xb9533000-0xb95c3fff]
[ 74.620272] PM: hibernation: Marking nosave pages: [mem 0xbd9de000-0xcc3fdfff]
[ 74.620752] PM: hibernation: Marking nosave pages: [mem 0xce000000-0xffffffff]
[ 74.622717] PM: hibernation: Basic memory bitmaps created
[ 74.629269] PM: hibernation: Preallocating image memory
[ 76.658495] PM: hibernation: Allocated 2042025 pages for snapshot
[ 76.658875] PM: hibernation: Allocated 8168100 kbytes in 2.02 seconds (4043.61 MB/s)
[ 76.658901] Freezing remaining freezable tasks
[ 76.660457] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 76.666115] port 0000:02:00.1:0.0: PM: dpm_run_callback(): pm_runtime_force_suspend+0x0/0x120 returns -16
[ 76.666255] port 0000:02:00.1:0.0: PM: failed to freeze: error -16
[ 78.616495] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694]
[ 78.654349] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..]
[ 79.106531] PM: hibernation: Basic memory bitmaps freed
[ 79.106855] OOM killer enabled.
[ 79.106873] Restarting tasks ... done.
[ 79.111514] PM: hibernation: hibernation exit
Not doing it today or probably the weekend, but now I have some actionable
git bisect plan without bisecting between major kernel releases which as I
have been told between 6.7 an 6.8-rc1 can lead to non working modeset
graphics on AMD Ryzen in between.
It seems now I only need to git bisect between 6.7.11 and 6.7.12 to find the
patch that breaks hibernation on 6.8.1 as well. However first I will briefly
check whether 6.8.4 hibernates okay.
[1] * 6.7.11: Fails to hibernate - work queues still busy
@ 2024-04-02 19:29 Martin Steigerwald
https://lore.kernel.org/regressions/[email protected]/T/#t
Best,
--
Martin
Martin Steigerwald - 05.04.24, 13:49:00 CEST:
> 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.
>
> The plot thickens, now 6.7.12 as compared to 6.7.11 which failed
> hibernation with busy work queues¹ and 6.7.9 + bcachefs downgrade fixes
> fails hibernation with the same error message than 6.8.1:
[…]
> Not doing it today or probably the weekend, but now I have some
> actionable git bisect plan without bisecting between major kernel
> releases which as I have been told between 6.7 an 6.8-rc1 can lead to
> non working modeset graphics on AMD Ryzen in between.
>
> It seems now I only need to git bisect between 6.7.11 and 6.7.12 to find
> the patch that breaks hibernation on 6.8.1 as well. However first I
> will briefly check whether 6.8.4 hibernates okay.
6.8.4 is still affected and fails hibernation with the same error message.
> [1] * 6.7.11: Fails to hibernate - work queues still busy
> @ 2024-04-02 19:29 Martin Steigerwald
>
> https://lore.kernel.org/regressions/2ad93b57-8fdc-476e-83b7-2c0af1cfd41d
> @leemhuis.info/T/#t
--
Martin
Martin Steigerwald - 05.04.24, 13:54:34 CEST:
> > Not doing it today or probably the weekend, but now I have some
> > actionable git bisect plan without bisecting between major kernel
> > releases which as I have been told between 6.7 an 6.8-rc1 can lead to
> > non working modeset graphics on AMD Ryzen in between.
> >
> > It seems now I only need to git bisect between 6.7.11 and 6.7.12 to
> > find the patch that breaks hibernation on 6.8.1 as well. However
> > first I will briefly check whether 6.8.4 hibernates okay.
>
> 6.8.4 is still affected and fails hibernation with the same error
> message.
Both kernels also fail to reboot the machine. Runit says:
- runit: system reboot
And then nothing anymore.
It is not just hibernation.
I think ThinkPad T14 AMD Gen 1 or similar systems with Linux are not that
rare. I am surprised this is not hitting more people. Well maybe it does
and no one reported it here.
Well let's see what happens when 6.7.12 hits distribution kernels.
Anyway, I have an actionable git bisect between 6.7.11 and 6.7.12, just
not today. Maybe beginning of next week.
--
Martin
Martin Steigerwald - 05.04.24, 13:54:34 CEST:
> > The plot thickens, now 6.7.12 as compared to 6.7.11 which failed
> > hibernation with busy work queues¹ and 6.7.9 + bcachefs downgrade
> > fixes
>
> > fails hibernation with the same error message than 6.8.1:
> […]
>
> > Not doing it today or probably the weekend, but now I have some
> > actionable git bisect plan without bisecting between major kernel
> > releases which as I have been told between 6.7 an 6.8-rc1 can lead to
> > non working modeset graphics on AMD Ryzen in between.
> >
> > It seems now I only need to git bisect between 6.7.11 and 6.7.12 to
> > find the patch that breaks hibernation on 6.8.1 as well. However
> > first I will briefly check whether 6.8.4 hibernates okay.
>
> 6.8.4 is still affected and fails hibernation with the same error
> message.
Also this time it is just the ThinkPad T14 AMD Gen 1 with a Lenovo USB
mouse. No second monitor, no USB hub, no nothing else attached.
Should have tested with such a minimal setup to begin with to limit the
test case to a minimum.
--
Martin
On Fri, Apr 05, 2024 at 02:11:11PM +0200, Martin Steigerwald wrote:
> Martin Steigerwald - 05.04.24, 13:54:34 CEST:
> > > Not doing it today or probably the weekend, but now I have some
> > > actionable git bisect plan without bisecting between major kernel
> > > releases which as I have been told between 6.7 an 6.8-rc1 can lead to
> > > non working modeset graphics on AMD Ryzen in between.
> > >
> > > It seems now I only need to git bisect between 6.7.11 and 6.7.12 to
> > > find the patch that breaks hibernation on 6.8.1 as well. However
> > > first I will briefly check whether 6.8.4 hibernates okay.
> >
> > 6.8.4 is still affected and fails hibernation with the same error
> > message.
>
> Both kernels also fail to reboot the machine. Runit says:
>
> - runit: system reboot
>
> And then nothing anymore.
>
> It is not just hibernation.
>
> I think ThinkPad T14 AMD Gen 1 or similar systems with Linux are not that
> rare. I am surprised this is not hitting more people. Well maybe it does
> and no one reported it here.
>
> Well let's see what happens when 6.7.12 hits distribution kernels.
>
> Anyway, I have an actionable git bisect between 6.7.11 and 6.7.12, just
> not today. Maybe beginning of next week.
6.7.y is end-of-life, I wouldn't worry too much about it, there's
nothing we can do about it anymore, sorry.
greg k-h
Greg KH - 05.04.24, 15:34:30 CEST:
> > I think ThinkPad T14 AMD Gen 1 or similar systems with Linux are not
> > that rare. I am surprised this is not hitting more people. Well maybe
> > it does and no one reported it here.
> >
> > Well let's see what happens when 6.7.12 hits distribution kernels.
> >
> > Anyway, I have an actionable git bisect between 6.7.11 and 6.7.12,
> > just not today. Maybe beginning of next week.
>
> 6.7.y is end-of-life, I wouldn't worry too much about it, there's
> nothing we can do about it anymore, sorry.
Ah, I see. Thanks.
Still its a good short cut for bisection. Bisecting between 6.7.11 and
6.7.12 should get much quicker results than bisecting between 6.7 and 6.8
and as its the same error message in 6.8.1/6.8.4 and 6.7.12 it might be
the same (backported) patch causing the issue.
--
Martin