I think the freezes may more likely be caused by the core dumper? If you run Steam with steam -no-cef-sandbox, the core dumps should no longer happen. I think they are caused by old CEF with modern glibc, and disabling the sandbox works around that for now. You should not use the Steam client as a browser for untrusted website, tho, while the CEF sandbox is disabled. So it's only a temporary solution which should be disabled once the Steam client moved to modern 64 bit architecture.
If the system freezes still persist after the work-around, the mitigation may throttle processes within critical IO paths which block other operations of the system. This shouldn't happen usually, but maybe there's writeback pressure in your system? Actually, the core dumper will cause writeback pressure, resulting in a positive feedback loop.
Thanks for the quick response! I need to clarify a few things regarding the initial report to avoid confusion:
I am about to test the -no-cef-sandbox workaround as suggested to see if it has any impact on the frequency of these freezes, even in the absence of crashes.
Adding an AMD data point, and also what happens with split_lock_detect=fatal (which I don't think anyone has tested in this thread yet).
My setup:
I'd originally gone with split_lock_detect=fatal because the default warn was letting Steam's CHTTPClientThre emit something on the order of 150k bus-lock #DB traps per second, and that was enough to starve my AMD hardware watchdog. The box is remote, the watchdog auto-reboots on kernel hang, so I really can't afford that level of #DB traffic.
With fatal, Steam now crashes instantly at launch:
steam.sh: line 966: 329184 Bus error (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@"
Full log excerpt:
steam.sh[329085]: Running Steam on nixos 26.05 64-bit
steam.sh[329085]: STEAM_RUNTIME is enabled automatically
setup.sh[329142]: Steam runtime environment up-to-date!
steam.sh[329085]: Steam client's requirements are satisfied
CProcessEnvironmentManager is ready, 6 preallocated environment variables.
[2026-04-10 10:33:16] Startup - updater built Apr 9 2026 01:38:34
[2026-04-10 10:33:16] Startup - Steam Client launched with: '/home/can/.local/share/Steam/ubuntu12_32/steam' '-srt-logger-opened'
Opted in to client beta 'publicbeta' via beta file
04/10 10:33:16 Init: Installing breakpad exception handler for appid(steam)/version(1775703228)/tid(329184)
Looks like steam didn't shutdown cleanly, scheduling immediate update check
[2026-04-10 10:33:16] Process started with command-line: '/home/can/.local/share/Steam/ubuntu12_32/steam' '-child-update-ui' '-child-update-ui-socket' '8' '-srt-logger-opened'
crash_20260410103316_2.dmp[329189]: Uploading dump (out-of-process)
/tmp/dumps/crash_20260410103316_2.dmp
[2026-04-10 10:33:16] Using update UI: xwin
04/10 10:33:16 Init: Installing breakpad exception handler for appid(steam)/version(0)/tid(329185)
[2026-04-10 10:33:16] Create window
/home/can/.local/share/Steam/steam.sh: line 966: 329184 Bus error (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@"
crash_20260410103316_2.dmp[329189]: Finished uploading minidump (out-of-process): success = yes
crash_20260410103316_2.dmp[329189]: response: CrashID=bp-d1711e8d-b0da-487d-aa77-3359f2260410
[2026-04-10 10:33:17] ProcessNextMessage: socket disconnected
[2026-04-10 10:33:17] No more messages are expected - exiting
Worth noting the AMD side of this: according to the kernel docs, split_lock_detect= on AMD only affects bus-lock #DB handling, since AMD doesn't raise split-lock #AC at all. So in fatal mode the kernel just sends SIGBUS on the very first bus-lock trap, and Steam hits that on the first CHTTPClientThre misaligned atomic before the main window even gets created. So on AMD, fatal isn't "degraded" behavior, it's an immediate hard crash at launch.
The breakpad CrashID above (bp-d1711e8d-b0da-487d-aa77-3359f2260410) has the matching minidump if that's useful, should contain the faulting RIP and the address of the atomic.
What's actually working for me as a workaround is split_lock_detect=ratelimit:5. Unlike off/warn/fatal, ratelimit:N is a bus-lock-specific mode (not split-lock), and instead of killing the offender it throttles it via enforced msleep() in the #DB handler. Net result: Steam stays alive, the bus-lock rate is capped well under what my watchdog can tolerate, and dmesg still shows the warnings so I'd notice a regression. For anyone else on AMD running into this, I'd suggest trying ratelimit:N (something in the 5 to 50 range) before reaching for off.
None of this fixes the underlying bug of course. There's some hot-path atomic in CHTTPClientThre whose storage isn't aligned, so it straddles a cache line on modern AMD and trips #DB on every access. If there's anything useful I can provide beyond the minidump (perf capture, targeted tracing, whatever), happy to.
I have seen these log entries no freezes so far but it absolutly spams my journal while steam is active.
`Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.26.0
Qt Version: 6.10.3
Kernel Version: 7.0.9-104.fc43.x86_64 (64-bit)
Graphics Platform: offscreen
Processors: 32 × AMD Ryzen 9 9950X3D 16-Core Processor
Memory: 32 GiB of RAM (31.0 GiB usable)
`
I wonder if considering that this seems to specifically target an x86 path how the behaviour would be on the experimental 64 bit client
I think i had the issue yesterday related to this.
9800x3d
9070xt
msi mpg carbon x870e
Bazzite 44.20260608 (2026-06-08T19:16:10Z)
My pc sudenly froze, about hour after boot.
Next restart, it froze almost immidiately, within minutes.
and any after that.
One boot, my qualcomm wifi chip on my motherboard, didn’t load (happens sometimes when restarting, requires power cycle to get back on) and it did not freeze when my wifi was down.
So, figured must be something downloading.
Rebooted back with wifi, had enough time to check what its connecting to (it was steam)
Checked download queue. rebooted, with blocked internet access to my PC, but wifi working. Didnt freeze either anymore.
Removed the game and some proton experimental (bleeding edge), which was trying to update. turned on access to internet, and it didnt crash anymore.
Im so far fine since that time.
Found this in one of the boot logs.
Jun 30 19:44:44 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:44 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:45 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:45 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:45 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:45 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:45 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:45 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:45 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:45 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: handle_bus_lock: 366 callbacks suppressed
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:49 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: handle_bus_lock: 139 callbacks suppressed
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:54 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: handle_bus_lock: 132 callbacks suppressed
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Jun 30 19:44:59 bazzite kernel: x86/split lock detection: #DB: CHTTPClientThre/19782 took a bus_lock trap at address: 0xf323a094
Seeing the same on 9850X3D. Never brought the system down but definitely log spammed a bit.
Found this in one of the boot logs.
These logs don't indicate any cause for the system freeze you were experiencing. These logs only show that the CPU performance has been degraded because some Steam process is using split locks (which hopefully gets resolved when the Steam Client officially switches to 64 bit).
If you want to try to observe the real cause of the freeze, ssh into your system from another computer and run dmesg -w, you should then be able to see the very last logs before the crash. It's more likely you're seeing an issue with the network driver, the kernel scheduler or your file system. In that case, it should be reported to Bazzite. The split-lock logged by the Steam Client (CHTTPClientThread) are most likely not causing the freeze.
I believe this will not be fixed until the client is ported to AMD64. @ValveSoftware if you want help I'm game
proton experimentalx1 2026-07
Your system information
Please describe your issue in as much detail as possible:
Expected: Steam should perform background network tasks (manifest downloads, update checks) without impacting overall system performance or stability.
Actual:
The Steam client triggers frequent system-wide freezes and stutters (lasting 10–20 seconds). These events coincide with split lock detection warnings in the system journal. The offending thread is consistently identified as CHTTPClientThre.
The kernel (especially on modern AMD Zen architectures) throttles the entire system due to bus_lock traps generated by unaligned atomic operations within the 32-bit components of the Steam client. This makes the OS virtually unusable while Steam is performing background updates.
Technical Log snippet:
Setting the kernel parameter split_lock_detect=off or warn mitigates the freezing, but the client still frequently experiences Segmentation faults in the same thread:
Steps for reproducing this issue: