System info:
Hardware: Apple Mac Mini, Apple M1 (base, non-Pro/Max/Ultra)
OS: Fedora Asahi Remix 44
Kernel: 7.1.6-400.asahi.fc44.aarch64+16k
fex-emu: 2604-1.fc44.aarch64
mesa-vulkan-drivers / mesa-libgbm: 26.1.5-1.fc44.aarch64
muvm: (installed via dnf install steam, exact version TBD — muvm --version doesn't print one directly, only accepts subcommands)
Steps to reproduce:
Fresh install via sudo dnf install steam -y on a clean Fedora Asahi Remix 44 system.
Run steam from a terminal.
Steam's own connection log shows connectivity tests (IPv4 + IPv6 HTTP + IPv6 UDP) all succeeding, and the login window is created and shown (WasHidden 0 in webhelper.txt).
Despite this, the GUI remains stuck indefinitely on "Waiting for Network," and the separate Python/PyQt6 launcher splash never dismisses either.
What I've ruled out:
DNS/networking: resolvectl status and curl -4/curl -6 confirm working IPv4 connectivity; Steam's own internal connectivity tests pass.
Memory pressure: free -h shows ~5.5Gi available, 0 swap used during the hang.
-cef-disable-gpu (Steam flag): no change in behavior.
LIBGL_ALWAYS_SOFTWARE=1 exported before launching steam: no change in behavior (though I can't confirm this variable actually propagated into the guest VM through the muvm/FEXBash launch path).
Debug findings:
Running with RUST_LOG=debug shows muvm's krun_devices::virtio::gpu::worker in what looks like a livelock: it repeatedly logs fence called: id=N against a mostly-static, slowly-growing list of fence IDs (e.g. 23, 32, 49, 142, 372, 752, 1857...) at extremely high frequency (thousands of times per second), with old fence IDs never appearing to retire. CPU usage on the muvm process stays pinned at 50%+ the entire time the UI is hung. Sample excerpt attached (steam-debug.log).
muvm-debug.log
(Steam's log failed to upload so pardon me for compressing it)
steam-debug.zip
NOTE: This report was written by Claude. I cannot guarantee that it is entirely true but I have verified it to the best of my ability.
System info:
Hardware: Apple Mac Mini, Apple M1 (base, non-Pro/Max/Ultra)
OS: Fedora Asahi Remix 44
Kernel: 7.1.6-400.asahi.fc44.aarch64+16k
fex-emu: 2604-1.fc44.aarch64
mesa-vulkan-drivers / mesa-libgbm: 26.1.5-1.fc44.aarch64
muvm: (installed via dnf install steam, exact version TBD — muvm --version doesn't print one directly, only accepts subcommands)
Steps to reproduce:
Fresh install via sudo dnf install steam -y on a clean Fedora Asahi Remix 44 system.
Run steam from a terminal.
Steam's own connection log shows connectivity tests (IPv4 + IPv6 HTTP + IPv6 UDP) all succeeding, and the login window is created and shown (WasHidden 0 in webhelper.txt).
Despite this, the GUI remains stuck indefinitely on "Waiting for Network," and the separate Python/PyQt6 launcher splash never dismisses either.
What I've ruled out:
DNS/networking: resolvectl status and curl -4/curl -6 confirm working IPv4 connectivity; Steam's own internal connectivity tests pass.
Memory pressure: free -h shows ~5.5Gi available, 0 swap used during the hang.
-cef-disable-gpu (Steam flag): no change in behavior.
LIBGL_ALWAYS_SOFTWARE=1 exported before launching steam: no change in behavior (though I can't confirm this variable actually propagated into the guest VM through the muvm/FEXBash launch path).
Debug findings:
Running with RUST_LOG=debug shows muvm's krun_devices::virtio::gpu::worker in what looks like a livelock: it repeatedly logs fence called: id=N against a mostly-static, slowly-growing list of fence IDs (e.g. 23, 32, 49, 142, 372, 752, 1857...) at extremely high frequency (thousands of times per second), with old fence IDs never appearing to retire. CPU usage on the muvm process stays pinned at 50%+ the entire time the UI is hung. Sample excerpt attached (steam-debug.log).
muvm-debug.log
(Steam's log failed to upload so pardon me for compressing it)
steam-debug.zip
NOTE: This report was written by Claude. I cannot guarantee that it is entirely true but I have verified it to the best of my ability.