7.0.0-29-generic is stable: 48 hours with both mitigations enabled
Following up on my previous comment, where I said I would boot the Ubuntu
7.0.0-29 kernel that had been installed but never used on this machine.
RESULT: no crash in 48 hours, with retbleed and SRSO mitigations ENABLED and
no workaround on the command line.
kernel 7.0.0-29-generic
#29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026
uptime 48.1 hours, still running
boot params quiet splash nmi_watchdog=1
(no retbleed=off, no spec_rstack_overflow=off,
no processor.max_cstate=1)
retbleed Mitigation: untrained return thunk; SMT enabled with STIBP
spec_rstack_overflow
Mitigation: Safe RET
kdump armed the whole time, 512M crashkernel
vmcore none produced
Call Trace / panic / oops
zero, checked hourly by a monitor script (50 consecutive
clean reports)
The original failure window was 12 to 36 hours, so 48 hours clears it with
margin. For comparison, 7.0.0-27 and 7.0.0-28 crashed repeatedly in that
window on this same hardware, and the only way to keep the machine up was
retbleed=off, which is what I had been running since July.
THE IDLE PATH WAS EXERCISED, not merely waited out
The panics were in srso_safe_ret and later in retbleed_return_thunk, reached
through cpuidle during sched_tick. So the relevant number is not just uptime
but how much the idle path ran:
326,328,922 entries into C3 across 16 threads in 48 hours
C3 is the deep idle state whose return path was faulting. It was entered over
three hundred million times without a single trace.
HARDWARE (unchanged from the original report)
AMD Ryzen 7 4800U with Radeon Graphics
family 23, model 96, stepping 1
microcode 0x860010d
BIOS SER_V1.14_P3C6M43_B_Link, 2022-03-24 (latest available for this board)
CONCLUSION
This matches the assessment that the problem was in the backport rather than
upstream: 7.2.0-rc5 mainline was stable with both mitigations for 332 hours
across 7 boots, and now the Ubuntu 7.0.0-29 backport is stable as well, while
7.0.0-27 and 7.0.0-28 were not. Whatever changed between -28 and -29 fixed it.
I am moving this machine back to the supported Ubuntu kernel and removing the
mainline build I had been using as a workaround. Happy to run any further test
if it helps to identify which change fixed it, since I have a reproducer that
used to fail within a day and a half.
A NOTE ON METHOD, in case it saves someone time
This crash leaves nothing in the journal. I checked 33 boots: a hard panic
kills the machine before journald flushes, so after a reboot there is no record
at all. Do not conclude a kernel is clean from an empty log. What actually
works as evidence is a kdump vmcore, the uptime reached, and instrumenting the
idle counters as above.
Also worth knowing when grepping for evidence: "drm panic" is a DRM feature
name and appears in normal boots, and "active return thunk:
retbleed_return_thunk" is the kernel announcing the mitigation is enabled, not
a fault. Both produced false positives in my first detector.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2160457
Title:
Kernel panic in srso_safe_ret / kick_ilb during sched_tick on AMD
Ryzen 7 4800U (Zen2)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160457/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
