You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
VM hangs with RCU stalls: vCPUs stuck in kick_all_cpus_sync during seccomp BPF JIT, 3 vCPUs never respond (2.2.3, M4) #2769
About 35 minutes after a normal startup, the OrbStack VM hangs completely. All containers become unreachable, the GUI shows nothing unusual, and orb report hangs without output. orb stop cannot stop the VM (graceful stop timed out, forcing), and the processes have to be killed manually. This has happened several times.
The guest kernel reports RCU stalls on CPUs 2, 4 and 6. vmgr's stack sampling shows the other vCPUs spinning while they wait for IPIs that never complete:
vCPU 0 and 5: smp_call_function_many_cond ← kick_all_cpus_sync ← __text_poke ← bpf_arch_text_copy ← bpf_int_jit_compile ← bpf_prepare_filter ← do_seccomp (a container installing its seccomp filter)
vCPU 3: smp_call_function_single ← sync_rcu_exp_select_node_cpus (expedited RCU waiting for the same CPUs)
vCPU 1: nmi_trigger_cpumask_backtrace (the stall detector)
vCPU 7: idle (cpu_do_idle)
vCPU 2, 4, 6: absent from every sample, and the same CPUs RCU reports as stalled
So 3 of the 8 vCPUs stop acknowledging IPIs entirely, while one vCPU stays idle and healthy. The guest shows no sign of OOM: no OOM killer, no killed processes. The "OOM is now expected behavior" message comes only from the generic RCU starvation warning.
Timeline (local time, UTC+1)
09:03:04: VM starts normally (Docker containers: immich, n8n, nightscout and a small custom stack)
09:38:06: first sampling stacks due to VM hang, and the guest reports rcu: INFO: rcu_sched detected stalls on CPUs/tasks: 2 4 6 (t=90004 jiffies)
09:38 to 11:35: health check failed ... vcontrol/disk/report_stats: context deadline exceeded roughly every minute, with 93 stack samples in total
11:35:32: graceful stop timed out, forcing, after which the VM still does not stop
Environment
OrbStack 2.2.3
Guest kernel 7.2.12-orbstack-00394-gbecdd6130068, 8 vCPUs, Rosetta enabled
macOS 27.0.1 (26A434)
MacBook Air, Apple M4 (4P + 6E cores), 24 GB RAM
A UTM VM (6 GB RAM) was running at the same time
Activity
TyceHerrman commentedon Oct 26, 2026
could this be a duplicate of #2659