Whole-VM wedge recurred on 2.2.3: blocking open() still on the vCPU thread

[owahltinez]

Follow-up to #2593, which was closed as fixed in v2.2.2. Same failure on 2.2.3 — the blocking open() is still on the vCPU thread.

OrbStack 2.2.3 (2020300) c83556b0 / macOS 26.5.2 (25F84) / M4, 16 GiB / guest kernel 7.0.14-orbstack-00380-ga7e0a2dc9535, 10 vCPUs.

Wedged 18:52:29–19:37:11 local on 2026-08-19, ~45 min. docker and orb status hang, vmgr at ~790% CPU, 37 hang samples. Host side, vcpu7, 689 of 689 samples:

689 Thread_4415934: vcpu7
+     ... 9 frames in OrbStack Helper ...
+                       689 open  (in libsystem_kernel.dylib) + 64
+                         689 __open  (in libsystem_kernel.dylib) + 8

Guest side, all 10 stall reports on CPU 7 in one grace period, counters frozen from first to last:

[644184.816960] rcu:  7-...0: (16 ticks this GP) idle=0834/1/0x4000000000000000 softirq=439232/439234 fqs=10032
[644184.817007] rcu:  (detected by 8, t=90007 jiffies, g=1593677, q=55228 ncpus=10)
[646705.470882] rcu:  (detected by 8, t=2610649 jiffies, g=1593677, q=71448 ncpus=10)

The sampler caught the stuck CPU's guest stack this time, which #2593 was missing:

virtio_fs_enqueue_req+2008
virtio_fs_send_req+95
__fuse_simple_request+547
fuse_file_open+279
fuse_do_open+31
fuse_dir_open+75
vfs_open+279
path_openat+1051
__arm64_sys_openat+287

fuse_dir_open, so the host open() is on a directory. My FIFO guess in #2593 was wrong.

Seccomp escalates one stuck CPU into a full spin: container starts JIT a filter, which reaches __text_poke → kick_all_cpus_sync and waits for every CPU to ack. CPU 7 never does, so each start parks another vCPU in smp_call_function_many_cond — ~240 of 334 guest stack dumps sit there. That's the 790% versus ~200% in #2593, and it means the VM degrades progressively under restart policies rather than losing one CPU.

Separately, the disk warning misdiagnoses this. The health check fails 27 times with Post "http://vcontrol/disk/report_stats": context deadline exceeded, and OrbStack put up a dialog asking whether my disk was full. It wasn't — 45 GiB free on the host volume, 41 GiB on the OrbStack volume. That timeout is a symptom of the wedged vCPU, so the dialog sends you looking at storage. I dismissed it and the VM recovered within seconds; previous incidents stayed wedged for hours untouched, so that path may be worth checking.

Trigger unchanged: a throwaway container joined the bridge at 18:51:09 and was destroyed moments later, first stall detection 80 s after. Checked after recovery — no nested mounts under the shared trees, no dataless directories, no leftover FIFOs or sockets, no symlink into the OrbStack NFS mount at ~/OrbStack.

Redacted orb report: https://gist.githubusercontent.com/owahltinez/e4fd6f49b65afc75f1b907d2646f78c6/raw/orbstack-diagreport-redacted.zip. Dropped netstat_rn.txt and scutil_dns.txt, replaced my username and container names, collapsed pre-hang krpc: dref failed paths. Kernel logs, stalls, both sample captures and the .orbprof files unmodified.