Environment
- macOS 26.5.2, Mac mini M4 (10-core, 16 GB unified memory)
- OrbStack 2.2.3 (build 20963), Docker-only mode, arm64 Linux guest (kernel 7.0.14-era)
- Reproduced with Jellyfin 10.11.11 (Docker, .NET 10). .NET 8 apps (Sonarr/Radarr/Bazarr) are NOT affected.
Summary
After auto-updating to v2.2.3, .NET 10 applications crash intermittently with SIGILL (exit 132). The guest kernel advertises HWCAP2_SME/HWCAP2_SME2 but the advertised instructions are not actually executable — every SME or SVE instruction traps to SIGILL. Downgrading to v2.2.2 completely fixes it.
Evidence 1: Impossible HWCAP combination
v2.2.3 guest /proc/cpuinfo Features:
fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt
fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb dcpodp flagm2
frint i8mm bf16 ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32
sme2 smei16i32 smebi32i32
getauxval(AT_HWCAP2) = 0x1a03f986181 → HWCAP2_SME (bit 23) and HWCAP2_SME2 (bit 37) are set, but HWCAP_SVE (bit 22) and HWCAP2_SVE2 (bit 1) are NOT. On real hardware, SME requires SVE — this combination cannot exist on a physical CPU, and it breaks user-space feature detection.
Evidence 2: Advertised instructions trap
A minimal C program executing the advertised instructions (with a SIGILL handler):
asm volatile(".inst 0x04e0e3e0"); // CNTD x0 (SVE)
asm volatile(".inst 0xd503437f"); // smstart (SME)
asm volatile(".inst 0xd503427f"); // smstop (SME)All three raise SIGILL (signal 4) in the v2.2.3 guest. After downgrading to v2.2.2 the HWCAP bits are gone entirely (Features end at ...i8mm bf16 ecv afp).
Evidence 3: Where Jellyfin died (gdb)
Running Jellyfin 10.11.11 under gdb batch mode, the crash caught:
Program terminated with signal SIGILL, Illegal instruction.
pc 0x0000ffffa6792d40 (libc.so.6, offset 0x82d40)
=> 0xffffa6792d40: ret <- perfectly legal instruction
#0 libc.so.6
#1 libc.so.6 (0xffffa679ae38)
#2 libcoreclr.so (0xffffa57d51fc)
The faulting "instruction" is a ret inside glibc's __lll_lock_wake_private (futex wake on mutex unlock) — a file-backed page that never changes. The D-side read shows valid code; the I-side fetch got garbage. This looks like VM-level instruction-fetch/cache coherency corruption rather than a genuine undefined instruction.
Impact
- Jellyfin (only .NET 10 workload on this host) crash-looped for a week: exit 132, anywhere from 13 seconds to ~3 hours of uptime, always SIGILL, no managed exception or core dump (DOTNET_DbgEnableMiniDump does not fire).
- Crash locations varied: startup tasks, EF Core queries, plugin loading, glibc mutex/futex paths.
- Kernel log showed persistent
Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF messages alongside.
Workaround
Downgrade to v2.2.2 (CDN still serves the old DMG: https://cdn-updates.orbstack.dev/arm64/OrbStack_v2.2.2_20903_arm64.dmg) and disable auto-update. Since the downgrade, Jellyfin has been stable for 6+ hours of active use (transcoding, playback, library browsing) with zero SIGILLs.
Request
Either make SME support actually execute the advertised instructions (SVE/SME state enabled end-to-end in the kernel/VM), or don't advertise HWCAP2_SME until it works. A quick v2.2.4 revert of the SME feature would unblock everyone affected.
Environment
Summary
After auto-updating to v2.2.3, .NET 10 applications crash intermittently with SIGILL (exit 132). The guest kernel advertises
HWCAP2_SME/HWCAP2_SME2but the advertised instructions are not actually executable — every SME or SVE instruction traps to SIGILL. Downgrading to v2.2.2 completely fixes it.Evidence 1: Impossible HWCAP combination
v2.2.3 guest
/proc/cpuinfoFeatures:getauxval(AT_HWCAP2)=0x1a03f986181→ HWCAP2_SME (bit 23) and HWCAP2_SME2 (bit 37) are set, but HWCAP_SVE (bit 22) and HWCAP2_SVE2 (bit 1) are NOT. On real hardware, SME requires SVE — this combination cannot exist on a physical CPU, and it breaks user-space feature detection.Evidence 2: Advertised instructions trap
A minimal C program executing the advertised instructions (with a SIGILL handler):
All three raise SIGILL (signal 4) in the v2.2.3 guest. After downgrading to v2.2.2 the HWCAP bits are gone entirely (Features end at
...i8mm bf16 ecv afp).Evidence 3: Where Jellyfin died (gdb)
Running Jellyfin 10.11.11 under gdb batch mode, the crash caught:
The faulting "instruction" is a
retinside glibc's__lll_lock_wake_private(futex wake on mutex unlock) — a file-backed page that never changes. The D-side read shows valid code; the I-side fetch got garbage. This looks like VM-level instruction-fetch/cache coherency corruption rather than a genuine undefined instruction.Impact
Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PFmessages alongside.Workaround
Downgrade to v2.2.2 (CDN still serves the old DMG:
https://cdn-updates.orbstack.dev/arm64/OrbStack_v2.2.2_20903_arm64.dmg) and disable auto-update. Since the downgrade, Jellyfin has been stable for 6+ hours of active use (transcoding, playback, library browsing) with zero SIGILLs.Request
Either make SME support actually execute the advertised instructions (SVE/SME state enabled end-to-end in the kernel/VM), or don't advertise HWCAP2_SME until it works. A quick v2.2.4 revert of the SME feature would unblock everyone affected.