6.8.1: fails to hibernate with pm_runtime_force_suspend+0x0/0x120 returns -16
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,
Signature · 1 line
Martin
Martin Steigerwald - 16.03.24, 17:02:44 CET:
Quoted 2 lines
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.
Quoted 2 lines
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.
Signature · 1 line
Martin
Quoted 12 lines · Martin Steigerwald
Martin Steigerwald - 16.03.24, 17:02:44 CET:
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 1 line
[...]
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:
Quoted 15 lines · Martin Steigerwald
Quoted 4 lines
Martin Steigerwald - 16.03.24, 17:02:44 CET:
Quoted 2 lines
ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1. Hibernation works correctly with self-compiled 6.7.9.
Quoted 9 lines
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.
Quoted 2 lines
Trying to use "
no_console_suspend" to debug next. Will not do bisect between major kernel releases on a production machine.
Quoted 6 lines
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,
Signature · 1 line
Martin
Quoted 30 lines · Martin Steigerwald
Linux regression tracking (Thorsten Leemhuis) - 19.03.24, 09:40:06 CEST:
Quoted 15 lines · Martin Steigerwald
Quoted 4 lines
Martin Steigerwald - 16.03.24, 17:02:44 CET:
Quoted 2 lines
ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1. Hibernation works correctly with self-compiled 6.7.9.
Quoted 9 lines
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.
Quoted 2 lines
Trying to use "
no_console_suspend" to debug next. Will not do bisect between major kernel releases on a production machine.Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 5 lines
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.
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 9 lines
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:
Quoted 15 lines · Martin Steigerwald
Quoted 4 lines
Martin Steigerwald - 16.03.24, 17:02:44 CET:
Quoted 2 lines
ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1. Hibernation works correctly with self-compiled 6.7.9.
Quoted 9 lines
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.
Quoted 2 lines
Trying to use "
no_console_suspend" to debug next. Will not do bisect between major kernel releases on a production machine.
Quoted 6 lines
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,
Signature · 1 line
Martin
Martin Steigerwald - 05.04.24, 13:49:00 CEST:
Quoted 28 lines
Linux regression tracking (Thorsten Leemhuis) - 19.03.24, 09:40:06 CEST:
Quoted 17 lines · Martin Steigerwald
Quoted 4 lines
Martin Steigerwald - 16.03.24, 17:02:44 CET:
Quoted 2 lines
ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1. Hibernation works correctly with self-compiled 6.7.9.
Quoted 11 lines
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.Quoted 3 lines
Trying to use "
no_console_suspend" to debug next. Will not do bisect
between major kernel releases on a production machine.Quoted 6 lines
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:
[…]
Quoted 8 lines
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.
Quoted 5 lines
[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
Signature · 1 line
Martin
Re: [regression] 6.8.1 and 6.7.12: fails to hibernate with pm_runtime_force_suspend+0x0/0x120 returns -16
Martin Steigerwald - 05.04.24, 13:54:34 CEST:
Quoted 11 lines
Quoted 8 lines
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.
Signature · 1 line
Martin
Re: [regression] 6.8.1 and 6.7.12: fails to hibernate with pm_runtime_force_suspend+0x0/0x120 returns -16
Quoted 21 lines · Martin Steigerwald
Martin Steigerwald - 05.04.24, 13:54:34 CEST:
Quoted 11 lines
Quoted 8 lines
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.
Quoted 8 lines
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
Re: [regression] 6.8.1 and 6.7.12: fails to hibernate with pm_runtime_force_suspend+0x0/0x120 returns -16
Greg KH - 05.04.24, 15:34:30 CEST:
Quoted 11 lines
Quoted 8 lines
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.
Signature · 1 line
Martin
Martin Steigerwald - 05.04.24, 13:54:34 CEST:
Quoted 12 lines
Quoted 5 lines
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:
[…]
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Signature · 1 line
Martin