Variable isolation results (as requested)
Following the request to isolate which parameter actually fixes the issue, I
ran the kernel with only `retbleed=off`, re-enabling both the SRSO mitigation
and the deep C-states that were previously disabled.
Result: the system is stable. `retbleed=off` alone is sufficient. Uptime is
currently 3 days 8 hours (since 2026-07-23 11:37:25 UTC-3) with zero errors in
`dmesg -l err,crit,alert,emerg`. For reference, the original crashes occurred
every 12-36 hours, so this window is well past the failure threshold.
Test matrix
| # | Boot parameters | Result |
|---|---|---|
| 1 | `processor.max_cstate=1` | Still crashed — trace in `srso_safe_ret` |
| 2 | `processor.max_cstate=1 spec_rstack_overflow=off` | Still crashed —
trace moved to `retbleed_return_thunk` |
| 3 | `processor.max_cstate=1 spec_rstack_overflow=off retbleed=off` |
Stable, 7d 16h |
| 4 | **`retbleed=off`** (current) | **Stable, 3d 8h and counting** |
Test 2 is the informative one: with SRSO mitigation disabled the crash did not
go away, it simply relocated to the RETBleed return thunk. Test 4 then confirms
the inverse — with SRSO mitigation active and all C-states available, the
system does not crash.
This rules out both `processor.max_cstate=1` and `spec_rstack_overflow=off`
as necessary parts of the workaround. The problem is specific to the RETBleed
return thunk.
Current state
$ uname -rv
7.0.0-28-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 21 01:01:36 UTC 2026
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=... ro quiet splash
retbleed=off nmi_watchdog=1 crashkernel=...
$ cat /sys/devices/system/cpu/vulnerabilities/retbleed
Vulnerable
$ cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Mitigation: Safe RET
SRSO mitigation is **enabled** and the system is stable — confirming SRSO was
never the
trigger.
Deep C-states are active and in heavy use
$ for s in /sys/devices/system/cpu/cpu0/cpuidle/state*/; do
echo "$(cat $s/name) latency=$(cat $s/latency)us usage=$(cat $s/usage)";
done
POLL latency=0us usage=48906
C1 latency=1us usage=28471209
C2 latency=350us usage=6195986
C3 latency=400us usage=50968085
driver: acpi_idle
governor: menu
C3 has been entered ~51 million times over this uptime. The original crash
signature was in the `cpuidle` → `sched_tick` path (`kick_ilb`), so if deep
C-state entry were part of the trigger, this workload would have reproduced it
many times over.
Independent confirmation: I monitor this machine's power draw through a smart
plug, and idle consumption dropped to 8-10W once the C-state restriction was
lifted. The deep C-states are genuinely being entered, not merely advertised.
Environment
| | |
|---|---|
| CPU | AMD Ryzen 7 4800U with Radeon Graphics (family 23, model 96, stepping
1 — Zen2) |
| Microcode | 0x860010d |
| System | Beelink SER, BIOS SER_V1.14_P3C6M43_B_Link (2022-03-24) |
| OS | Ubuntu 26.04 LTS |
| Kernel | 7.0.0-28-generic |
Note the BIOS dates from 2022 and no newer release is available from the
vendor for this board, so the AGESA/microcode level cannot be raised further on
my side.
Summary
The workaround for this hardware reduces to a single parameter,
`retbleed=off`. Neither disabling the SRSO mitigation nor restricting C-states
is required. Happy to run further tests or collect additional data if that
would help narrow down the return thunk interaction.
--
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
