The Legion 5 15IAX10 Hackintosh in late October 2026: what the public web knows about the Arrow Lake-HX stalls, NvGfx, MT7925 and macOS 26.7.2: Supersearch Research Dossier

• Generated: 2026-10-27 (every "checked" date in this document is this day unless a line says otherwise)
• Mode: Exhaustive (15 research agents, then an audit, a contradiction pass with independent re-verification, a timeline pass, a practitioner pass, four theme syntheses, a devil's advocate and a quality gate)
• Quality gate: PASS for use as a planning document (WARN on source diversity and search reach); scores in the methodology section
• Sources included: 229 in the sources table (337 unique URLs were read across the research reports)
• S and A tier sources: 108 in the sources table (about 170 of the 337 URLs after the audit's stricter regrade)
• Subject machine: Lenovo Legion 5 15IAX10 (Core Ultra 9 275HX, Intel iGPU 8086:7D67, RTX 5070 Laptop GB206, MediaTek MT7925, Realtek ALC257) on macOS Tahoe 26.7.1 (25G241) through OpenCore, running the project's own NvGfx, XeGfx, MtkWlan/MtkWlanNative and MtkBt drivers.

The public web has no report that matches the project's I-116 stall. There are Linux reports on the same family of parts, mostly Arrow Lake-H and Meteor Lake rather than the 275HX die, where the GuC firmware acknowledges a TLB invalidation about 2.3 seconds late and some machines then freeze. Those freezes keep the kernel alive (SysRq works, the journal keeps writing) and the NMI watchdog never fires. The I-116 panic is different: one CPU never reaches the rendezvous and the other 23 do not answer even an NMI. The only confirmed root cause for the Linux late acknowledgements is stale CPU cache lines of firmware-written memory on the standalone media GT, fixed in a commit that reaches Linux 7.4, and XeGfx skips the media GT in every recorded boot. The fwtable_write32 frame in the I-116 panic is most plausibly the GuC doorbell write, and Intel's own source marks that register's forcewake handling as a FIXME workaround for delays when the platform changes sleep state. That is a lead and not a diagnosis: in only one of four recorded panics is the panicking CPU in driver code, that CPU had also taken an interrupt and may be a waiter, and rivals that the public record cannot separate include a System Management Mode stall (the project's NVRAM trace writes every 250 ms and has been on in every guarded run) and the project's own power kext, which was loaded in every run.

The platform research found no firmware fix to wait for. Lenovo's S2CN26WW is the newest BIOS for this machine and only updated CSME. Intel's specification update (revision 024, October 2026) still lists erratum ARL037 (a core can hang entering or leaving C6 or deeper, with no machine check logged) as "Planned Fix" on the HX line, but Intel calls it synthetic, it hangs one core, and the panic needs a machine-wide stall. Newer microcode (0x121, 0x122) exists against the 0x11b this machine runs, with no public text tying it to the erratum. For I-118 (resets 15 to 40 seconds after OpenCore's ExitBootServices line, after two Linux probe sessions) nothing public matches: no one reports an Arrow Lake reset as opposed to a hang. The candidates are leftover state from the previous OS (microcode, GSP/WPR2, a Linux-armed watchdog, VT-d state), all supported by analogy only, and the log line "EXITBS" marks where OpenCore's log stops, not where the machine died.

On the graphics side, NullMoth's current release (2.6.2) carries the same driver as 2.5.5, and the project's 2.6.2 rebase is built but not booted (N-294). Independent evidence for the NVIDIA problems (drag stalls, HiDPI, HDR, Chrome flicker, MPS translation) is thinner than it looks and some of it is the project's own account. Several Intel Xe on macOS efforts are active (ArrowWhatever on the same die, zep245's Tiger Lake port, jwx29's fork, VedCloud's Meteor Lake notes); the only soak figure on this die is a self-reported 40 minutes, from a patched copy of the project's own shim. ArrowWhatever fixed a userptr unwire race that the project's code also contains, with a different failure signature. zep245 found NVRAM trace writes to be a hot-path cost, which has never been tested in XeGfx and is a switch away; if native NVRAM writes run in System Management Mode, that switch is also a test of the stall.

For macOS, 26.7.2 is build 25G332 (released 2026-10-26); 25G330 was the third release candidate, and the project's tracker and one public reply use the wrong number. The kernel collections of 25G332 can be rebuilt without installing anything, by applying Apple's own BXDIFF50 delta patches to the files already on the Mac, and the result verifies against hashes. A first ABI comparison shows unchanged class sizes and vtables with three small differences, so the native Wi-Fi front end's refusal on 25G332 looks like a gate decision more than a proven break. Bluetooth reports mix a probable stale byte pin with a card-state fault. Intel Macs end at Tahoe, so every point release is a recurring cost for kexts that depend on private layouts.

• I-116 has no public twin. Rank the experiments by cost: one session at stock LegionCpuPower limits with the SMI count read, one run with the NVRAM trace off, passive per-CPU and TSC timing around the doorbell and forcewake waits so the missing CPU gets a name, machine-check banks after the next stall, and only then the waker by gtawake 2x2 with a stopping rule. Do not write that I-116 is "the 2.3 second cache bug", and do not use tlbto_us=0, which removes the panic string.
• Do not wait for a BIOS or microcode fix, and do not load newer microcode through OpenCore as a mitigation. None is published, and early loading over an older BIOS revision broke other Intel parts in 2026.
• For I-118, make the cold-versus-warm state a recorded column, record the microcode revision and the watchdog state before and after each Linux probe, and fully power off after Linux before testing macOS.
• Stay on 25G241 and prepare 25G332 offline: correct the "25G330" records, review the three ABI differences, explain why the live bluetoothd does not match the OTA record, and ask reporters for the Wi-Fi refusal reason.
• Treat the self-reported peer projects as claims. Port the userptr race fix as the project's own code, and do not log it as an I-116 attempt.
• Nothing in this dossier needs an outside post; anything on a public tracker is Bash's decision.

1. Intel treats the doorbell write as an unfinished workaround. The H2G doorbell (register 0x1901f0) is in a range that normally needs no forcewake, but Intel added GT forcewake for it because the write can be delayed when the platform enters or leaves a sleep state, and marked it FIXME pending an official workaround. A separate commit says the same about multicast steering registers. This is the best mechanism-level match for the I-116 frame, and it points below the driver. Sources: 6d46d09a0d7d, 8fa1c7cd1fe9. Confidence: Medium (the link to I-116 is inference; the panic carries no register offset).
2. The one root cause everyone cites is scoped to a GT that XeGfx does not start. Wa_22016122933 concerns memory shared with the media GuC, XeGfx logs "Skipping GT1" in seven boots, and the supporting measurements come from Arrow Lake-H machines. Its own reporter saw a silent death with the fix applied. Sources: xe commit d5b0bf3f37f1, xe 8678. Confidence: High on the scope, Medium on the inference that it cannot be ours.
3. Same-silicon Linux freezes leave the kernel alive; I-116 does not. Reports on 7D67 and 7DD1 end with a live kernel or a silent power-off with nothing captured, and none carries a per-CPU state comparable to the I-116 panic. Sources: xe 9168, i915 16937. Confidence: Medium-High.
4. A GT hold tests a different failure class than the one Intel is fixing. The Tiger Lake macOS port and the FreeBSD maintainer both stopped hangs by keeping the GT awake, but both are other silicon and neither had a controlled A/B, and the owner of xe 8678 held forcewake on Arrow Lake while the late acknowledgements continued. A hold is a test for a CPU-side or sleep-state class (that I-116 is in it is assumed, not shown), and a negative result on one must not be read across. Sources: drm-kmod 457, xe 8678. Confidence: Medium.
5. The panic is a late detector and the stall length is unknown. The rendezvous spin is bounded at about 2.0 seconds, so "2 s" is a timeout and not a measurement; the 27 s figure in one run record contradicts the saved progress file; the panicking CPU is a waiter in most runs. Naming the missing CPU is the most valuable extra datum, and the SMI count (MSR 0x34) separates an SMM stall from an uncore hang. Sources: xnu mp.c, LKML on stuck MMIO. Confidence: High on the arithmetic.
6. Shim semantics are a live candidate beside silicon. FreeBSD found three LinuxKPI gaps behind GuC scheduling failures on Meteor Lake, and the same silicon ran a 40-minute soak under a patched copy of this project's own shim (self-reported, two days old, inside the project's own spread of times to stall). The stand-ins for in_atomic, irqs_disabled and rcu_preempt_depth decide whether a full H2G buffer sleeps or spins. Sources: freebsd-src 4f2f26fb1e8a, ArrowWhatever. Confidence: Low.
7. ARL037 fits the first phase of the panic and not the second. One core hanging with no machine check matches the single missing CPU; it does not explain 23 CPUs ignoring an NMI, Intel calls it synthetic, and four freezes happened on Linux with a C-state limit of 2 and display power states off. Sources: Intel 834774 rev 024, xe 9168. Confidence: Low.
8. No firmware fix is known, so there is none to wait for. S2CN26WW is the newest BIOS (checked), microcode 0x121 and 0x122 have no public mapping to ARL037 (an absence claim from one search pass), and loading microcode early over an older BIOS broke Meteor Lake machines in August 2026. Sources: Lenovo readme, microcode releases, microcode issue 112. Confidence: Medium (the BIOS fact is High; the absence of a fix is one search pass).
9. For I-118 the unrecorded variable is cold versus warm. Intel's triager asks for it on the one 7D67 probe-failure thread, NVIDIA's WPR2 reports hinge on it, and the project's failing and passing boots differ in that column. Every candidate (microcode persistence, WPR2, a Linux watchdog, VT-d) is an analogy. Sources: i915 16052, open-gpu-kernel-modules 1353. Confidence: Medium.
10. The Intel Xe peers fixed glue-code bugs, which are cheap to close. The userptr unwire race is a lock gap that exists in XeGfx and does not match the I-116 signature. The NVRAM trace cost is a hot-path problem, and because native NVRAM writes on EDK2-derived firmware normally go through System Management Mode (unverified for this BIOS), the trace is also a candidate cause of the stall, and more than a tidy-up. Sources: ArrowWhatever userptr note, zep245 design notes. Confidence: Medium.
11. Independent evidence on the NVIDIA problems is thin, and some of it is ours. The HDR trace and the 12-byte HiDPI finding came from the project's own account; the Chrome Graphite cure and the MPS failures have several independent reporters. The 615.71.10 and 615.78.08 source diffs show no platform logic change, and the project's one GSP control already lifts the 50 W default to 115 W. Sources: nullmoth 341, NVIDIA compare. Confidence: Medium.
12. The 26.7.2 Wi-Fi break is a gate decision first, and the gate is a safety gate. The front end refuses on the xnu tag before it looks at sizes, and the offline comparison shows unchanged sizes and vtables with three unreviewed function differences, one plausibly relevant. No 25G332 boot of the project's kexts has happened, so this stays inference. Sources: MtkNativeAbi.hpp, appledb 25G332. Confidence: Medium.
13. Tahoe is the last Intel macOS, so each point release is a recurring cost for private-layout kexts. The newest MT7925 competitor shares the per-build pin. Automating the offline kernel-collection route is worth more than any single 25G332 fix. Sources: Apple macOS page, OCLP 1183. Confidence: Medium.
14. Arrow Lake Hackintosh practice converges on VT-d off, a DMAR drop and a type-0 MADT, and this config differs in two quirk choices. Two other 275HX EFIs (not independent of one another's guide lineage) run SetupVirtualMap on without ForceExitBootServices, while this config does the opposite and keeps DMAR. None of those projects reports I-118-style resets, and this machine's normal boots pass, so a quirk A/B is a hypothesis. Sources: 1401 issue 58, ASUS FX608LP EFI. Confidence: Medium.

The run followed the six questions in the brief. Fifteen research agents each took one aspect and wrote a report; a second wave audited the sources, re-verified the load-bearing facts independently, built the timeline and collected practitioner reports; four synthesis drafts (one per theme) then combined them, a devil's advocate attacked the result, and a quality gate scored it.

The sections that follow are: the four themes (main findings, each with its evidence table rows, key insights, ranked actions and risks), the timeline, technical and operational details, the consolidated evidence table, tradeoffs and alternatives, practitioner reality, contradictions and debates, failure modes and misconceptions, gaps and limitations, the devil's advocate, consolidated actionable takeaways, methodology and the sources table.

Upstream has published evidence for two ways a GuC acknowledgement arrives late on Meteor Lake and Arrow Lake. The first is a stale CPU cache read: the GuC answers in time, but the CPU keeps reading an old empty line of the G2H buffer. Intel's xe fix d5b0bf3f37f1 (Wa_22016122933) took one reporter from 20 to 60 stalls a day to zero in six weeks over more than ten million invalidations (xe 8678). The second is a platform sleep-state delay on a write that forcewake does not cover: 6d46d09a0d7d says there "could be some delays when platform is entering/exiting some higher level platform sleep states" for the H2G doorbell.

Our signature differs from both. I-116 is a whole-machine stall, then an XNU rendezvous panic in which 23 of 24 CPUs answered and none took the NMI. The XeGfx log ring held no i915 message after GuC load (no CT timeout), and in N-288 the GPU interrupt counters kept moving with every interrupt handled. The closest local match to the second mechanism is N-287, where the panic CPU sat in fwtable_write32 under intel_guc_ct_send during an execbuffer ioctl, the doorbell path. This is inference: no public report measures that write stalling, so the link is a hypothesis.

The cache mechanism is excluded unless our shim has a GT0 analogue (1.4). A platform stall that no driver timer catches cannot be excluded, and 1.6 shows why the evidence leans that way.

Confidence: Medium (checked 2026-10-27) that these are the two documented mechanisms; Low that either explains I-116.

The panic strings read mp_rv_action() entry: 23 of 24 responses, then mp_kdp_enter() ... expected 24 acks but received 1 after 1536000000 ticks. XNU's rendezvous code uses a spin timeout of four times the lock timeout, and the NMI ack wait is half a second; at 3.072 GHz that is 2.0 s and 0.5 s. I computed (cur - start) from the N-287, N-288 and N-290 panic strings: about 6.144e9 ticks, exactly 2.0 s. The panic therefore fires at the normal timeout after the rendezvous began, not after a long stall, and how long the machine had been stuck is not in the data.

"23 of 24" means one CPU never entered the rendezvous (its id is not printed). Phase two, in which none of the other CPUs acknowledged an NMI although about 22 had entered, needs more than one stuck CPU: an SMM or SMI episode, a fabric or memory stall, or CPUs unable to take NMIs. This is inference and Unverified.

The panic CPU is a waiter, not the culprit. N-287 (about 45 s after WindowServer started): in or below fwtable_write32 + 0xfa, called from intel_guc_ct_send. N-288 (about 40 s): idle in processor_idle. N-289 (15 to 20 s): pmap_remove_range from the free worker (IOBufferMemoryDescriptor::free <- xg_vm_x_release <- __i915_gem_free_objects). N-290 (88 min, during diskutil apfs resizeContainer): storagekitd in nx_resize. One puzzle: i915 runs fwtable_write32 under spin_lock_irqsave, and the N-289 README says the shim's spinlock_enter masks interrupts, yet CPU 3 took an IPI there. Either the interrupted address is a return after the unlock or the mask is not what we think; the irqoff_check switch tests this.

Two local record problems need fixing before publication. The N-287 README claims a 27 s guard-loop gap and that the unified log stops at 11:19:06, but the saved N-287/guard/ws-progress.txt has lines about every 5 s through 11:19:38 with IOPresentment counts still rising, so any "27 s stall" in the aspect reports is softened here. And N-290 ran 0.0.43 with a 20 ms interrupts-off watchdog and survived 88 minutes; the wakeup may make I-116 rarer, which is not proven.

Confidence: High (checked 2026-10-27) on the 2.0 s arithmetic from the saved panic strings; Unverified on the true stall length and the missing CPU.

The doorbell is register 0x1901f0 (GEN11_GUC_HOST_INTERRUPT), written by intel_guc_notify under the CT buffer's spin_lock_irqsave. 6d46d09a0d7d (authored 2024-01-19, committed 2024-01-24, v6.9) added GEN_FW_RANGE(0x1901f0, 0x1901f3, FORCEWAKE_GT) /* FIXME: WA to wake GT while triggering H2G */. Its text says the register sits in the sgunit and "is not affected by forcewakes", and that "this will have an official WA soon". The accurate wording is "a FIXME workaround takes GT forcewake for that offset", not "the doorbell needs forcewake". Our drm-kmod base c16de0f has the range; xe's xe_guc_notify() in xe_guc.c is a plain MMIO write without it.

The sister commit 8fa1c7cd1fe9 (GT forcewake during MCR steering) cites the same cause and says "an upcoming pcode firmware update will also be necessary to provide the other half of this workaround". A pcode half implies a BIOS or IFWI dependency no kext can supply, which fits Red Hat bug 2463170 (reported fixed by a kernel update plus a Lenovo BIOS PCODE update).

fwtable_write32 takes uncore->lock, calls __force_wake_auto, and each ack wait is 50 ms per pass with fallback passes. By my arithmetic a worst case exceeds one second (inference), enough to keep other CPUs waiting on that lock. This machine has BIOS S2CN26WW and microcode 0x11b; 0x121 and 0x122 exist, but no release note ties either to this symptom.

Confidence: High (checked 2026-10-27) that the commits say this; Medium that the pcode dependency applies to this laptop.

d5b0bf3f37f1 (committed 2026-09-24, merged via drm-next on 2026-10-24, queued for 7.4, not in v7.3) covers the standalone media GT, media version 13.00, on Meteor Lake and Arrow Lake. Memory shared between the CPU and the media GT's GuC (CT buffers, log, ADS, SLPC) must not be CPU-cached, or the CPU reads a stale empty CTB until the line is evicted and the 2.25 s fence timeout fires first. A coherent WB|COH_2WAY mapping did not help (2290 ms); a CPU-WC variant works; swapping in XE_BO_FLAG_FORCE_WC naively flips the GGTT side to WB and stalls return (xe 8678). A follow-up patch on the intel-xe list (403 on fetch, described from the corpus) says uncached-only regresses probe to about 3.1 s and WC fixes it. i915 has carried the workaround since a161b6dba6e0 (v6.5-rc1), keyed on media version 13.0 and GT_MEDIA.

The XeGfx log reads Skipping GT1 (Standalone Media GT) - MEI driver not available on FreeBSD, matching drm-kmod PR 418. The workaround's scope is therefore absent from our run, and "I-116 is the 2.3 s cache bug" must not be written anywhere. Even with the fix, media-GT "not started" timeouts persist at about one per 100 h.

C9 in the contradiction file is a Low-confidence analogue on GT0: if the shim maps GuC shared pages cacheable while the GGTT side is snooped differently, a stale-line effect is conceivable. Nothing tests that. Reading how xg_vm.c maps CT pages and which PAT the GGTT entries use would settle it without a boot; the XeGfx VM notes say a page run's kernel mapping is write-back.

Confidence: High (checked 2026-10-27) for the workaround's media-GT scope; Contradicted as an explanation of I-116; Low for a GT0 shim analogue.

The cached notes on xe 8678 hold the most direct A/B on Arrow Lake. Note 1 (2026-07-30): forcewake held across the whole GT, GT C6 residency delta zero, still nine timeouts. A 250 ms doorbell re-kick shortened most acks to 15 to 276 ms, but severe episodes ignored 8 to 9 consecutive doorbells (worst 5996 ms); the owner first read that as GuC-side, then the list confirmed the stale-cache cause (note 15). So "a forcewake or RC6 hold stops the stall" is Contradicted for the late-ack class: late acks and a CPU-side blocked doorbell write are two separate mechanisms.

Note 26 says the series "would not have prevented" a GT0 wedge. Note 28 (2026-09-19) reports the owner's own 7d51 machine locking completely on 2026-09-16 on a kernel with the workaround, leaving no log line; the NMI watchdog and pstore captured nothing. Note 30 speculates (tier B) that a hang in a GPU power or fabric handshake "can take the whole package down". Other Arrow Lake H machines with backports ran clean. This is the closest public analogue to our silent phase, and it is one report without a root cause.

Confidence: High (checked 2026-10-27) on what the notes say; Medium that they transfer to 7D67.

xe 9168 (device 7d67, a 285HX mini PC) shows freezes with a live kernel: SysRq-S works, nmi_watchdog=panic never fires, the journal keeps writing, and a TLB timeout precedes the freeze by minutes to hours. A 2026-10-27 comment reports DC, PSR, FBC, panel replay and DMC wakelocks off plus intel_idle.max_cstate=2 do not help. That is a different class from N-290, where the CPUs go silent. i915 16937 (ARL-P) is a hard hang with a silent NMI watchdog and about 1000 DC transitions a minute before death, not cured by PSR, FBC, max_cstate=1 or removing the NVIDIA card. i915 13926 has forcewake and TLB timeouts with one CPU stuck in VT-d qi_submit_sync. No report matches 23 of 24 CPUs plus NMI silence on 7D67 in any operating system.

For the silent phase the best public statement is Gleixner's on another platform: a machine can stall on outstanding MMIO transactions "w/o further notice" and "the NMI is just a red herring" (LKML, 2026-01-13). That fits a CPU parked in an uncore write (N-287) and silent peers, but it is a model, not a measurement. Gleixner's text concerns HPET clocksource time failing to propagate after a hung PCI config read, so the remark about the NMI describes that path and does not transfer as a rule. The N-287 panic CPU was also running interrupt code (cpu_signal_handler sits above the fwtable_write32 frame in the saved panic string), so it may have been a waiter that happened to be in driver code. The same silicon and macOS build did a 40-minute soak with zero stalls under a patched copy of this project's own XeGfx shim (ArrowWhatever, tier B, self-reported, created 2026-10-25), while N-290 died at 88 minutes under heavy I/O, so the trigger is setup-specific.

Confidence: Medium (checked 2026-10-27) that the silent phase has no direct public analogue; Low on any specific cause.

intel_gt_invalidate_tlb_full in intel_tlb.c is gated by wedged state, seqno coalescing and with_intel_gt_pm_if_awake, so not every free sends an H2G ("every free" claims are overstated). It takes the GuC path only if HAS_GUC_TLB_INVALIDATION and the GuC is ready, otherwise mmio_invalidate_full, which takes FORCEWAKE_ALL and the MCR lock and waits 100 us then 4 ms per engine. The GuC path (intel_guc_submission.c) sends through intel_guc_send_busy_loop and waits about 2 s before logging "TLB invalidation response timed out".

An aspect report called clearing has_guc_tlb_invalidation a one-flag experiment. That is wrong. 2d6e2b10a773 says Meteor Lake "is presently the only platform that requires it for any purpose", and af58ee227662 says GuC-based GGTT invalidation is incompatible with MMIO invalidation. In intel_ggtt.c, guc_ggtt_invalidate sends through the CT per GT, a second H2G source beside the free path. Clearing the flag could leave GGTT and PPGTT paths inconsistent. This is a Medium-confidence reading of commit text and source, untested.

N-289 puts the free worker's pmap_remove_range, an XNU TLB shootdown, under the panic CPU. A shootdown is an IPI wait on every CPU, so one CPU stuck in an uncore write makes the next shootdown stall the rest (inference).

Confidence: Medium (checked 2026-10-27), from source and commit text read directly; fallback safety on 7D67 untested.

The relevant changes are generic: deeee411a975 (2020, per-object cond_resched in __i915_gem_free_objects) and the 2021 series that flushes TLBs before releasing backing store (7938d61591d3 and neighbours), which made the free worker the main invalidation producer. The Tiger Lake port on XNU (IrisXe-macos-driver, tier B) had a preemption_level -1 panic from cond_resched (ggtt_pin -> shmem_get_pages -> shmem_sg_alloc_table -> cond_resched -> sched_relinquish -> thread_block), traced to an earlier lock imbalance and cured by turning off a per-CPU curthread cache. That points at the shim's critical-section accounting, not at the free worker. For us the N-289 panic CPU was already inside the shootdown, so cond_resched is not a cure; limiting how much one free pass does is a smaller experiment than touching the TLB path.

Confidence: Medium (checked 2026-10-27) that no ARL-specific free-worker fix exists; Low that throttling would change I-116.

GuC submission is the Linux default on Meteor Lake and Arrow Lake, and xe dropped force_execlist (b623bd790db0). XeGfx's HOW-IT-WORKS says that drm-kmod disables the GuC by default, that these parts have no execlist submission (the no-GuC path returns -EIO and the GT is declared wedged), and that XeGfx sets enable_guc=3. "Switch to execlists" is therefore not an available A/B on 7D67; whether a HuC-only enable_guc=2 mode works is unsettled. FreeBSD defaults GuC off because of shutdown and reboot freezes (drm-kmod 399).

I checked the base c16de0f (2026-10-08, "Reduce diff with Linux 6.14"): DUAL_QUEUE_WA is set for graphics IP 12.70 or newer with CCS, as in ff868667a4f9, and it is engine-level, not whole-machine. Render power gating stays excluded for IP 12.70 to 12.74 in its intel_rc6.c, following 25e7976db86b (forcewake ack timeouts in CI); upstream limited that exclusion to selftests in 0a4ae87706c6 (v6.16). So we run the conservative setting upstream later dropped, with RC6 and media power gating on.

GuC 70.53.0 is what linux-firmware ships and our log shows. 70.74.0 is in drm-firmware and runs in Intel CI on Meteor Lake, but 70.72.1 behaved like 70.53.0 in xe 8678, so a firmware swap is low yield.

Confidence: High (checked 2026-10-27) for DUAL_QUEUE_WA and render-PG state, read from source; Medium for the firmware conclusion.

drm-kmod 457 (2026-08-30) diagnosed a GuC "Bad context sched_state" hang that sleep 3000 < /sys/kernel/debug/dri/0/i915_forcewake_user cured. Two causes were named: LinuxKPI runs the handler in an ithread, not a hardirq filter, so RC6 entry and exit happens during the delay and the GFX_MSTR_IRQ read returns invalid state; and the preemptible handler makes the masked window long. This is a correlation without a controlled A/B, and a later cancel_delayed_work_sync fix was called cleaner.

The fixes are small and checkable. FreeBSD 79e290d96786 (2026-09-13) corrected an inverted cancel_delayed_work_sync() return value, found while debugging GuC scheduling failures. 0d022baa047a runs irq_work callbacks under RCU. 4f2f26fb1e8a implements irqs_disabled and names intel_guc_send_busy_loop as a user, which matters because intel_guc.h picks sleeping or an unbounded cpu_relax() retry from in_atomic(), irqs_disabled() and rcu_preempt_depth(). OpenBSD bd7ea2868af8 polls CT receive while waiting. FreeBSD agreeing with Linux is not a second opinion; it is the same code.

The Tiger Lake port on XNU adds a ladder (nmx_i915_awake.c): a GT power reference alone still froze, adding intel_uncore_forcewake_get(FORCEWAKE_ALL) was clean, and the freeze needed paced 60 fps frames, never back-to-back submission. One machine, no controlled A/B. XeGfx 0.0.44 and 0.0.45 already carry matching switches (gtawake=1, gtawake=2, irqoff_check=0), built but not booted (XeGfx).

Confidence: Medium (checked 2026-10-27); commits verified, effect on I-116 is inference.

Intel's specification update 834774 rev 024 lists ARL037, "A Core May Hang When Entering or Exiting C6 or Deeper Sleep States", as Planned Fix on HX (Fixed on H, N/A on U; an earlier aspect report had the columns wrong). Per Intel it is synthetic-only and hangs one core, not 23 of 24, so it is a weak fit. i915 16052 (7d67 probe-time all-ones MMIO reads, Intel text marked LLM-assisted) is a power-sequencing race with a request for cold versus warm results; the contradiction file says to drop it from the TLB-freeze list because it relates to I-118. Microcode and BIOS are variables we have not moved, and moving them needs Bash's OK.

Confidence: Low (checked 2026-10-27) that errata explain I-116; High on the stated erratum status.

1. Holds test one failure class and not the other. The Tiger Lake port on XNU was cured only when it held forcewake on all domains (zep245) and FreeBSD's forcewake_user workaround stopped a GuC scheduling hang (drm-kmod 457), yet the xe 8678 owner held forcewake and the ack stall went on. A hold is a test for the whole-system class (ours is assumed, not shown), not the late-ack class, and a negative result on one must not be read across. The positive evidence comes from two ports on other silicon (Tiger Lake, Meteor Lake) and the one hold on Arrow Lake failed. Confidence: Low to Medium.
2. A platform cause is not excluded, though no newer BIOS or microcode path exists on macOS. Intel's two FIXME commits (6d46d09a0d7d, 8fa1c7cd1fe9) call themselves half a workaround awaiting pcode, and a silent platform death with the cache workaround applied (xe 8678, note 28) suggests a path no kernel patch reaches. BIOS and microcode are variables this project has never moved, and both statements here are absence claims from one search pass. Confidence: Low to Medium.
3. Our observables do not exclude a stalled MMIO transaction, and it fits them better than an ack delay, but it is a model. The N-287 panic CPU sits in an uncore write path yet had also taken an IPI, so it may be a waiter; the panic CPUs of N-288 to N-290 were in idle, in pmap_remove_range and in APFS reads, so only one of four runs shows the driver; the silent CPU is unnamed. System Management Mode (an SMI stops every thread while the TSC runs on), an EC or firmware event, and a failed deep-idle wake are rivals that the data do not separate. The 2.0 s rendezvous timeout and the NMI silence resemble Gleixner's description, while every upstream mitigation targets ack delays. TSC deltas around the doorbell and forcewake waits are the discriminating measurement, together with the SMI count (MSR 0x34). Confidence: Low (inference).
4. A shim-semantics cause is a live candidate, not a favourite. FreeBSD found three LinuxKPI gaps behind GuC scheduling failures (79e290d96786, 4f2f26fb1e8a), and the same silicon ran a 40-minute soak clean under a patched copy of our own XeGfx shim (ArrowWhatever, self-reported and not independent of our code; a 40-minute run also sits inside our own spread of 900 s passes and an 88-minute death). Our in_atomic, irqs_disabled and rcu_preempt_depth stand-ins steer intel_guc_send_busy_loop between sleeping and spinning. Confidence: Low. Its passive checks (reading the stand-ins) come before any boot test.
5. Heavy I/O and the free worker meet at TLB shootdowns. The free worker became the main invalidation producer in 2021 (7938d61591d3), N-289 shows it inside pmap_remove_range, and N-290 died during an APFS resize. A CPU stuck with interrupts masked makes every other CPU's shootdown wait, so I/O load may raise the chance of a wedge without being its cause. Confidence: Low (inference).

Intel's Core Ultra (Series 2) Specification Update (document 834774, revision 024) lists ARL037: a core can hang entering or leaving C6 or deeper, no machine check is logged, Intel saw it only in synthetic conditions, and a BIOS workaround is possible. The status row is Planned Fix for S, S 6+8 and HX/HX Plus, N/A for U, Fixed for H (Intel 834774 rev 024). It was added in revision 008 (May 2025) and updated in revision 012 (October 2025) (same PDF). So on our 275HX it is acknowledged, unfixed in silicon as of October 2026, and left to firmware. Aspect 2 had the column mapping reversed (fixed on HX); the spec text and Aspect 5 are right, and verification pass agrees.

It fits phase 1 of I-116: the panic reports 23 of 24 responses, so exactly one of 24 logical CPUs never answered the debugger rendezvous (xnu mp.c; panic record in evidence/native/N-290/README.md). It fails on three counts. Intel says synthetic only, and our stalls come within minutes of a WindowServer session. In phase 2 none of the other 23 CPUs acknowledge the NMI, and ARL037 says nothing about healthy cores going silent (this is inference: a hung core might stall IPI delivery, but no source says so). And the waker evidence is weak: the 20 ms waker thread in XeGfx 0.0.43 coincided with one surviving session, but 0.0.43 also added spinlock and interrupt instrumentation, and the direction of the waker's effect on idle is unknown: this text reasons that a timer waking a core 50 times a second adds C6 transitions, while the N-290 README says it keeps cores out of deep idle, and neither has been measured. It is not a ranking input.

The other errata fit worse. ARL042 (package C6 exit hang, Geyserville) is Fixed on HX. ARL068 (PCIe Gen5 L1 substate exit, with THREE STRIKE and INTERNAL TIMER machine checks) is No Fix on HX, but needs a Gen5 link in L1 substates and logs an MCE; our NVMe link is Gen4, Linux logs FADT indicates ASPM is unsupported here (evidence/native/N-274/hw/dmesg.txt), and I-116 shows no MCE. ARL004 is VMD-only, ARL031/041/043/049 are H-only (same PDF). The Meteor Lake RC6 exit errata MTL037/042 cited by Aspect 4 were not re-fetched, and their relevance to our iGPU rests on shared Xe lineage (inference). The Wa_22016122933 media-GT workaround cannot be the cause because XeGfx never touches GT1 (verification pass). Intel's text names no die-to-die, ring or fabric erratum for HX.

Confidence: Low (best candidate for phase 1 only; synthetic-only wording and phase 2 count against it).

i915 16052 is an all-ones MMIO read at probe on a 7d67 iGPU (our device ID). Intel's triager called it a hardware/firmware power-sequencing race, noted LLM-assisted triage, asked for cold versus warm, dGPU disabled and another BIOS, and set the issue to close on 2026-10-27 without data. In xe 9168 the freezes keep the kernel alive, and in 8678 holding forcewake did not stop the acknowledgement stall. Verification pass therefore treats them as unlike our whole-machine stall with an xnu panic, and I agree.

The claim that 9168 rules out C-states does not hold. Its reporters are ARL-H, where ARL037 is Fixed, so they cannot test it, and the reporter who used intel_idle.max_cstate=2 with DC, PSR and FBC off still saw four power-offs on 2026-10-27, but 2.3 shows that setting leaves a core C6-class state on. What the reports show is a shared power-sequencing weakness in the 7d67 and 7dd1 families, not a CPU idle verdict. One data point from our probe: the 47-minute Linux 7.0 capture, which had no stall, logs Invalid mmio detected during user access from i915, three seconds after nouveau re-enabled the dGPU's HDA controller (dmesg; message source intel_uncore.c). One occurrence is not evidence, but it sits beside a dGPU power event, which is what Intel asked about (inference).

Confidence: Medium (issue text verified 2026-10-27; mapping to I-116 is inference).

Linux has no Arrow Lake table in intel_idle; the driver falls back to ACPI _CST and honours intel_idle.max_cstate there (intel_idle.c). An Arrow Lake report shows _CST MWAIT hints 0x0, 0x21 and 0x60 (Unraid); Meteor Lake's table uses 0x20 for C6 and 0x60 for C10 (same intel_idle.c), so 0x21 is a core-C6-class state and max_cstate=2 keeps it (inference). Aspect 4 and Aspect 15 said Arrow Lake does not use intel_idle and the knob is not the lever; the source shows the fallback, so I overrule them.

On macOS, XCPM runs under a Comet Lake CPUID spoof (Cpuid1Data 55060A00 in our OpenCore config), and LegionCpuProbe publishes no residency counters. Package C2 needs all cores in C6 or deeper and graphics in RC6 (Intel datasheet, H/U parts). The registers worth reading are the common ones: core 0x3FC to 0x3FE, package 0x3F8 to 0x3FA, 0x60D and 0x630 to 0x632, 0xE2 (C-state config, CFG lock), 0x34 (SMI count) and the MCi_STATUS banks from 0x401 (Intel SDM). Whether Arrow Lake implements each address is unverified.

Confidence: Medium (kernel source read directly; the 0x21 mapping and the MSR list on this die are inference).

We run microcode 0x11b (macOS reports 283; Linux logs Current revision: 0x0000011b with no update line, N-274 dmesg). Intel shipped 0x121 on 2026-05-12 (release) and 0x122 on 2026-08-11 (release) for the 06-c6-02 B0 part, after 0x11a (2025-11-11) and 0x11b (2026-02-10). Aspect 5 said three newer revisions; only two exist. The notes say only "Update for functional issues" and cite the same spec update, so "0x121 fixes ARL037" is a guess. Newer microcode over old firmware has broken boot on other parts (issue 112, 113).

Lenovo's S2CN26WW (readme 2026-03-24, catalog 2026-05-06) is the newest BIOS for 83F0 and changes only "Update Intel CSME", EC untouched (readme); S2CN27WW returns 404 (probe). The CSME version is unstated. Sibling Lenovo notes cite 19.0.5.x against Intel's August 2026 fix level 19.0.11 for Arrow Lake S/HX (INTEL-SA-01427), so ours is probably older (inference); that is a security matter, not stall evidence. No newer firmware exists to flash, and I found no source showing macOS loads Intel microcode files itself (inference).

Confidence: High for revisions and BIOS state; Low for any link to I-116 or I-118.

In N-292 four OpenCore starts in a row ended at EB|LOG:EXITBS:START after two Ubuntu probe sessions, with no macOS output or panic (N-292 README). That line marks where OpenCore's log stops, not where the machine died: the passing cold boot N-293 ends on the identical line (evidence/native/N-293/opencore-2026-10-27-174540.txt). The handoff still asks what the screen showed. "15 to 40 s after EXITBS" is an upper bound that includes firmware POST and possibly a manual power press. From the log stamps I computed 33, 25 and 19 seconds from each EXITBS to the next OpenCore start; a shrinking interval is not what a fixed timer gives. The first start was slower in firmware (229 ms against 68 to 81 ms at "Boot order has first option as the default option"), consistent with a cold start but not proof, so "warm-only" is unproven.

The UEFI boot-services watchdog defaults to five minutes and stops at ExitBootServices (UEFI 2.11); OpenCore also clears it, and all six logs print OC: Watchdog status is 0 (Configuration.tex). Linux's iTCO heartbeat defaults to 30 s, inside the window (iTCO_wdt.c), but N-274's dmesg has no iTCO line, so the driver probably never bound. Aspect 15 also said OpenCore reports reset causes through StartupPowerEvents; that is wrong, the option only sets a Data Hub property (Configuration.tex). The firmware reset register is an SMI write (port 0xB2, per Aspect 15), so a reset may run SMM code (inference).

Confidence: Medium (logs and sources read directly; whether any restart was automatic is unknown).

The mechanism with the best public precedent is the NVIDIA GSP. Its protected region (WPR2) stays up when Linux unbinds the driver (nova-core unload v5, mxtools PR 559), and the open module fails early with NV_ERR_INVALID_STATE when it finds WPR2 already up (kernel_gsp.c); a GB203 report describes WPR2 latched across warm reboots (open-gpu 1353). Our probe started nouveau on the GB206 with GSP RM 570.144 (dmesg). Against it: those failures appear as a failed GPU init in the next OS, not a silent reset, and a Hybrid boot keeps the dGPU idle.

Microcode comes second. An OS-applied update lasts until power is removed; kernel documentation does not say so and I could not confirm it for this CPU, though 2019 reports on older Intel parts treated it as normal (Arch FS#64498, USN-4182-3). N-274 did not update (0x11b before and after); whether the 10-24 sessions loaded 0x121 or 0x122 is unknown and takes one dmesg line to settle. Third, Linux skips disabling VT-d translation for an Intel iGPU with device ID prefix 0x7d, and it fired in N-274 (iommu.c); a platform reset clears DMAR registers, so carryover is unlikely (inference). The EC is a candidate with no evidence either way.

Confidence: Low (each carryover mechanism is plausible and none is shown).

The community's EXITBS cure is VT-d off: 1401 2.6.0 added a BIOS checklist item for 12th-gen and newer Intel including Core Ultra, because it got machines past EXITBS:START (1401 #10, #11, #53, #58) (changelog). On an Insyde laptop the VT-d row was hidden behind X2APIC and turning X2APIC off exposed it; the same thread found ProvideCurrentCpuInfo = true mandatory on Arrow Lake-H, found CpuTopologyRebuild made failures unrecoverable, and cleared an APFS respawn loop with SetApfsTrimTimeout 0 (1401 #58). 1401's own Arrow Lake laptop default enables CpuTopologyRebuild, which that reporter's test contradicts; we keep it off. 275HX reports in #44 and #49 show the same handoff stop. DevirtualiseMmio guidance is split: off on laptops, on for Core Ultra 200 desktops (changelog).

The Legion breaks the pattern. Linux sees DMAR with two DRHDs and VT-d active for graphics (dmesg), so firmware VT-d is on, yet N-293 reaches the desktop with DisableIoMapper set (docs/session-handoff.md). So "VT-d off" is not universal. This is inference: the community's "hang at EXITBS" reports may also be a last log line, as in 2.5. Our MADT fix (only type 9 entries, APIC-LAPIC.aml) is ours, confirmed on a second 275HX laptop per Aspect 14 (not re-checked).

Confidence: Medium (1401 text read 2026-10-27; second-laptop confirmation not re-verified).

Treat the waker as a hypothesis. XeGfx 0.0.44 added xegfx.irqoff_check=0 and 0.0.45 added xegfx.gtawake=1|2, so the levers exist. Once the cheaper steps below have run, run a 2 by 2 through xe-guard (waker on/off, gtawake 0/2), with a fixed load (disk copy loop plus WindowServer), recording time to stall and a stopping rule fixed in advance (for example stop an arm pair after three stalls in one arm and none in the other, or after a session budget). A 30 minute arm may show nothing, since N-290 passed 900 s and died at 88 minutes, and every stall ends in a panic or a hang with the risk of APFS rollback, so the budget should be small. The last uncontrolled death came at 88 minutes under APFS resize I/O (N-290 README), so one session per arm is meaningless.

Add readers: try powermetrics for C-state residency, and if it is empty add the core/package MSRs and 0x34 to LegionCpuProbe (a kext change). Before it, run one session with debug.legioncpu.{pl,hwp,epp} at stock values (a sysctl, no kext change and no reboot), because LegionCpuPower 0.4.1 was loaded in N-290 and Linux ran at stock limits. Then add a control arm with low-priority spinner threads that keep cores out of C6; it also changes power, temperature and the LegionCpuPower guard (10 W steps at 100 C), so it is not a clean C-state control: if stalls vanish, the cause is idle-state related and ARL037 gains weight; if not, drop it. After the next panic, read the MCA banks from 0x401 on first boot (survival across a warm reset is unverified). Raising slto_us (a boot-arg, so an NVRAM write that needs Bash's OK) shows whether a stall is finite, but only for stalls between the old and the new timeout, and it may waste a reboot; a TSC-gap log in XeGfx answers the same question passively. Never pair it with tlbto_us=0, which turns the panic into a trace line and loses the one artifact I-116 produces. A weak comparison is Linux: the 47-minute N-274 capture had no stall, but it ran without WindowServer, XeGfx or LegionCpuPower and at stock power limits, so it differs in at least four ways; a 2-hour Ubuntu run with the same disk loop and an iGPU workload shows whether the platform alone stalls.

Confidence: Medium (design is sound; none of these runs exists yet).

Add to every attempt row: cold or warm, microcode before and after, GPU mode (Discrete or Hybrid), and a phone photo of the verbose screen. Then run arms three times each. A: Ubuntu probe, log dmesg | grep -i microcode, iTCO, wdt, WPR2, then full power-off and a 30-second wait before macOS. B: same session, then a plain warm restart. C: as B, but with nouveau blacklisted so Linux never starts GSP. D: macOS-only warm restarts as baseline. Add a POST-time calibration (time a deliberate power press) to learn what "15 to 40 s" can contain.

Reading it: if A passes and B fails, power-retained state matters, and C separates GPU from microcode (a pass in C points at GSP/WPR2; a grep of the NvGfx log for "unexpected WPR2 already up" backs it). If B fails with equal microcode before and after, microcode is out. A long gap before the next POST means a manual power cycle is part of the story. All of it uses the existing probe stick.

Confidence: Medium (cheap and falsifiable; no arm has been run).

1. Each leading I-116 explanation covers only part of the evidence. ARL037 gives one silent core but not 23 silent CPUs (Intel 834774, xnu mp.c), and the similar Xe reports keep their kernels alive (xe 9168). So I-116 is more likely a machine-wide stall than one core's idle exit. Confidence: Low.
2. "C-state" is untested, not disproved. max_cstate=2 still allows a C6-class state (intel_idle.c, Unraid), XCPM thinks the CPU is Comet Lake, nothing publishes residency, and the waker result is confounded. Confidence: Medium.
3. "EXITBS" in I-118 labels where OpenCore's log stops, not where the machine died. Passing and failing boots end identically and no firmware watchdog is known to cover 15 to 40 seconds (iTCO, TCO, ME and EC watchdogs are not excluded; Unverified) (evidence/native/N-293/opencore-2026-10-27-174540.txt, UEFI 2.11). Find the real stage and whether a human ended it before testing hypotheses. Confidence: Medium.
4. Cold versus warm is the variable both problems share and neither has recorded. Intel's triager asks for it (i915 16052), NVIDIA's WPR2 reports hinge on it (open-gpu 1353), and N-293 passed cold where N-292 failed after Linux. One column fixes this at no cost. Confidence: Medium.
5. No firmware fix is known to exist, so there is none to wait for. The BIOS is newest, newer microcode has no public ARL037 mapping, and ARL037 is Planned Fix (Lenovo, microcode 20260811). I-116 work is a driver-side workaround or a measurement. That the BIOS is the newest is checked; that no fix exists is an absence claim from one search pass. Confidence: Medium.

Scope: NullMoth's driver and our NvGfx fork on the RTX 5070, and every public Intel Xe peer next to our XeGfx on the Arrow Lake iGPU. Where an aspect report and a verification pass file disagreed, the verification pass verified fact is used and the text says so. Project-internal evidence (handoff, guard captures, tracker) is marked "local" because it is not published.

NullMoth 2.6.2 is the current upstream release and carries the same driver as 2.5.5 (see the release list). Our nvgfx-2.6.2 branch rebases onto it, so the 2.5.4 and 2.5.5 driver changes arrive in the same boot as ours (local, docs/session-handoff.md, 2026-10-27). A failure at N-294 cannot be pinned on one change, and the attempt record should say so first.

Four third-party items since 2026-10-20 matter. PR 385 (pointer fields in the MPS depthwise translation) is in the package and passes our in-process translator test (local, evidence/native/I-117-translator-pr385). The sampler-slot analysis in 363 (blocky backdrop blur) is in. The hi-res mode flag proposed in 354 is in as f48eb4033e77; its effect for us is open, because our 12-byte scale-resolutions override already listed scaled modes on 26.7.1. Issue 412 is a third-party tester measuring our drag-stall commits on 2.6.2 (3.6).

Not adopted: the retry patch in 419 (conflicts with 385, 3.5), the brightness change in 312 (no licence stated), the hash swap in 187, and community HiDPI hacks. Expect heavy translation work after install: 370 measured 30 to 60 percent of a core on a cold cache, and our async cache writes should shorten it.

Confidence: High (checked 2026-10-27) for what is in the package; Medium for effect, none of it measured on this machine yet.

ArrowWhatever patches NvGfx and XeGfx on the same silicon as ours (275HX, 7d67, macOS 26.7.1). Its userptr note describes a panic with the text xegfx: vm: freeing wired page ... (ref 0x1). Pin and unwire lock separately, so the last unwire decides a page is free, and while it prepares the free outside the lock another thread pins the same page; the page reaches the free list still wired. The patch adds one unwire entry that drops the count and unlinks the run under xg_vm_mtx, plus a guard in vm_page_free() for user-held pages. The author reports a soak with zero panics; the README says the project is mainly LLM-driven, and nobody else has reproduced it.

I read our xe-2.6.2 xg_vm.c against that. The lookup takes the mutex and returns (lines 442-455); the pin path then raises ref_count with an unlocked add (1744-1810); unwire drops and frees outside the lock (894-910). The window is real in our tree.

It is a latent race, not our current failure. None of the captures I checked, N-290 included, carries the freeing wired page text; I-116 is a whole-machine stall that ends in a CPU rendezvous panic with 23 of 24 CPUs stuck (local, evidence/native/N-290). This is inference: the race may need more WindowServer or Metal-client churn than our runs reached. The patch files are under the same PolyForm Noncommercial licence as our fork.

Confidence: Medium (checked 2026-10-27) that the window exists (our code read); Low that it explains anything we saw; Unverified for the soak (self-reported).

zep245's design log (a Tiger Lake machine) has two findings that map onto I-116. First, NVRAM breadcrumbs: a flip took about 700 ms because the commit-trace patch wrote and synced NVRAM about 37 times per atomic commit, against about 1.3 ms with the flip off; dropping the breadcrumbs after WindowServer opened the framebuffer fixed it (b125, b126). Ours writes xegfx-step and xegfx-accel and calls an NVRAM sync in xg_trace_write, switched by xegfx.nvram_trace, and every guard capture from N-223 to N-290 ran with it at 1 (local, evidence/native/N-2xx/guard/sysctl.txt). The trace-off run has never been done; how often we call it, and what our NVRAM backend costs, are unmeasured.

Second, the GT hold: dropping the boot-time keep-awake hold led to a panic 16 s after a cold boot, so zep245 holds through boot and releases 90 s after attach (b148); a one-shot RC6 test later showed that allowing RC6 was fine (b139). XeGfx 0.0.45 carries gtawake=1|2 and irqoff_check=0 as A/B switches (local, handoff). The panic line needs care: "NMIPI for unresponsive processor: TLB flush timeout" is an xnu CPU-side message about a CPU that did not answer a TLB shootdown with interrupts off. It is not a GPU or GuC invalidation timeout such as the one tracked in xe 8678.

Do not over-read the fit. A GT hold is not expected to cure the GuC late-ack bug (the A/B in 8678), and XeGfx skips the media GT, so the Wa_22016122933 root cause cannot explain I-116. These tests probe a possible separate CPU-side cause.

Confidence: Medium (checked 2026-10-27) that the NVRAM cost is real on zep245's machine (own log); Unverified that it applies to ours.

Our state: XeGfx 0.0.45 first reached stages 1 to 4 on 2026-10-21 (issue 2), and the accelerated desktop ran 88 minutes at N-290 before I-116 killed it (local, handoff). It is not a daily driver, and the stall is unresolved.

ArrowWhatever is the only peer on our silicon. It claims a zero-copy GGTT flip and a deferred K9 flip at about 60 fps (zero-copy, K9), with manual bring-up after boot and one WindowServer restart (route). The aspect report rated it tier S; the audit rates it B (self-reported, LLM-driven, no reproduction), and the audit wins. jwx29's meteor-lake-local (155H, 7d55, macOS 15.8.1) passes stages 1 to 7 and says stability was not established; our review found a small glue delta on our 0.0.44 and no I-116 fix (local open loop). VedCloud (MTL-U 7d45) reports a lost-wakeup GuC TLB timeout fixed.

Two projects are not competitors. WhateverXe 0.6.1 says no Xe-LPG or Meteor Lake support is planned. nmx-intel (Raptor Lake) composites on NVIDIA and flips to the Intel panel, a Hybrid fallback idea rather than an Xe driver. NullMoth's own NMXGPU has an open report where i915/xe never attach on Arrow Lake-H (297). Breadth for every Xe peer is "anecdote" (scout).

Confidence: Medium (checked 2026-10-27) for the ranking; every peer claim is self-reported (tier B at best).

Geekbench 6 and 7 hit depthwiseConv_3x3 with "Function vs Private pointer phi" in 377, the same kernel's CPU translation exceeds 180 s in 111, and Vision barcode detection aborts its host app in 334. The maintainer's position in 334 is that the kernel does not run on the GPU yet and that a private-pointer fix faults the GPU. So a translation that "succeeds" with null handles is a different failure from a clean error. PR 385 is the one candidate, and we carry it.

Issue 419 (Chrome WebGL2 context loss on 2.6.2) reports a local patch that cut translation failures from 53 to 0 and null handles from 24 to 0, with 18,066 frames at 64.5 fps, by retrying forward-fields four rounds. It conflicts with 385. The translator crate is LGPL-3.0-or-later, so reuse is allowed, while the repository's top level states no standard licence (LICENSE). This is inference: because a GPU-fault outcome exists, "failures dropped to zero" is not proof of correct rendering.

Confidence: High (checked 2026-10-27) that the failures are open and seen by several reporters; Low on 419's effect (one anecdote).

Issue 412 is a tester on an RTX 5080 reporting stock 2.6.2 dragging at 85 to 100 flips per second with 63 to 124 ms stalls, and six of our commits removing them. Two state-cache commits made Alacritty text jump back, so the tester held them out. By commit message those match our repeat-pipeline skip and sampler-variant memo (inference: the match is by message and switch name); in our package both sit behind NVMTL_NO_PSO_SKIP and NVMTL_NO_SV_MEMO. The commit-time pass on its own queue is fc07ff5e145d.

Related reports point at the same area without proof: a missed frame about every 0.6 s on all apps (410) and frame pacing at 540 Hz (302). For N-294 the practical test is a heavily redrawing terminal (such as Claude Code itself) with the two switches on and off.

Confidence: Medium (checked 2026-10-27); one independent tester, and the regression is one report.

Scaled modes validate but never reach the list in 354, which points at kDisplayModeValidForHiResFlag (0x00800000) missing in getInformationForDisplayMode (nvrm-fb.cpp line 3028 at 2.6.2). Issue 360 reports 1920x1200 HiDPI refused at 165 Hz but accepted at 60 Hz, and 341 covers HiDPI above half native on 1440p and 1600p panels.

Three corrections to the aspect report. The limit fits a desktop pixel rate (width x height x refresh) better than a ratio cap, with display stream compression and link bandwidth as caveats; "about 1.3x" was a simplification. The 12-byte versus 16-byte scale-resolutions tension between macOS 15 and 26 was largely settled by a later 15.8.1 data point (16-byte also hidden, 12-byte with backing sizes works). And the 12-byte finding in 341 came from our own account, so it is not independent. The community hacks (a 64-timing cap with nvfbscalehz, a 26-byte NVRM patch) are unvalidated by anyone else.

Confidence: Medium (checked 2026-10-27); the flag is code reading plus our mode list, the rate rule is a fit to three reports (inference).

HDR is an old request (30). The only mechanism offered is that CoreDisplay forces 8 bits per component when the framebuffer class name contains "NVDA", and that renaming it kills the Metal compositor; that trace in 341 came from our own account, so the aspect report's framing as a community finding is wrong. Treat it as one unreproduced trace.

Chrome flicker has a measured cure: Skia Graphite disabled fixed it in 333, and NVMTL_SCHEDULE_AFTER_SURFACE_WRITES=1 cured the Simulator flicker at a speed cost in 293. On our box Chrome 155 runs Graphite on the NVMTL plugin; a launcher without it exists, effect unconfirmed (local note, 2026-10-22). ANGLE Metal on NVIDIA was opened for Discord in 348 (closed).

Confidence: Low (checked 2026-10-27) for HDR (single self-reported trace); Medium for the Graphite cure (few reporters).

On our machine the RM gets no platform power input by default, the VBIOS limit is 50 W, and Windows runs the same GPU at 115 W (power.md). GSP control 0x20800AD2 (CONFIGURE_TGP_MODE, in ctrl2080internal.h) lifts the enforced limit, and boot-arg nvrmtgp=1 sends it from nvrm_power.cpp on AC. NVIDIA's laptop comparison gives a 50 to 100 W TGP range for the 5070. I could not extract the figure from Lenovo's PSREF sheet here, so reconciling the three numbers is open.

Upstream shows the same problem class on Linux: 1389 (Lenovo RTX 5070 Mobile, _DSM NVD1 not found), 1393 (platform request handler fails, power capped), 1344 (closed; Legion capped near 55 W) and 1162 (NVPCF not bound). The aspect report suggested diffing 615.71.10 for the 1389 fix. Checked: 615.71.10 is 615.71.09 plus a version bump, and the 615.71.09 to 615.78.08 diff shows no platform-request or power-policy logic change, only regenerated GSP firmware data and unrelated files. This is inference: any fix lives in the firmware blobs, which a source diff cannot show.

GSP stability issues in the same tracker (heartbeat Xid 119 in 1353, frozen power telemetry in 1237 and 1287, a boot hang in 1421) are why the TGP step stays conservative: AC only, polled, on change.

Confidence: High (checked 2026-10-27) for the 50 W to 115 W control on our machine (our N-73 measurement); Low for any upstream fix location; Unverified for Lenovo's own figure.

LegionCbmrFix (our public repo) unloads Microsoft's cbmr_driver.efi, which this BIOS loads at 0x180000000, and reserves its 164 KiB. Without it the Legion panicked in vm_page_validate_no_references within 4.5 to 10 minutes of memory churn, with or without GPU drivers; the README records a 360 s churn test passing and no panic of this kind since 2026-10-16. jwx29's README reports the same panic on its Meteor Lake machine and confirms the workaround unloads the image there, but says post-workaround stability was not established.

The same panic text appears in NullMoth issue 328 on a different laptop (GTX 1650), at a page address far outside our CBMR range. This is inference: that report is not the firmware-memory case, and the panic string alone cannot decide. Matching on the text will misattribute.

Confidence: High (checked 2026-10-27) for the Legion cause and fix (own machine, README test); Low for any other machine.

1. The Intel work is converging on the same two suspects, and neither is the GPU. ArrowWhatever's userptr race (a lock gap in pin and unwire) and zep245's NVRAM cost (syncs in a hot path) are both glue-code bugs, both plausible in XeGfx, and neither matches I-116's signature. They are cheap to close. The userptr race is unlikely to be the cure; the NVRAM trace is a different matter, because native NVRAM writes on EDK2-derived firmware normally run in System Management Mode (whether this Insyde build does is Unverified), so the trace is a cause candidate and not only hygiene. Sources: userptr note, DESIGN.md. Confidence: Medium.
2. Third-party evidence on both vendors is thin, and part of it is ours. The HDR trace and the 12-byte HiDPI finding came from our own account, the drag measurement is one tester, and the ArrowWhatever soak is self-reported. What is independent: the MPS failures (several reporters) and the Chrome Graphite cure. Sources: 341, 412, 377. Confidence: Medium.
3. A readable N-294 result needs the base change split from our changes. 2.6.2 carries the 2.5.5 driver, and our package adds fixes for MPS, sampler slots, scaled modes and drag, so the result should be logged against both sets, with the two state-cache switches and a cold-cache note. Sources: release, 412, 370. Confidence: Medium.
4. Panic text identifies less than it seems to. vm_page_validate_no_references also appears off-range on another laptop, and "TLB flush timeout" is a CPU shootdown in xnu while the Xe tracker uses the phrase for GPU-side invalidation. Read the address and the stack, not the headline. Sources: LegionCbmrFix, 328, xnu mp.c. Confidence: High.
5. The Blackwell power question changed from "find upstream's fix" to "ours is the fix". The 615.71.10 and 615.78.08 diffs show no platform logic change, and our one GSP control already lifts 50 W to 115 W, so waiting on upstream source buys little; the open items (envelope numbers, blob changes) are documentation work. Sources: compare, power.md, 1389. Confidence: Medium.

AppleDB lists four 26.7.2 builds: 25G320 (RC, 2026-10-06), 25G325 (RC2, 2026-10-13), 25G330 (RC3, 2026-10-19) and 25G332 (release, 2026-10-26). Dortania's KDK is tagged 25G330, and our own maintainer reply in mt7925-hackintosh-wifi issue 4 first said "25G330" before correcting itself to 25G332. Where an aspect report or tracker row calls 26.7.2 "25G330", the later verified record wins: the final build is 25G332.

I checked on the Legion today that Apple's catalog still serves several builds: softwareupdate --list-full-installers lists 26.7.2 as 25G332 and as 25G325, and does not list 25G330. The rebuilt 25G332 kernel reports xnu-12377.161.15.701.48~2 (Darwin 25.6.0, built 2026-10-12), against 700.19~2 on the Legion's 25G241. The Darwin version is the same on both, so a gate keyed on it cannot tell them apart; only the xnu tag can. The Intel delta patches for 25G330 and 25G332 give identical BootKernelExtensions.kc, SystemKernelExtensions.kc and kernel (25G325 differs). This is inference: a 25G330 tester's kernel-side behaviour is therefore a fair proxy for 25G332, but only for those three files.

Confidence: High (checked 2026-10-27): dates from AppleDB, catalog listing and kernel string read by me.

Apple serves an Intel delta from 25G241 to 25G332, 1,358,475,023 bytes and readable with HTTP Range, listed in the appledb entry, so only the needed members are fetched. It holds BXDIFF50 patches for BootKernelExtensions.kc (about 1.7 MB), SystemKernelExtensions.kc (about 0.6 MB) and the kernel (about 1.5 MB), in the format blacktop/ipsw implements: a header with sizes, a 20-byte result SHA-1 and a 20-byte base SHA-1, then compressed control, diff and extra streams.

What I verified myself: each patch's base SHA-1 equals the SHA-1 of the live 25G241 file on the Legion; the patched output's SHA-1 equals the patch's result SHA-1; and its size and CRC32 equal the entries in the OTA's own post.bom. That is a byte-level fact, not a plausibility argument. Kext binaries have lived only inside these two collections since Ventura and Apple ships them prebuilt (only the auxiliary collection is built on the Mac), so the rebuilt files hold every kext binary the 25G332 boot uses, including IO80211Family 1200.13.1, the version in the issue 4 reporter's logs.

Nothing was installed and no Apple binary goes into git. The route needs the exact base build, so it works from 25G241 only, and it covers kernel-side files only: for user-space files the OTA gives just a bill of materials (see 4.5). The scripts were standard-library Python, run with -I on files in a scratch directory.

Confidence: High (checked 2026-10-27): hash, size and CRC32 equalities were computed, not reported.

kcabi compares IO80211Family, IOSkywalkFamily and AppleBCMWLAN between two kernel collections: instance sizes, vtables, request tables and disassembled functions. Against 25G241, the sizes, vtables and request tables are unchanged. Of 1154 compared functions, 1121 are identical and 33 differ; 31 of those differ only in addresses or ordering. The three real differences are one field offset in _kern_netif_queue_rx_enqueue (0x4d8 becomes 0x4e8) and the immediates in AppleBCMWLANNANInterface::enableDatapath and ::disableDatapath. By my arithmetic every changed immediate in the two NAN functions moves by exactly 0x27, which looks like one inserted structure rather than six unrelated edits.

This is inference: the NAN (Wi-Fi Aware) functions are in Apple's Broadcom driver class, which MtkWlanNative does not subclass, so they probably do not matter to us. The rx_enqueue change is the one to read, because a field moving by 0x10 inside a queue structure breaks any code that accesses that field directly instead of calling an API. Whether MtkWlanNative does is not settled; it needs a disassembly review of the call site and a boot test on a real 25G332 machine. kcabi compares binaries, not behaviour, so unchanged layouts do not prove the Wi-Fi menu will attach.

Confidence: High for the measured differences, Unverified for their consequences (checked 2026-10-27): no 25G332 boot of our kexts has happened.

MtkNativeAbi.hpp starts the native front end only when the running kernel's xnu tag is on an allow-list and the live class sizes match. The shipped allow-list in the same repository has one entry, 25G241 (700.19~2). A refusal is recorded in the provider property MtkNativeDeclined; MtkNativeLast exists only when the front end started. After a decline MtkWlan falls back to its Ethernet front end: en1 with no Wi-Fi port.

That matches issue 4: MtkWlan 0.12.1 and MtkWlanNative 0.4.13 load, en1 is up, no Wi-Fi menu, and the maintainer reply gives the same diagnosis. The reporter's empty MtkNativeLast is consistent with a decline but is not proof, and nobody has captured MtkNativeDeclined yet, so the real refusal reason is unrecorded. This is inference: with the tag outside the list the size check never runs, so the unchanged sizes of 4.3 could not have helped. The reporter is on a desktop board with a MediaTek card, not a Legion, but the gate does not depend on the motherboard.

Confidence: Medium (checked 2026-10-27): code reading is direct, the link to the reporter's machine is inference.

LegionBtFix patches two instructions of bluetoothd in memory and gates on a byte window plus a SHA-1 of the whole 4 KB page, for 25G241 only. The OTA bill of materials lists /usr/sbin/bluetoothd at the same size in both builds (23,555,568 bytes) with different CRC32 values, so the binary changed without growing, and Apple's 26.7.2 notes include one Bluetooth entry. Bluetooth patterns are known to be build-specific: BrcmPatchRAM issue 39 is a bluetoothd pattern that stopped matching. This is inference: the page-hash gate will probably refuse on 25G332, the safe outcome, but the I-047 crash loop could then return unprotected.

I could not apply the bluetoothd delta to check the pages. The patch's base SHA-1 equals neither the live universal binary nor its x86_64 slice. For five other files I compared (bluetoothaudiod, bluetoothuserd, true, cfprefsd, airportd) the live CRC32 equals the OTA's pre.bom, but bluetoothd does not (live 2381493249, pre.bom 4287939534). I have no explanation: an earlier modification of the on-disk binary and a BOM that records the file in another representation are both possible. It does not change the conclusion that LegionBtFix is untested on 25G332.

Confidence: Medium for "binary changed" (BOM comparison), Unverified for the page hashes (checked 2026-10-27).

In issue 4 the reporter's first USB listing showed no MediaTek device; the maintainer advised a full power drain and a BIOS Bluetooth check; later that day he wrote that Bluetooth works and posted a listing with a "Wireless_Device" at vendor 5075, product 13826, which is 13D3:3602 in hex (my conversion; the line order in his paste is ambiguous). The step he took is not recorded, and his Wi-Fi is still unresolved, which fits 4.4.

The ID is in Linux btusb v7.3, and MtkBt matches by vendor (Foxconn 0489, IMC Networks 13D3, MediaTek 0E8D), so it would claim the device. This is inference: a Bluetooth function that is missing from the USB bus and returns after a power cycle looks like a combo-card state fault, and our own issue 1 already documents the card wedging over a warm restart. Whether LegionBtFix or MtkBt loaded on his desktop was not asked. A tracker row saying "Bluetooth lost on 26.7.2" would overstate this evidence, and so would "26.7.2 is Bluetooth-safe".

Confidence: Medium (checked 2026-10-27): one anecdote with an unrecorded fix.

I parsed the CSAF data behind APPLE-SA-149522: 213 CVE entries under 93 component headings, among them Kernel (17 entries), Bluetooth (1), Wi-Fi (3), AirPort (1) and graphics components (IOSurface, Metal, IOGPUFamily). The notes describe fixes, not ABI, so they cannot tell us whether IO80211 or IOSkywalk layouts moved; 4.3 does that. They do show that a rule of "only the kernel tag changed" would be false.

For NvGfx and XeGfx the only point is that graphics-family components changed. No report in the corpus tests an NVIDIA or Intel iGPU driver on 25G332, and no Arrow Lake data on 26.7.2 turned up. The day-one reports are from stacks that avoid private IO80211 layouts: InsanelyMac's 26.7.2 thread has users on itlwm, SimpleBCM and SimpleHDA updating to 25G332 without trouble, and I found no acidanthera issue or commit that mentions 26.7.2.

Confidence: High on the counts (parsed), Low on what they imply for our drivers (checked 2026-10-27).

Apple's macOS page lists macOS 27 "Golden Gate" as compatible with Apple silicon Macs only, which agrees with the OCLP discussion that Tahoe is the last Intel release. How long Intel Macs keep receiving Tahoe security updates is only press-relayed (three years), not a primary Apple statement.

For the Legion this matches Bash's position of staying on Tahoe 26.x until support ends. The cost is that every point release moves the xnu tag, can change bluetoothd (4.5) and user-space daemons (the OTA bill of materials shows airportd growing from 3,228,064 to 3,228,096 bytes), and so re-opens the per-build pins of MtkWlanNative and LegionBtFix. This is inference: automating the kcabi refresh and the OTA route (4.2) is worth more than any single 25G332 fix.

Confidence: Medium (checked 2026-10-27): the model list is direct, the support horizon is press-relayed.

The set, with creation dates from the GitHub API: laobamac/SimpleMtkWlan (2026-05-26, GPL-2.0), flxxxxddd/SimpleMtkWlan v1.5.0 (2026-10-13), mnnobre/AirportMtkWlan (2026-10-14), thanhnndev/mt7925-macos-wifi and HackSucks/mtwlm (both 2026-10-26), and an unread fork of our own repo. The thanhnndev README calls itself experimental, mostly AI-written and tested on one laptop; it reports native mode on 25G241 at 176.6 Mb/s down and 65.0 Mb/s up (HE 160 MHz, 2x2), WPA2-PSK and mixed WPA/WPA2 only, and keeps abi/native-wifi/ dumps for 24H32 and 25G241. It is tied to one build exactly as ours is, so the 26.7.2 wall is shared by everyone on the private IO80211 front end.

On the Linux side, ac22c8c723c6 keeps the join ROC until the station is authorized (the 4-way handshake area), d12a54be2604, 8d2f5990cd42 and c781b74c3fd0 harden power-management and reset paths (our I-081 warm-restart problem), and b3078bb2ee12 and e3ac0d9f1a20 reset on a WMT timeout and accept short FUNC_CTRL events (MtkBt's "status 255"). The linux-firmware repository has MT7925 builds stamped 20261016; our kexts embed 20260813, and no changelog exists for either. This is inference: these fixes address symptoms like ours, but a subject line is not a diff, and each needs a read against MtkWlan before anyone claims it applies.

Confidence: Medium (checked 2026-10-27): repository and commit facts are direct, performance claims are anecdotes, applicability is untested.

The most-reported fix for the silent stop at EXITBS:START on Arrow Lake is VT-d off: 1401 issue 10, issue 11, the 2.6.0 changelog and the core-ultra-drop-dmar rule in efi_rules.json. Issue 58, the best-documented chain, found the VT-d row greyed out until X2APIC was disabled (an Insyde laptop), then needed ProvideCurrentCpuInfo and SetApfsTrimTimeout 0; the reporter changed VT-d and the DMAR drop in one boot, so causality is two variables. The same rule file scopes arrow-lake-ctr to desktops, and a laptop default panicked in that issue.

Reading the actual plists, wsjj's Y9000P EFI (83F5, 275HX, BE200 Wi-Fi, panel on the NVIDIA GPU) and the ASUS FX608LP EFI both set SetupVirtualMap true and ForceExitBootServices false. Our OCEFI (read today) is the reverse, with DevirtualiseMmio off, ProvideCurrentCpuInfo on, and only the APIC table in ACPI Delete (no DMAR drop). Mountainatic's YaoShi16 EFI reports the same MADT shape (tier B, not re-checked) on a second 275HX laptop with a converted APIC-LAPIC.aml and deletes both DMAR and APIC. wsjj's README says ResizeAppleGpuBars = -1 while its plist has 0, so documentation drifts from config.

This is inference: the Booter difference is a candidate A/B for our resets after EXITBS:START (I-118), not a proven cause, and "VT-d off yields a type-0 MADT" is unverified because nobody has dumped the MADT before and after a BIOS change. None of these EFIs reports I-118-style resets.

Confidence: Medium (checked 2026-10-27): plist values and issue text are direct, causality is absent.

LenovoLegionLinux commit a897adf92a06 (2026-08-07) adds the Legion 5 15IAX10 (83F0) with BIOS prefix S2CN and EC chip ID 0x5508, shared with the LOQ 15IRX10, and 29571790b209 (2026-09-20) uses a level-index, speed-only WMI fan table across the 0x5508 models, citing level bytes at EC addresses F9F0 to F9F9. Our BIOS is S2CN26WW, so this is data about our own EC. This is inference: it is a read-only cross-check for the LegionFan curve code in LegionCpuPower, not something to write to.

BelikPePe-UA/legion5-15irx10-hackintosh is a Legion 5 15IRX10 with an i7-14700HX (Raptor Lake) on Sequoia, with Fn+Q mode events from WMI notify 0xE3 and GPU clock tools. It helps with keyboard and GPU power, not with Arrow Lake boot questions. In 1401 issue 44 a Lenovo 275HX owner reports an early page fault with no answer. No 285HX, Legion 16IAX10 or Legion Pro Gen 10 report turned up.

Confidence: Medium on the EC commits (direct), Low on usefulness (checked 2026-10-27).

1. The Wi-Fi break on 26.7.2 is a safety decision in our own gate: the layouts kcabi checks are unchanged, but three function differences are unreviewed. Bluetooth is a separate question, since bluetoothd changed in place. The gate refuses on the xnu tag before it looks at sizes (4.4), while the offline kcabi run shows unchanged sizes, vtables and request tables with only one plausibly relevant function change (4.3). The cheapest next step is to review that one change and, with Bash's agreement, try an allow-list entry for reporters, not to wait for a full re-port. The unknown is real: no 25G332 boot of our kexts has happened. Confidence: Medium. Sources: MtkNativeAbi.hpp, kcabi.
2. Offline reconstruction separates ABI preparation from the decision to update. Because the 25G332 kernel collections can be rebuilt and verified without installing anything (4.2), dumps, allow-list candidates and header refreshes can be prepared while the Legion stays on 25G241, and the same OTA's bill of materials already shows which user-space files changed (bluetoothd, airportd, 4.5 and 4.8), which kcabi cannot see. Confidence: High on the method, Medium on its reach. Sources: bxdiff50.go, APPLE-SA-149522.
3. Bluetooth reports on 26.7.2 mix two causes, so neither "the update broke it" nor "the update is safe" follows. The bluetoothd binary changed at an unchanged size and Apple lists a Bluetooth fix, so LegionBtFix's pins are likely stale (4.5). Separately, the one reporter's Bluetooth device left the USB bus and returned after a power drain, which is a card-state fault our warm-restart issue already describes (4.6). Confidence: Medium. Sources: LegionBtFix, issue 4, issue 1.
4. Outside Arrow Lake configs support a read-only BIOS look and an optional two-quirk A/B for I-118. Two other 275HX EFIs (not independent of each other's guide lineage, and neither reports a Linux-then-macOS sequence, which is where I-118 appears) run SetupVirtualMap on without ForceExitBootServices and the 1401 corpus converges on VT-d off or a DMAR drop, whereas ours has the opposite quirk pair and keeps DMAR (4.10). None of them reports I-118-style resets, so the A/B is a hypothesis, and our normal boots work. Confidence: Medium. Sources: ASUS FX608LP EFI, wsjj EFI, 1401 issue 10.
5. Staying on Tahoe 26.x is viable, but each point release is a recurring cost for private-layout kexts, and the newest competitor shares it. macOS 27 drops Intel while 26.7.2 still carries a large security update (4.7, 4.8), and each release moves the xnu tag, bluetoothd and possibly user-space daemons; the newest MT7925 project has the same per-build pin (4.9). Automating the kcabi refresh and the OTA route is worth more than any single 25G332 fix. Confidence: Medium. Sources: Apple macOS page, thanhnndev/mt7925-macos-wifi.

Scope: Legion 5 15IAX10 (Arrow Lake-HX 7D67, our XeGfx / NvGfx / MtkWlan, Tahoe 25G241). Last column is tier/confidence. Dates are UTC and primary unless marked. "gl" = gitlab.freedesktop.org (HTML behind Anubis; issue dates come from API JSON cached by the aspect agents, which I read but did not re-fetch). "inferred" means my arithmetic, not a published date. Never-invented rule held: gaps are marked.

1. 2026-10-27: mt7925 issue #4 shows 26.7.2 (25G332) makes MtkWlanNative decline the unknown build (maintainer diagnosis), so Wi-Fi falls back to Ethernet mode; our kcabi diff shows _kern_netif_queue_rx_enqueue field offset 0x4d8 to 0x4e8, a candidate cause (tool output, unreviewed). Medium.
2. 2026-10-27: xe #9168 comment shows the GuC ack delay survives display power-state off. Core C-states, RC6 and the GuC stay open for I-116.
3. 2026-10-26: macOS 26.7.2 final 25G332, 17 kernel CVEs, no kext/IO80211 notes. Per-build ABI dump needed.
4. 2026-10-26: NullMoth 2.6.2; driver code frozen since 2.5.5.
5. 2026-10-25 to 10-27: three peers on Xe-on-macOS (ArrowWhatever, jwx29, VedCloud), all without a long soak.
6. 2026-10-24: drm-next merged; d5b0bf3f lands for 7.4 only.
7. 2026-10-21: Mesa brw hang fix.
8. 2026-10-18: Linux v7.3.
9. 2026-10-16: Intel spec update rev 024; ARL037 unchanged on HX.
10. 2026-10-14: Mesa 26.2.5, cx0_phy ARL-S fix.
11. 2026-09-27: OpenCore 1.0.8 (HideVerbose key broke 1401 2.5.3 builds).
12. 2026-09-02: drm-firmware GuC 70.74.0.
13. 2026-08-11: microcode 0x122 (Legion on 0x11b).
14. 2026-05-11: FreeBSD ported MTL.

• "26.7.2 final is 25G330": tracker R073/R074; final is 25G332 (RC3 was 25G330). Source: appledb, issue #4 comment 6.
• "Tahoe 26.7.1 is current": superseded 2026-10-26; abi/native-wifi/25G241 covers only 25G241.
• "MtkWlan 0.11.3 / MtkWlanNative 0.4.11" (global notes): now 0.12.1 / 0.4.13. "LegionCpuPower 0.3.3": now 0.4.1 (2026-10-27).
• "NvGfx base 2.5.3 is latest": NullMoth is at 2.6.2.
• "OpenCore 1.0.9 is out": 1.0.8 is the latest release.
• "d5b0bf3f is in 7.3": it is not (7.4).
• "GuC 70.53.0 is the only firmware": 70.74.0 exists (drm-firmware) and is in use.
• "ARL037 planned fix everywhere": H is Fixed; HX is not.
• "S2CN23WW has the MCU update": S2CN26WW is newest.
• "Intel Macs run macOS 27": Golden Gate 27 is Apple silicon only.

• 6d46d09a0d7d: API says 2024-01-24, one aspect report 2024-01-19. Author vs committer date not separated by me. Tag v6.9 (2024-05-12) is unambiguous.
• S2CN26WW: readme 2026-03-24 vs catalog 2026-05-06 (likely upload vs authoring, unverified).
• 26.7.2 build: 25G330 (RC3, 10-19; also the maintainer's first reply on issue #4) vs final 25G332 (10-26).
• Potential, not seen: Linux 7.3 tag is 2026-10-18 23:14 UTC, so sources in UTC+1 or later may say 10-19.
• NVIDIA tags: 615.71.10 published 2026-10-21, after 615.78.08 (2026-10-07). Version order is not date order.
• Reporters say "OpenCore 1.0.9"; no 1.0.9 release exists, only master builds.
• 0x11b arrived 2026-02-10, but the only BIOS readme with an MCU line (S2CN23WW, 2025-11-04) predates it. S2CN26WW (2026-03-24) postdates it, so it probably carries 0x11b (inferred).
• FreeBSD drm-kmod #315 returned 404 on freebsd/drm-kmod, so its date is unverified.

This section collects the reference material that the findings above lean on: how to read the I-116 panic, the firmware and device identity of the 7D67 iGPU, the verified offline route to the 26.7.2 kernel collections, and the experiment matrices for I-116 and I-118. Everything here was checked on 2026-10-27 unless a line says otherwise.

The panic text says that the panicking CPU timed out in mp_rv_action with 23 of 24 CPUs having entered. In the public xnu source the rendezvous spin is bounded by four times the lock timeout (mp_spin_timeout), the lock timeout defaults to 0.5 s on release kernels, and the boot-arg slto_us changes it (xnu mp.c, machine_routines.c). The TLB-shootdown timeout follows the same default and a boot-arg tlbto_us=0 turns the panic into a trace event. Two consequences follow. First, "23 of 24" means exactly one CPU never arrived at the rendezvous, but the panic string does not print which one, so the most useful extra datum a future panic could carry is the identity and last instruction of the missing CPU. Second, the later "none of the other 23 CPUs acked the NMI" phase is a separate observation: one stuck CPU explains the first phase, while the second needs something shared, such as an SMM/SMI period, a fabric or memory stall, or CPUs that cannot take an NMI. The independent contradiction check in this research run left the question unresolved, and no public report shows the same two-phase pattern on a 7D67 part. The public xnu tree ends at xnu-12377.121.6 while the Legion runs a 12377.161.x kernel, so mapping panic offsets to source is approximate.

Gleixner's remark on LKML (2026-01-13) is the best published statement of what a stuck MMIO transaction looks like to an operating system: the machine "just stalls on outstanding MMIO transactions w/o further notice" and the NMI is "a red herring" (LKML). It argues for looking at the first stalled access rather than at the NMI silence. It does not by itself explain why 23 CPUs spinning in cache would also ignore an NMI.

The firmware names are the Meteor Lake names; there is no arl_guc file. ARL-H parts (7D51, 7DD1) are Xe-LPG+ 12.74, so many "Arrow Lake" reports in public trackers match the silicon family but not this die.

The 26.7.2 release candidates were 25G320, 25G325 and 25G330 (RC3); the shipping build is 25G332, released 2026-10-26 (appledb 25G332). The kernel collections cannot be downloaded as plain files, but the Intel delta OTA from 25G241 carries them as BXDIFF50 patches against the files already on this Mac. The route, as run and checked by the research agents:

1. Confirm the base: sw_vers shows 26.7.1 / 25G241 and the SHA-1 of BootKernelExtensions.kc, SystemKernelExtensions.kc and the kernel begin 01a0b5ca, d8847772 and b42c5e15.
2. Read the OTA entry for 25G332 in appledb whose prerequisite build is 25G241 and whose device group is the seven-device Intel group (the zip is about 1.36 GB).
3. List the zip's central directory with HTTP range requests and fetch only the three .bxdiff members (about 12 MB).
4. Apply each patch to the live file with a small stdlib Python patcher that refuses to run unless the base SHA-1 matches and checks the result SHA-1.
5. Cross-check the rebuilt hashes against post.bom from the same zip, then validate with kmutil inspect.
6. Dump and compare with the project's own kcabi tooling against abi/native-wifi/25G241.

The rebuilt 25G330 and 25G332 collections have identical hashes for BKC, SKC and kernel, so for kext purposes they are one build. The kcabi comparison against 25G241 shows unchanged class sizes, vtables and request tables, with three small differences: one field in _kern_netif_queue_rx_enqueue moves from offset 0x4d8 to 0x4e8, and two immediates change in AppleBCMWLANNANInterface::enableDatapath and disableDatapath. Whether those break MtkWlanNative is inference until someone reviews them. Nothing in this route touches OCEFI, NVRAM, kexts or the volume. The build identities come from appledb. An independent check confirmed that the patch headers carry base SHA-1s matching this Mac's files, but that check did not apply a patch itself; the byte-level result rests on the first agent's run, whose patcher verified each result SHA-1 against the OTA's own manifest.

Record, for every probe-then-macOS pair, whether the machine was fully powered off in between; this turns the cold-versus-warm column from memory into data. Before leaving Ubuntu, record the loaded microcode revision (dmesg | grep -i microcode) and, if possible, the TCO watchdog state (/sys/class/watchdog/*). After the warm restart, read sysctl machdep.cpu.microcode_version: 283 is 0x11b (unchanged); 289 would be 0x121 and 290 0x122. Boot the probe sessions so that the dGPU is left quiet (modprobe.blacklist=nouveau) so that GSP/WPR2 state cannot persist. These are cheap, read-only or stick-side changes. They are listed with their evidence in Theme 2.

Every row states a claim, how far it can be trusted on 2026-10-27, the best sources and a note on how the evidence was obtained. Rows are grouped by theme in the order of the main findings. Confidence labels are High, Medium, Low, Unverified and Contradicted; "inference" in the notes means a reading of direct evidence that no source states.

The research did not produce one clean answer for any of the open issues, so the useful comparison is between the options the evidence leaves open. Each pair below states what the public record says about the two sides and where the project's own constraints change the weighting.

An i915 port against an xe port for the Intel iGPU. XeGfx carries Linux i915 plus Mesa ANV. On this PCI ID i915 is the upstream default driver and has been since the force_probe requirement for Meteor Lake was removed in v6.7 (commit 213c43676beb), while xe still carries require_force_probe for the Meteor Lake and Arrow Lake descriptors, so running xe on this silicon is an officially unsupported configuration. The tracker reality points the other way: every active Intel investigation of the Arrow Lake GuC acknowledgement stall lives in the xe tracker (xe 8678, xe 9168), while an Intel developer answered a wedge report on xe with "Use i915?" (xe 9224). There is also a data point that the two drivers diverge on the same PCI ID: 7D67 shows corruption under i915 at DDR5 7600 MT/s and above that xe does not show (i915 17098), which is far above a laptop's SO-DIMM speeds but proves the memory paths differ. For a port, i915 is the larger shim surface and xe the smaller one (GuC is mandatory there and the force_execlist parameter was dropped on 2026-06-30, commit b623bd790db0). Staying on i915 keeps the code the maintainers still treat as the shipping path; moving to xe would make the project track the code where Intel's engineers are currently debugging. Neither is clearly better for I-116, and a switch would restart the bring-up work.

GuC submission against execlists. GuC submission with HuC through the GSC is the default for Meteor Lake and Arrow Lake in i915, and upstream does not offer execlists as a supported fallback in xe. A user on Raptor Lake reported that a GuC hard lockup went away with enable_guc=0 (i915 15708), but that is a different platform with different firmware, and GuC deprivilege on Meteor Lake means the firmware sets up the WOPCM before the OS starts. The cheaper variant of the same idea is to send TLB invalidation through the MMIO fallback instead of a GuC H2G message. It would test the GuC CT path without abandoning GuC submission, but it is not a one-flag change: Meteor Lake is the one platform that needs GuC invalidation, and GuC-based GGTT invalidation is documented as incompatible with MMIO invalidation (commit af58ee227662). The experiment matrix lists it with that warning.

Holding the GT awake against letting it idle. A forcewake or RC6-off hold is the one mitigation that two independent non-Arrow-Lake ports report as helping: the FreeBSD drm-kmod maintainer's Meteor Lake case (drm-kmod 457) and the zep245 macOS port notes. The costs are power and heat on a laptop that already runs at 100 C on a CPU lap, and the counter-evidence is direct: the owner of the xe 8678 investigation pinned the GT at C0 with zero C6 residency and still saw nine acknowledgement timeouts. The two readings are compatible if the xe bug is GuC-side (a late reply) while the macOS stall is CPU-side (a write that blocks), which is why the experiment is worth running as a 2x2 with the waker thread instead of being assumed to work.

Hybrid composite route against XeGfx driving WindowServer. In Hybrid mode the iGPU owns the panel. The conservative route lets NvGfx composite on the NVIDIA GPU and lets a small framebuffer driver flip scanout on the iGPU, which the nmx-intel project demonstrated on Raptor Lake (nmx-intel). It does not depend on the XeGfx stall being solved. XeGfx drives WindowServer directly, which is the only route that can give a Metal-accelerated desktop on the iGPU alone, and it is also the route with the I-116 stalls. The two are fallbacks for each other as long as the Discrete NVIDIA boot remains the daily driver.

Stay on 26.7.1 against moving to 26.7.2. The offline route recovers the 26.7.2 collections without installing, so the decision no longer depends on first updating a machine to look. The remaining tradeoff is between per-build ABI pins and a fingerprint approach. Per-build pins are safe but fail at day one of every update, as the first public 25G332 report on the project's own native Wi-Fi shows (mt7925-hackintosh-wifi issue 4). A fingerprint over class sizes and vtable slots accepts a new build only when the layout is unchanged. The horizon is bounded in any case: macOS 27 is Apple silicon only, so Tahoe is the last Intel release (OCLP issue 1183).

A native Wi-Fi front end against a layout-independent driver. MtkWlanNative integrates with the private IO80211 and Skywalk classes, which gives the system Wi-Fi menu but ties each release to a build. The Intel-card projects that avoid private layouts, such as the itlwm line and SimpleBCM (itlwm, SimpleBCM), were reported working on 26.7.2 on day one. For MT7925 itself, no layout-independent driver exists, and the two public native MT7925 lines (ours and thanhnndev's) report WPA2 joins only, with no 6 GHz, AWDL or sleep support. Swapping the card for an Intel one is what most Gen 10 Hackintosh EFIs do (wsjj EFI), at the cost of opening the laptop and of the Bluetooth path.

VT-d off or DMAR dropped against VT-d left on with an APIC replacement. The Arrow Lake community splits. Several desktops and laptops pass the ExitBootServices stop only with VT-d off or the DMAR table dropped, and the 1401 maintainers encode that as a rule (efi_rules.json). Other 275HX laptops boot with VT-d on, DMAR deleted and a custom APIC table (YaoShi16 EFI). The Legion keeps DMAR and replaces the APIC table, and its normal boots pass. VT-d state is the one variable that has never been recorded for the failing I-118 boots, so changing it now would add a variable, while recording it would not.

Newer microcode through OpenCore against waiting for a Lenovo BIOS. Microcode 0x11b is two Intel releases behind (0x121 and 0x122 exist), and Lenovo's newest BIOS for this machine, S2CN26WW, only updated CSME. Loading newer microcode over an older BIOS revision has broken boot on other Intel parts in 2026 (microcode issue 112), and no public text ties either newer revision to the one open erratum (ARL037). The expected value of loading it as a stability fix is low and the downside is a non-booting machine, so it is a last-resort experiment and not a mitigation.

Scope: what operators, maintainers and users reported and did, for Q1 Linux/BSD/macOS-port freezes on MTL/ARL, Q2 NVIDIA via NullMoth, Q3 Intel Xe on macOS, Q4 macOS 26.7.2, Q5 MT7925 and Legion Gen 10, Q6 resets after ExitBootServices. Sources: the practitioner sections and findings of Aspect 1 to Aspect 15 (cited by their primary URL), plus NEW direct fetches today (marked NEW; read-only gh api GET, GitLab REST descriptions, one WebFetch). Date checked for all rows: 2026-10-27. Tier: S primary or maintainer text, A expert with data, B user report, C press. Breadth: anecdote = one machine or person, few = 2 to 5 independent reports, broad = many independent reports. GitLab comments return 401, so closure reasons and maintainer replies on freedesktop issues are not visible.

Agree: a stage of recoverable TLB-ack timeouts (26 in 47 h, 20 to 60 per day) often precedes silent freezes; the freezes leave nothing in the journal and the NMI watchdog stays quiet (R5, R6); xe is worse than i915 on the same machine (R6, R12); kernel upgrades helped most (Aspect 4). Non-Linux ports (R8, R9) independently found that keeping the GT out of RC6 or parked cures their hang. Disagree: causes. Intel-side fix for acks is cache coherency (R2); FreeBSD and zep245 blame RC6 transitions plus delayed interrupt handling; R4 and R5 blame display DSB/DC; Intel calls R3 a power-sequencing race. Confounded mitigations: psr/dc/ASPM/C-state results are mixed and often changed together (R7), several "fixes" were kernel or BIOS updates in disguise, and R2's all-domain forcewake hold did not stop the ack delay while R8/R9 holds did cure a harder stall, so the two symptoms may differ. The single IRQ-pinning report (R7) is unconfirmed. New: Intel's own ARL-H CI silently dies in many unrelated selftests (R11), which fits a platform-level stop rather than one GuC path; caveat: "incomplete" can also mean lost logs. No report matches I-116 (23 of 24 CPUs answer) on 7D67 in any OS.

Agree: 2.6.2 is stable enough that users measure rather than crash-report; MPS, Vision, Geekbench compute remain broken on every generation; drag stalls come from per-upload IOSurface import and VRAM re-import (R17); HiDPI needs the hi-res flag and hits a head-scaler ceiling (R18); HDR is blocked by the "NVDA" class path (R19); Chrome flicker goes away with Graphite off (R20); Blackwell laptop users get almost no NVIDIA help and TGP only lifts through platform negotiation (R23). Disagree: scaler ceiling 1.3x vs 1.4x; 12-byte vs 16-byte scale-resolutions by macOS version; the maintainer says the hang is gone in 2.5.2 while 377 shows translation still fails. Confounded: R22's idle freezes survived 60 Hz and flip_latch=2 (so those are not cures); reinstall fixed one "regression" (NullMoth 259, NEW); fixes in downstream forks are single-machine and often AI-assisted, which upstream refuses.

Agree: all four Xe-on-xnu stacks (Mountainatic, jwx29, VedCloud, zep245) keep the firmware-lit panel, activate by hand after boot, descend from NullMoth's tree, and say stability is not established; none reports a multi-hour soak; their panics are the same classes (thread_call cap, preemption_level, userptr free, TLB flush timeout, firmware pages). WhateverXe and JulioNectar stay on Gen12. No third-party issue or reply exists on any of these repos (NEW check). NullMoth's own Intel driver is on hold (297).

Agree: day-one reports from stacks that do not touch private IO80211 layouts (itlwm, SimpleBCM, Lilu kexts) are clean; the only public break is ours (native Wi-Fi gate). No acidanthera issue or commit mentions 26.7.2 or 25G332 (NEW scan). Disagree: whether the BT loss in R27 is the update or hardware state. Confounded: R27's Bluetooth returned after a suggested power drain, but the step actually taken is unknown, and the reporter's board differs from R28's working 25G241 report; 25G330 is an RC, 25G332 is final (kgp and our own notes used the wrong one first).

Agree: two native lines run MT7925 on Tahoe (ours, thanhnndev), WPA2 only at about 90 to 180 Mb/s, no 6 GHz, AWDL or sleep; warm restart can wedge the card until a cold power-off (our mt7925 1; Linux mt76 reset fixes). Gen 10 Hackintoshes elsewhere mostly swap in Intel Wi-Fi (wsjj Y9000P BE200, ASUS FX608LP). Disagree: WPA3 (BelikPePe says works, thanhnndev no confirmed WPA3). NEW: AppleALC PR 975 (Ersiter, 10-27) adds ALC287 layout 99 for Legion IAX10H, acidanthera/AppleALC#975.

Agree: nobody has posted an Arrow Lake case of a reset (as opposed to a hang) after EXITBS; hang advice is VT-d off (X2APIC first on some Insyde laptops), MADT type 9, DevirtualiseMmio. Practitioners treat a cold power cycle as the cure when a prior OS left hardware in a state (R32, R33). Disagree: VT-d (our post to 1401 says DMAR is still exposed on our boot, others require it off); CpuTopologyRebuild and SetupVirtualMap on or off. Confounded: hang advice does not transfer to a warm-only reset. Negative search today (1401, NullMoth, acidanthera for reset/reboot/after Ubuntu/Windows) found nothing.

• ArrowWhatever "about 60 fps, no tearing" (K9): same-day, no logs attached; its only soak (40 min, https://github.com/Mountainatic/ArrowWhatever/blob/main/docs/performance.md) ran at about 18.8 presents/s before K9. Longest run for any Intel macOS stack is about 40 min.
• ArrowWhatever "0 panics": 200 s run plus 40 min; the project's own pre-patch panic came at about 20 min. README says it is mainly LLM-built.
• jwx29/XeGfx description claims Arrow Lake operation, but the repo is a mirror 0 ahead of ours; VedCloud "26,000 frames" is self-reported and the project moved to macOS 27.
• zep245 links the TLB flush timeout to RC6 only by timing; no root cause.
• NullMoth "fixed in 2.5.2" covers the hang only (377). HDR "force8BPC" is one unreproduced trace. mickys branches carry AI trailers and cannot go upstream.
• thanhnndev and BelikPePe results are single-machine, untested for WPA3; HackSucks mtwlm is untested on Tahoe; xarmaq sleep branch is unaudited.
• Hackintosh "works" tables for Gen 10 laptops are self-reported (Aspect 14). 1401 TROUBLESHOOTING still says EXITBS is core layout or memory map, while its own 2.6.0 notes say VT-d.
• Linux "fixed by 7.0.10-201" claims mix kernel and BIOS changes (Aspect 3).
• Intel CI "incomplete - No warnings/errors" is inferred to be a silent stop; the harness cause is not stated.

1. Marked NEW in the table: R11 (Intel CI ARL-H silent stops: 16 of 17 issues since 08-01, counted by GitLab REST label platform: ARL_H; MTL_P has 23 among the first 200; xe tracker ARL has 6, all community), R12, R13, R22, and R27 (Bluetooth back at 18:45).
2. FreeBSD 457 (as400l, 07-20): drm-613 freezes the whole OS where drm-612 stays reachable. FreeBSD 527 (Comet Lake, freebsd/drm-kmod#527): hangs tied to shmem page-out, cured by turning swap off; a cross-check for any shim shmem path.
3. NullMoth 259 and 1401 48: 5070 Ti desktop "choppy UI" after 2.5.x, resolved by reinstall under Tahoe.
4. acidanthera bugtracker 2561 (BlueToolFixup CSR pairing, Codex-assisted, Sequoia) and BrcmPatchRAM 39 (bluetoothd patterns are build-specific): nobody has tested BlueToolFixup on 25G332 with a real controller.
5. No new commits for zep245 since 10-25; jwx29/NvGfx pushed "VRAM Reporting" 10-27 18:21; NullMoth Discussions are disabled, so Discord content is not indexable.

Scope: break the emerging I-116 / I-118 / macOS 26.7.2 conclusions. Tiers: S primary, A expert data, B user report, C press, D weak. Confidence is mine, date checked 2026-10-27 unless noted. GitLab comments were read through the public GraphQL endpoint (the HTML is behind Anubis); lore.kernel.org is 403, so lore links are quoted from GitLab comments only.

C1 (High). The best-known root cause cannot be ours. Wa_22016122933 is scoped to the media GT; XeGfx skips that GT in seven boots (V6). The xe fix is untested on 7D67 and says nothing about GT0 (the xe owner told a GT0 wedge reporter that her series "would not have prevented this", note 26). Do not write "I-116 is the 2.3 s cache bug". https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8678

C2 (High). Linux freezes are mostly a different class from N-290. 9168 (ARL-H 7dd1): the freeze came in the same second as the timeout, but the kernel stayed alive (journal kept writing, SysRq-S ran), nmi_watchdog=panic never fired. 9168 note 4 (today, ARL-H 7dd1): timeouts come minutes to hours before the freeze, kernel alive, 4 power-offs in one day. N-290 is the opposite: all other CPUs silent to NMI for 0.5 s, then a panic. https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/9168

C3 (High). A forcewake hold does not cure the TLB-ack bug (V18). Answer to the brief: no, a hold would not stop the xe 8678 stall; it is GuC-side (8 to 9 doorbell kicks ignored, worst 5996 ms) until the cache theory. But XeGfx's problem may be CPU-side (a doorbell write that blocks), which the hold could still help. Two separate mechanisms; the corpus merges them.

C4 (Medium-High). Setup-specific. Same silicon, same XeGfx 0.0.44, same macOS build did a 40-minute soak with zero stalls (local evidence). N-290 died at 88 min under an APFS resize (heavy I/O, NVIDIA boot). Suspect the I/O, the dGPU, the BIOS or config before the TLB path.

C5 (Medium). ARL037 is a weak fit. Intel text: C6 or deeper entry/exit, no MCE, synthetic only, BIOS workaround possible. It hangs a core within a module, not 23 of 24 CPUs. 9168 note 4 froze four times with intel_idle.max_cstate=2, xe.enable_dc=0, PSR and FBC off. Newer microcode is not documented to fix it. Keep it as a low-probability lead, not a cause. https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/9168

C6 (Medium). "Wa applied, platform still dies." xe 8678 note 28: the owner's 7d51 machine locked completely on 2026-09-16 on a kernel with the WA, with no log line at all and the NMI/pstore route capturing nothing. So even on Linux a silent whole-platform death exists that the cache fix does not explain. It is the closest published analogue of N-290, but 7d51 is not 7D67. https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8678

C7 (Medium). Every free sends an H2G is overstated (V3). The free-worker and execbuf stacks may still be one event, but through a different gate than "every free".

C8 (Medium). 2.3 s late ack vs a stall that outlasts the panic path. A late ack is a fence timeout while all CPUs run. N-290 reads in two phases (panic-string-133823.txt, xnu mp.c): CPU 5 timed out in mp_rv_action after 2.0 s with 23 of 24 CPUs entered, so one CPU never arrived (id not printed). Then in mp_kdp_enter none of the other 23 CPUs acked even an NMI (1 ack of 24, two 0.5 s waits). A single stuck CPU explains phase one; phase two needs a shared stall (SMM/SMI, fabric or memory, iGPU DMA with VT-d off) or CPUs unable to take NMIs. An uncached MMIO write to a hung target stalls only the issuing core (reasoning, Unverified).

C9 (Low). Possible shim analogue of the cache bug on GT0. If the shim maps GuC shared memory cacheable while the GGTT side is snooped differently, a stale-line effect could appear on GT0 too. Untested idea, no source. Check how xg_vm.c maps CTB pages and what PAT the GGTT entries use.

C10 (Low). Leads that do not match. i915 17098 (7D67 corruption with DDR5 at 7600 MT/s or above, i915 not xe): https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17098 (not re-fetched). Oct 2026 execbuf presumed_offset fault fixes: not relevant to a stall.

• xe 8678 now holds the answer to the 2.3 s bug: three commits in drm-xe-next (63360b32, fc668a6e with an H2G hunk in xe_guc_ct.c, d5b0bf3f), d5b0bf3f queued for 7.4; backports tested clean on ARL-H 7dd1 and 7d51 (notes 45, 49 to 52). https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8678
• Follow-up "drm/xe: Map Wa_22016122933 buffers WC on the CPU side" (navonjohnlukose, 2026-10-03): d5b0bf3f alone maps the buffers UC on the CPU and regresses xe probe from ~0.35 s to ~3 s and s2idle resume to ~2.9 s; WC fixes both. Only matters if XeGfx ever brings up the media GT. Link (not fetched, 403): https://lore.kernel.org/intel-xe/20261003222145.67240-1-navonjohnlukose@gmail.com/
• media GT "not started" job timeouts remain after the WA (about 1 per 100 h, recovers in under 1 s). Same thread, notes 47 and 52.
• i915 16052 (7d67, reported on Arrow Lake-S): Intel's jkrzyszt, 2026-10-08, calls it a hardware or firmware power-sequencing race, asks for cold-boot vs warm-reboot comparison and dGPUs disabled; 2026-10-27: will close as not reproducible without the reporter. Relevant to I-118 (warm vs cold state). Intel's text is marked LLM assisted. https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16052
• i915 12104 (MTL, forcewake timeouts): triage ping 2026-10-26 asking for a drm-tip retest. https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/12104
• Intel ARL spec update rev 024 (Oct 2026) adds ARL077 to ARL079 (perf counters, missing #UD) and removes ARL072 and ARL073. None touch C-states, MMIO or the GT. ARL075 (IRET shadow stack) is Fixed.
• xe 9224 (GT0 wedge: "Timed out wait for G2H, action 550e") and 7694 (MTL, four 6.19 commits exposing the same signature) were read only as quoted in 8678 (note 26, 43). Not fetched directly.
• No new Linux commit touching the MTL forcewake table for 0x1901f0 in master as fetched today.

1. Late ack or blocked doorbell? I-116's frame is a CPU-side write inside intel_guc_ct_send. The Linux bug is a CPU-side read of a stale reply. Different mechanisms; nothing published shows the write side stalling.
2. One stuck CPU or the whole machine? The rendezvous count (23 of 24 entered) favours one CPU that never arrived; the NMI silence of the other 23 favours a machine-wide stall. The panic string does not name the missing CPU: the "NMI pending" list is every CPU except the panicking CPU 5. Candidates (CPU-side MMIO wait, SMM/SMI, fabric/memory, iGPU DMA) are not ranked by data. A second panic with cpu_signal state or a kdp-free capture would be needed.
3. Does I-116 share a cause with the Linux "silent platform death"? C6 suggests it might; unprovable without a trace on a 7D67 part.
4. I-118: microcode persistence across warm reset (V15), iTCO watchdog, VT-d/DMAR state, and 16052's "cold vs warm" are all candidates. I did not re-verify the iTCO and DMAR findings of Aspect 15; they stay Unverified.

• "Needs GT forcewake" becomes "a FIXME workaround in the fw table takes GT forcewake for that offset" (V1).
• "Every free sends a TLB H2G" becomes "a free of an object with an unbound VMA, if not coalesced and the GT is awake" (V3).
• "The 2.3 s acks are root-caused to stale cache lines" becomes "root-caused for the media GT on xe; GT0 and other stalls are separate" (V5, C1, C6).
• "Same-silicon reports end in freezes" becomes "some freeze, kernel alive; one silent platform death even with the WA" (C2, C6). Drop 16052 from the list (V8).
• "Forcewake or RC6-off hold stops freezes" becomes "correlated with fewer freezes in two non-ARL ports; the owner's own A/B on ARL showed no effect on the ack stall" (V9, V10, V18).
• "ARL037 columns" in Aspect 2 item 10: correct to HX Planned Fix, U N/A, H Fixed (V11). Call ARL037 "possible, synthetic-only per Intel".
• "Microcode persists across a warm reboot" becomes "plausible, one distro regression suggests it, not stated by kernel docs" (V15).
• "ArrowWhatever's patch explains I-116" becomes "different failure signature; may be a separate bug worth porting" (V13).

Aspect 5's 0x11b-to-BIOS mapping; Aspect 15's iTCO and DMAR claims; xe 8760, 9224, 7694, 7686; i915 16937, 17311, 17098 details; the lore.kernel.org patch bodies; Intel SDM statement on microcode persistence; the exact Intel doc URL for 834774 (document number read from the PDF, URL pattern not re-fetched).

1. ARL037 on HX. Aspect 2 reads spec update rev 008 as "Planned Fix in four of five steppings", with the column order inferred and ARL-H "N/A". Aspect 5 reads rev 024 (2026-10): HX and S still Planned Fix, ARL-H moved from Planned Fix (rev 008) to Fixed. The two disagree about H in rev 008. HX is Planned Fix in both. Aspect 4 cites only the May 2025 text. Confidence Medium; the column mapping is inferred, re-read the table before using it. Sources: https://cdrdv2-public.intel.com/834774/834774_024.pdf and https://edc.intel.com/output/DownloadPdfDocument?id=8247.
2. Microcode. Machine runs 283 = 0x11b (Aspect 5). Aspect 4 and Aspect 5 agree on the list (0x118 to 0x122). Aspect 5 says "three newer revisions" but lists two (0x121, 0x122) and later "two Intel releases behind". Dates: 0x121 on 2026-05-12, 0x122 on 2026-08-11. No public text maps either to ARL037; the INTEL-SA-01441 page contradicts itself (denial of service vs privilege escalation, Aspect 5): https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01441.html.
3. Which 26.7.2 build ships: consistently 25G332 (final, 2026-10-26); 25G320, 25G325, 25G330 are RC1 to RC3 (Aspect 11, Aspect 12, Aspect 13; https://github.com/littlebyteorg/appledb/blob/main/osFiles/macOS/25x%20-%2026.x/25G332.json). Open points: appledb lists an installassistant source on 25G325 that nobody explained; the only KDK is 25G330 (https://github.com/dortania/KdkSupportPkg/releases/tag/25G330); Aspect 11 calls the 25G332 kernel string "a gap" while Aspect 12 derived it (12377.161.15.701.48 vs 25G241's .700.19).
4. Wa_22016122933 versions: Aspect 1 "in master via drm-next-2026-10-21, not in v7.3, targets 7.4"; Aspect 3 "not in v7.1, v7.2 or the v7.3 tag"; Aspect 6 describes the mapping as CPU write-combined, GPU uncached; Aspect 3 says a coherent mapping did not help but CPU-WC with GGTT UC worked. Compatible, but nobody states it plainly. i915's version is from 2023 (https://github.com/torvalds/linux/commit/a161b6dba6e0e8132921a6b948d311cdf67f3476).
5. GuC firmware: Aspect 6 says "nothing newer than GuC 70.53.0 to try"; Aspect 1 cites drm-firmware MR !84 (70.74.0, merged 2026-09-02, https://gitlab.com/kernel-firmware/drm-firmware/-/merge_requests/84) and Intel CI logs on 70.74.0 (i915 17311). Correct: 70.53.0 is the newest in linux-firmware main; 70.74.0 exists outside it.
6. GitLab access: Aspect 1 says issue comments return 401 so maintainer replies are invisible; Aspect 6 reads Intel developer comments through GraphQL; Aspect 3 says xe #8678 was unreadable while Aspect 1 gives its details. Quoted maintainer comments need a second look.
7. Naming and IP version. The kernel and Mesa call 7D67 ARL-S (mtl_info, arl_u); the machine is ARL-HX; ARL-H parts (7d51, 7dd1) are 12.74 Xe-LPG+. Our own probe reads 12.70, media 13.00, display 14.00 (watchthelight-labs/XeGfx#2). Many "ARL" evidence rows are ARL-H or ARL-P (xe #8678, i915 #16937 on 7d51), so they match the silicon family but not the die.
8. Tier labels differ for the same source: xe #8678 (S in one block, A in another), zep245 DESIGN.md (A vs B), ArrowWhatever (S vs self-reported).
9. xnu: public source ends at xnu-12377.121.6 (Aspect 3 reads it) while the Legion runs 12377.161.15.700.19 (Aspect 11), so panic strings map to source only approximately.
10. I-118 timing: Aspect 14 says resets 15 to 40 s after EXITBS:START; Aspect 15 argues an iTCO watchdog with a 30 s default (Linux driver value, not measured on this firmware). Plausible, unproven.

• "About 2.3 s" late-ack delay and "about 1000 DC transitions per minute": from titles or single reports (xe #8678, i915 #16937).
• "Three newer microcode revisions" (two listed). "115 W" is Lenovo's rating (https://psref.lenovo.com/syspool/Sys/PDF/Legion/Legion_5_15IAX10/Legion_5_15IAX10_Spec.PDF), NVIDIA lists 50 to 100 W (https://www.nvidia.com/en-us/geforce/laptops/compare). "92 W under stress" is a different SKU.
• Soak and fps numbers from ArrowWhatever and VedCloud: self-reported, no artifacts.
• "417 issues scanned" (Aspect 3, Aspect 11) vs "about 60 threads dumped" (Aspect 8) for the same NullMoth tracker: scope differs by aspect; do not aggregate.

These are the ways the evidence in this dossier is most likely to mislead, grouped by theme. Each theme also lists its own limits above; this section collects the traps that matter when a result is written into project notes or a public page.

Do not write that I-116 is the 2.3 s cache bug. Wa_22016122933 is scoped to the media GT, our log shows GT1 skipped, and the workaround's own reporter saw a silent death with it applied. The trap is borrowing a published fix's confidence for a different mechanism.

The panic's 2.0 s is a timeout, not a measurement of the stall. Reading "a 2 second hang" from it, or the 27 s figure from the N-287 README, misleads: the saved progress file contradicts the README, and the real duration is unknown.

"Forcewake hold fixes it" is two claims. It correlates with fewer whole-system freezes in two ports, each a single machine without a controlled A/B, and it did not stop the late-ack stall on Arrow Lake in xe 8678. A hold that cures I-116 would not prove the xe mechanism, and one that fails would not rule out a CPU-side blocked write.

Several sources are tier B or LLM-assisted: the Intel text on i915 16052 and 12104, the Tiger Lake port's notes, ArrowWhatever's soak, and the FreeBSD BAR2 PR 496 (single author, unreviewed). The lore patch body was not read (403). Last, load correlation is easy to over-read: N-290 is one panic during one APFS resize, and the 20 ms checker may have changed the rate, so a clean 88 minutes is a hint, not a result.

Anchoring on ARL037 because it is the only erratum with the right shape is the main trap: Intel's wording (synthetic, no MCE, one core) is narrower than the panic, and a machine-wide stall would make it a wrong cure. The waker "result" is one observation with a changed instrumentation set, which can hide a coincidence.

Several aspect-level statements should not enter the project notes: that OpenCore decodes reset causes, that Arrow Lake does not use intel_idle, that three newer microcode revisions exist, and that ARL037 is fixed on HX. Where the early research reports and the later verification checks disagree, the checks win.

For I-118, "EXITBS" is a logging boundary and "15 to 40 seconds" mixes POST and human reaction, so both look more precise than they are. The four failures also come from one sequence, so GSP, microcode and VT-d each fit all four rows and none is separated from the others. A cold pass such as N-293 (Discrete NVIDIA, VT-d on) says little about Hybrid mode or a post-Linux boot.

Finally, 1401 guidance comes mostly from desktop and Insyde laptop reports. Copying "VT-d off" or "CpuTopologyRebuild on" into a config that already passes would change behaviour for no proven gain, and any such change touches the OpenCore config and needs Bash's OK.

The race fix could be mistaken for an I-116 fix. It closes a real window, but the failure signature differs; if the stall continues after the port, the log should say the race was removed and the stall remained.

Self-reported peers are rated B for a reason. ArrowWhatever and jwx29 are LLM-driven projects with results from one machine each and no independent reproduction. Their "stages passed" counts are bring-up milestones, not stability, and a pass on their hardware says little about ours.

The HiDPI story keeps moving. The 1.3x ceiling, the 12-byte versus 16-byte split and the missing-flag explanation have each been corrected at least once, and the flag is in our package although its effect on 26.7.1 may be nil. Do not state a cause in a public note until a mode list changes after a boot.

A 115 W control that works on AC says nothing about battery, sustained thermals or Dynamic Boost. The Linux issues describe platform handling that macOS reaches only through our opt-in boot-args, so their fixes may not transfer.

Translation counts ("53 to 0 failures") can hide a faulting GPU. Count rendered frames, GPU faults and Metal errors rather than translator statuses, and do not adopt 419 until its conflict with 385 is settled in a test.

"25G330 is the 26.7.2 release" is wrong and is already in our notes and a public reply. The identical Intel kernel files for 25G330 and 25G332 make the mistake harmless for kernel-side questions, but that equality must not be stretched to user-space files such as bluetoothd or airportd.

A clean kcabi result is not a pass. It covers three kernel families of one vendor stack; the OTA bill of materials shows airportd at 3,228,064 bytes on 25G241 and 3,228,096 on 25G332, so the Wi-Fi daemon changed too. The Wi-Fi menu depends on user-space behaviour kcabi cannot see, so a boot test stays necessary.

The reporter's Bluetooth recovery is easy to over-read. It is one anecdote from a desktop board, the step is unrecorded, his Wi-Fi refusal reason was never captured, and a card-state fault explains it as well as an OS change. The Legion's own bluetoothd is also unexplained: its CRC32 does not match the OTA's record of 25G241, so claims that rely on "stock 25G241" for that binary should wait until this is understood.

Hackintosh EFI repositories are not proof for our machine. They have other SMBIOS identities and other panel routing (wsjj disables the iGPU and drives the panel from the NVIDIA GPU, while our Hybrid boots use the Intel iGPU), and their documentation can drift from their plists. 1401 rules are scoped by machine class, and a rule that fixes a desktop can panic a laptop.

Some figures are not primary: the three-year Intel security horizon is press relay, and the AI-written thanhnndev README reports performance for one laptop. Neither belongs in our public pages as established fact. Absence of reports is also weak evidence: no acidanthera issue mentions 26.7.2 and no NVIDIA or Xe driver has a 25G332 report, mainly because few people have updated yet.

The gaps are listed by how much they change a decision, not by theme.

No public analogue with CPU backtraces exists for an NMI-ignoring stall on this silicon. Every public Meteor Lake and Arrow Lake freeze report found (xe 7694, 9168, 9224, i915 12104, 16937 and others) comes from Linux, and the ones that identify a mechanism describe a live kernel (SysRq works, the journal keeps writing) or a total silent death with nothing captured. None carries a per-CPU state dump comparable to the I-116 panic. The research therefore ranks mechanisms by plausibility, not by a match to a published trace, and the strongest items (the doorbell write, the TLB invalidation path, the power-state errata) are candidates. Nothing found shows the CPU-side write stall that the I-116 frame suggests.

The one confirmed root cause for Arrow Lake GuC late acknowledgements probably does not apply. The stale-cache-line fix (xe commit d5b0bf3f37f1, Wa_22016122933) concerns the standalone media GT. XeGfx skips that GT in every recorded boot, so the fix is relevant only if the media GT is ever brought up. The public evidence for it comes from ARL-H parts (7D51, 7DD1), not 7D67.

Intel documentation is partial. There is no public programmer's reference for Meteor Lake or Arrow Lake graphics, so register behaviour comes from kernel source only. The Arrow Lake specification update (revision 024, October 2026) lists ARL037 as "Planned Fix" on HX, but the column mapping was read from text extraction and from an earlier revision, and Intel does not map errata to microcode revisions in public text. Whether microcode 0x121 or 0x122 changes anything for I-116 or I-118 is unknown. The contents of Lenovo's BIOS S2CN26WW (microcode revision, SAGV, ASPM and C-state options) were inferred from sibling readmes and the revision the machine reports, not read from the firmware.

Search reach was limited. The shared web search budget (200 calls) was exhausted during the run, so the later work used direct fetches only, and every "no report found" statement means "none found in one pass". Specific blind spots: Chinese-language Hackintosh forums (pcbeta, the 黑果小兵 blog, bilibili); gitlab.freedesktop.org issue pages (behind a bot check, so comments came through the public GraphQL endpoint and closure reasons stayed invisible); lore.kernel.org (403, so patch bodies are quoted from tracker comments); FreeBSD Phabricator and Bugzilla; Intel's older specification-update revisions (403). The Legion Pro and 285HX Gen 10 variants have no Hackintosh reports in the sources reached.

Self-reported project claims were not reproduced. The Intel Xe on macOS projects (ArrowWhatever, jwx29's fork, VedCloud, zep245) publish frame rates, soak lengths and "zero panics" figures without attached logs, and several are partly built on this project's own XeGfx core. They are graded B and treated as claims. None of their longest soaks exceeds about 40 minutes, which is shorter than the failure window of I-116.

The 26.7.2 work is byte-level only. The kernel collections were reconstructed and checked against hashes, and a class-layout comparison against 25G241 ran, but nothing was loaded on hardware and nothing was installed. Whether the three layout differences break MtkWlanNative, and whether the build-specific Bluetooth byte patches still match, are untested. The public xnu source tag (12377.121.6) is older than the kernel the Legion runs (12377.161.x), so panic offsets map to source only approximately.

I-118 rests on analogy. The leading explanations (microcode persisting across a warm reboot, a Linux-armed TCO watchdog, GSP/WPR2 state left by the previous OS, a VT-d state difference) come from precedents on other CPUs or other drivers, one of them from 2019. No public report describes an Arrow Lake reset, as opposed to a hang, at that point in the boot. Nothing decisive can be said until the cold-versus-warm column and the microcode revision are recorded across a probe-then-macOS pair.

Date and naming conflicts remain in the sources. Two ARL037 column readings disagree about the H line in revision 008 (both agree HX is Planned Fix); a repository's commit dates read as 2026-10-28, after the day of the run; the project's own tracker calls 26.7.2 "25G330", which was the third release candidate. These are listed with the other inconsistencies in the contradictions section.

This section keeps the objections as raised. The theme text, the key insights and the ranked actions were edited in response, so some quotations below (for example the wording of the stalled-MMIO insight and the position of the NVRAM-trace run in the list) describe the drafts before the edits. I attacked the dossier's strongest claims and its ranked actions on 2026-10-27 with read-only fetches. The factual spine held: intel_idle has no Arrow Lake table (intel_idle.c, S, High), and S2CN26WW and microcode 0x11b are as stated. The inference on top did not: which mechanism I-116 is, which control is a control, and which experiment goes first.

1. The stalled-MMIO reading is over-read (high). Theme 1 says our observables "fit a stalled MMIO transaction" and leans on Gleixner's mail (A). That mail is about HPET-clocksource time failing to propagate after a hung PCI config read, so "the NMI is a red herring" is a statement about that path, not a rule. The N-287 panic CPU took an IPI (cpu_signal_handler sits above fwtable_write32+0xfa in evidence/native/N-287/panic-string.txt), so it was a waiter that happened to run driver code. N-288 to N-290 put the panic CPU in idle, in pmap_remove_range and in APFS nx_bio_doread: one run of four is in the driver. Both timeouts are xnu constants (S), and the silent CPU is unnamed. The data say the machine stopped answering for at least 2.5 s. They do not separate a hung uncore write, an SMI, an EC or firmware event, or a failed deep-idle wake. MMIO confidence: Low.

2. SMM is an unnamed, testable rival (high; Low confidence). xegfx.nvram_trace writes xegfx-step every 250 ms through native NVRAM and has been on in every guard capture since N-223. On EDK2-derived firmware, runtime variable writes are normally sent into SMM (VariableSmmRuntimeDxe.c, S), and zep245 measured about 19 ms per sync (DESIGN.md, B). Whether this Insyde build does so is Unverified. An SMI stops all threads while TSC keeps counting, which fits the 2.0 s first phase; the second needs a stall that outlasts 2.5 s or recurs. The discriminator is the SMI count (MSR 0x34) plus TSC gaps. Theme 3 calls the switch "cheap to close and unlikely to be the cure" while the master list puts the run ninth.

3. The experiment order is wrong (high). Cheaper steps sit behind a 12-session design. (a) Set debug.legioncpu.{pl,hwp,epp} to stock for one session: a sysctl, no kext change, no reboot. (b) Check whether the existing LegionCpuProbe 1.1 can already read MSR 0x34 before proposing a kext change. (c) One nvram_trace=0 run. Only then the 2x2. Thirty-minute sessions may show nothing: 0.0.43 passed 900 s and died at 88 minutes, and an arm with zero events teaches nothing. Each stall ends in a panic or hang, and an unclean end already rolled APFS file sizes back at N-293 (N-292 README). Use a stopping rule, not a fixed 12.

4. LegionCpuPower is an uncontrolled variable (high). Version 0.4.1 was loaded in N-290 (evidence/native/N-290/guard/kmutil.txt). It lifts the MCHBAR limit to 120/168 W and gives every core its own HWP range, which is MMIO and MSR traffic into the same power machinery any stall or idle-exit story involves. The I-116 themes never mention it, and Linux ran at stock limits, so it is no control for it.

5. The controls are weaker than described (high for "another shim"). ArrowWhatever was created 2026-10-25, has 0 stars and describes itself as built on XeGfx, so it is our shim plus overlay patches. Its 40-minute soak is self-reported (B), tests its own userptr fix, and falls inside our own spread. Linux N-274 ran 47 minutes without WindowServer, XeGfx or LegionCpuPower. A read-only diff of its overlay patches against our branch is worth more than either.

6. Firmware and idle reasoning contradict themselves (medium). Theme 1 says the fix "may live outside every driver" and asks for "a BIOS with the pcode half"; Theme 2 says "No firmware fix exists to wait for" at High. Both rest on absence claims from one search pass. macOS does not load microcode, and no newer BIOS exists to flash. Theme 2 says the waker "adds C6 transitions" while the N-290 README says it keeps cores out of deep idle; neither is measured. The spinner arm also changes power, temperature and the guard's 10 W steps, so it is not a clean idle control.

7. Risk and wasted reboots (medium to high). tlbto_us=0 makes xnu trace without panicking, which removes the one artifact I-116 yields and turns a stall into a power-button hang. A larger slto_us answers "does it end" only for stalls between 2 and N seconds; a TSC-gap log needs no NVRAM. On 2026-10-27 the live OCEFI config reads SetupVirtualMap false and ForceExitBootServices true, while the public EFI copy shows the reverse, so the Booter A/B changes a working, picker-less boot path and may reproduce an I-118 stop for nothing. The "per-CPU heartbeat" is a second waker. The allow-list entry looks like policy, but MtkNativeAbi.hpp (source) is a safety gate, and kcabi's _kern_netif_queue_rx_enqueue field move (0x4d8 to 0x4e8) is unreviewed.

• Selection. Linux trackers hold failures; clean runs are silent. The "Linux Xe reports" class is over-represented.
• Confirmation. Our two hypotheses (MMIO stall, C6 and the waker) framed the queries; SMM, EC and MCA material is thin because nobody searched for it.
• Recency and volume. About two thirds of the sources are GitHub, many under two weeks old, and some Intel comments are LLM-assisted.
• Vendor. Intel's spec update lists what Intel found; "Planned Fix" is not "absent".
• Survivorship and transfer. Public ports are the ones that worked, and the forcewake-hold evidence comes from two non-Arrow-Lake ports (Tiger Lake, Meteor Lake).
• Self-report and citation loops. Repos like ArrowWhatever grade themselves; FreeBSD and OpenBSD import Linux i915, so agreement is not independent.

• Stalls persist at stock LegionCpuPower limits: the power kext drops out. They vanish: it becomes the lead.
• nvram_trace=0 removes the stall: SMM or firmware cost becomes the lead, and the MMIO model drops.
• SMI count jumps across a stall, or TSC gaps appear with no SMI: that separates SMM from an uncore hang.
• A symbolized panic RIP and a named silent CPU in two runs.
• An ArrowWhatever overlay patch we lack that plausibly removes a stall.

Per run: LegionCpuPower setting, MSR 0x34 before and after, TSC gaps, cold or warm start, time to stall, panic CPU context, under a fixed load and a stopping rule set in advance.

The list below ranks the actions from all four themes by value for the cost and risk of the step. The per-theme lists after it keep the full wording and evidence. "OK" means the step needs Bash's explicit approval under the project rules (kexts, boot-args, NVRAM, BIOS, macOS updates, outside posts). Nothing here was done by the research run.

Group 1: no approval needed (records, reading, analysis)

1. Fix the 26.7.2 build name in the project records. Replace "25G330" with "25G332" (and say 25G330 was the third release candidate) in tracker rows R073 and R074, the handoff and the follow-ups to the reply in mt7925-hackintosh-wifi issue 4. A public correction on that thread is Bash's call. Target: tracker and docs. Evidence: appledb 25G332. Confidence: High. OK: not for the records.
2. Add four columns to every boot attempt row: cold or warm start, microcode revision before and after, GPU mode, VT-d state. Include the Ubuntu probe's microcode and watchdog lines. Target: tracker attempt rows, the I-118 evidence folder. Evidence: i915 16052, Intel microcode releases. Confidence: High that it costs nothing, Medium that it will separate the I-118 candidates. OK: not needed.
3. Correct the I-116 and I-118 notes. The panic's 2.0 s is a timeout and not the stall length; the 27 s figure in one run record contradicts the saved progress file; "EXITBS" is a logging boundary; StartupPowerEvents does not decode reset causes; max_cstate=2 still allows a C6-class state; ARL037 is synthetic-only and Planned Fix on HX; only two newer microcode revisions exist. Target: I-116 and I-118 evidence READMEs, handoff. Evidence: xnu mp.c, Intel 834774. Confidence: High. OK: not needed.
4. Write the N-294 attribution note before booting. List NullMoth's 2.5.4 and 2.5.5 driver changes apart from the project's commits and the two state-cache switches, and note a cold-cache warning, so one result can be read against both sets. Target: handoff and the attempt README. Evidence: NullMoth 2.6.2, issue 370. Confidence: High.
5. Read-only checks that remove candidates for I-116: whether the SSD sits behind Intel VMD (ARL004), whether powermetrics shows C-state residency, the VT-d and X2APIC rows in the BIOS and a MADT dump, whether the live bluetoothd differs from the OTA record (and why). Target: notes. Evidence: Intel 834774, Theme 2 and Theme 4. Confidence: Medium. OK: not needed for reading.
6. Audit the shim stand-ins by reading source: in_atomic, irqs_disabled, rcu_preempt_depth, the cancel_delayed_work_sync return value, the IRQ handler's context, and the cache attribute of the CT, ADS and log pages. Target: XeGfx shim. Evidence: freebsd-src 4f2f26fb1e8a, 79e290d96786. Confidence: Medium. OK: not needed for reading.
7. Review the three kcabi differences by hand (the _kern_netif_queue_rx_enqueue field move and the two NAN datapath immediates) against MtkWlanNative's callers, and write the OTA route into a small helper beside kcabi that also lists changed user-space files. Target: kcabi, abi notes. Evidence: kcabi, bxdiff50.go. Confidence: Medium (analysis), High (method). OK: not needed.
8. Document the Blackwell power finding and the 615.71.10 and 615.78.08 diff result in notes/power.md with one table of the 50, 100 and 115 W figures. Evidence: NVIDIA compare. Confidence: High.

Group 2: cheap experiments that need approval (existing switches, sysctls or stick-side work), in this order

9. A session at stock LegionCpuPower limits (debug.legioncpu.{pl,hwp,epp}), with the SMI count read before and after. LegionCpuPower 0.4.1 was loaded in N-290 and lifts the MCHBAR limit to 120/168 W and gives each core its own HWP range, while Linux ran at stock limits; none of the I-116 analysis so far treats it as a variable. It is a sysctl with no kext change and no reboot. Check first whether LegionCpuProbe 1.1 can already read MSR 0x34. Target: LegionCpuPower, LegionCpuProbe. Evidence: devil's advocate section, the N-290 guard capture. Confidence: Medium that it is worth one session. OK: yes (the sysctls change power behaviour).
10. One xe-guard run with xegfx.nvram_trace=0, paired with the SMI-count read. The trace has been on in every guard capture since N-223 and writes native NVRAM every 250 ms; the Tiger Lake macOS port measured about 19 ms per sync, and on EDK2-derived firmware runtime variable writes normally run in System Management Mode (Unverified for this Insyde build). If the stall vanishes, firmware cost becomes the lead; if the SMI count jumps across a stall, SMM is confirmed. Target: XeGfx debug knob. Evidence: zep245 design notes, VariableSmmRuntimeDxe.c. Confidence: Medium that it is worth one boot, Low that it is the cure. OK: yes (it changes what a guarded boot runs).
11. Only then, the 2x2 of the 20 ms waker against gtawake 0 and 2 (and irqoff_check=0). Use a fixed I/O load, a session budget and a stopping rule set in advance (stop an arm pair after three stalls in one arm and none in the other). A 30 minute arm may show nothing, because N-290 passed 900 s and died at 88 minutes, and every stall ends in a panic or a hang with the risk of an APFS rollback (N-292 and N-293 showed file sizes rolled back). One run per arm cannot separate a rare event; xe 8760 used a single 20 minute arm. Target: XeGfx 0.0.45, xe-guard. Evidence: drm-kmod 457, xe 8678. Confidence: Medium. OK: yes (confirm the batch).
12. I-118 arms with the Ubuntu probe stick and a full power-off between sessions, with modprobe.blacklist=nouveau so the dGPU's GSP state cannot persist, and the watchdog state recorded. Target: probe stick, no macOS change. Evidence: open-gpu-kernel-modules 1353, Arch FS#64498 (background only). Confidence: Medium. OK: Bash must be present for the power-off and any macOS restart outside a staged attempt.
13. Passive timing in XeGfx: TSC deltas around the doorbell write, the forcewake wait and the TLB-ack wait, and per-CPU timestamps in a ring read at panic. Do not add a per-CPU heartbeat thread, which is a second waker and recreates the confound; do not mix it with waker arms in one boot. The aim is to name the missing CPU of "23 of 24". Target: XeGfx shim, debug.xegfx_log. Evidence: LKML on stalled MMIO (about HPET after a hung PCI read, so a model and not a rule), 6d46d09a0d7d. Confidence: Medium. OK: yes (kext change).
14. Extend LegionCpuProbe with C-state residency MSRs, the SMI count and the MCA banks, and read the banks on the first boot after the next stall. Target: LegionCpuProbe. Evidence: Intel 834774. Confidence: Medium. OK: yes (kext change). Reading with an existing tool is read-only.

Group 3: code that closes a known defect (log it as such)

15. Port the userptr unwire fix as the project's own commit, written from the invariant stated in the ArrowWhatever note and not from their patch text, and log it as "race removed", never as an I-116 attempt. Target: XeGfx xg_vm.c, branch xe-2.6.2. Evidence: userptr note, xg_vm.c. Confidence: Medium that the window exists in the project's code, High that it differs from I-116's signature. OK: yes (kext change).
16. Test the N-294 drag work with a heavily redrawing terminal and the two state-cache switches toggled, and record the result for NullMoth issue 412. Target: NvGfx plugin, my-settings block. Evidence: issue 412. Confidence: Medium. OK: yes (staging and reboot, GPU guard rules).

Group 4: needs approval and has a real downside, or low expected value

17. A long slto_us for one stall run, as a late optional step. It only separates stalls between the old and the new timeout, needs an NVRAM write, and may waste a reboot; a TSC-gap log answers the same question passively. Do not use tlbto_us=0: it makes xnu trace without panicking, which removes the one artifact I-116 produces and turns a stall into a power-button hang. Confidence: Low to Medium. OK: yes (boot-args in NVRAM).
18. Route PPGTT TLB invalidation through the MMIO fallback. Not a one-flag change because GGTT invalidation also goes through the CT on these parts; prefer throttling or batching frees. Evidence: 2d6e2b10a773, af58ee227662. Confidence: Medium on the warning. OK: yes.
19. Decide whether to add the 25G332 kernel tag (701.48~2) to the MtkWlanNative allow-list as an unverified build, only after the hand review of the three kcabi differences (item 7) and a reporter's ioreg output. The gate is a safety gate with a live class-size check, so a wrong entry could panic other people's machines; the Legion cannot test it without updating macOS. Confidence: Low. OK: yes (kext change; updating macOS is a separate yes).
20. Quirk A/B for I-118 (SetupVirtualMap on with ForceExitBootServices off on OCEFI, stick untouched). A hypothesis from two other 275HX EFIs; normal boots pass today. The live OCEFI config reads SetupVirtualMap false and ForceExitBootServices true (read 2026-10-27) while the public EFI copy shows the reverse, so reconcile the two first, run it only with the stick ready and after the cold-or-warm column exists, because it changes the only picker-less boot path and could produce an I-118 style stop for nothing. Evidence: ASUS FX608LP EFI, 1401 issue 58. Confidence: Low. OK: yes (OpenCore config).
21. Do not do: chase a BIOS flash or microcode injection as a mitigation, install 26.7.2 on the Legion to look, or change VT-d on the strength of desktop reports. None has public support strong enough for the risk. Any of them needs Bash's OK first.

Outside posts (Bash decides, and each needs a contact log afterwards): a signature comment on xe 8678, xe 9168 or an i915 tracker after the timing data exists; a 385 test result and a 354 datapoint for NullMoth; the open reply to jwx29; a correction on mt7925-hackintosh-wifi issue 4.

EOF

1. Reconcile the N-287 27 s gap with ws-progress.txt and record the 2.0 s rendezvous arithmetic in the I-116 evidence README and the handoff (XNU mp.c). Documentation only. Confidence: High. Bash's OK: not needed.
2. Audit the shim stand-ins by reading source: in_atomic, irqs_disabled, rcu_preempt_depth, cancel_delayed_work_sync return values, irq_work under RCU, the IRQ handler's context, and the cache attribute and PAT of the CT, ADS and log pages (C9). Evidence: 4f2f26fb1e8a, 79e290d96786, 0d022baa047a. Confidence: Medium. Bash's OK: not needed.
3. Queue paired runs of the built-but-unbooted XeGfx 0.0.45 switches (gtawake=1, gtawake=2, irqoff_check=0) against a control, same load and window, including an I/O-heavy run like N-290. One run per arm cannot separate a rare event (xe 8760 used a single 20 minute arm), so plan repeats. Evidence: zep245, xe 8678. Confidence: Medium. Bash's OK: needed (installs a kext; boots follow the project rules).
4. Add TSC-delta timing around the doorbell write, the forcewake ack wait and the TLB-ack wait, plus a ring of near-miss late acks and passive per-CPU timestamps read at panic (not a heartbeat thread, which is a second waker) so the missing CPU of "23 of 24" can be named, logged to debug.xegfx_log. Evidence: 6d46d09a0d7d, LKML. Confidence: Medium. Bash's OK: needed (kext change).
5. Optionally a larger slto_us for one run, to learn whether the stall ends or never ends. Never use tlbto_us=0, which loses the panic string. Confidence: Low to Medium. Bash's OK: needed (boot-args).
6. Before any TLB-path test, study why Meteor Lake requires GuC TLB invalidation (2d6e2b10a773, af58ee227662); prefer throttling or batching frees over clearing the flag. Confidence: Medium. Bash's OK: needed for any boot test, not for reading.
7. Idle-state and microcode A/B (C-state limit); no BIOS with the pcode half exists, since S2CN26WW is the newest, and any BIOS setting change needs Bash's explicit OK. Evidence: 8fa1c7cd1fe9, Intel 834774. Confidence: Low. Bash's OK: needed (BIOS).
8. GuC 70.74.0 trial. Low expected value, since 70.72.1 matched 70.53.0 in xe 8678. Confidence: Low. Bash's OK: needed (firmware loaded by the kext).
9. A comment on xe 8678, xe 9168 or an i915 tracker describing our signature (23 of 24, NMI silence, a forcewake-hold A/B) would help upstream, but whether and when to post is Bash's decision; I suggest waiting for action 4.

1. Add cold/warm, microcode-before-and-after, GPU-mode and screen-photo columns to every boot attempt row; record the Ubuntu probe's microcode line. Tracker and process, no OK needed. Evidence: 2.5, 2.9. Confidence: High.
2. Correct the notes: StartupPowerEvents does not report reset causes, max_cstate=2 does not exclude C6, ARL037 is synthetic-only and Planned Fix on HX, and only two newer microcode revisions exist. Docs and handoff, no OK. Evidence: 2.1, 2.3, 2.4, 2.5. Confidence: High.
3. Run the I-118 arms A to D with the Ubuntu probe stick and a full power-off between sessions. Probe-stick procedure; needs Bash at the machine and his go for any macOS restart outside a staged attempt. Evidence: 2.6 and 2.9. Confidence: Medium.
4. Run the I-116 2 by 2 (waker, gtawake) only after a stock-limit LegionCpuPower session and the nvram_trace=0 run, with a stopping rule and a session budget, a fixed I/O load, through xe-guard. XeGfx 0.0.45 knobs exist; the xe-guard standing go covers self-judged runs, but confirm the batch with Bash. Evidence: 2.8. Confidence: Medium.
5. Try powermetrics for C-state residency; if empty, extend LegionCpuProbe with the C-state MSRs, SMI count (0x34) and MCA banks (0x401 on). Kext change, needs Bash's OK. Evidence: 2.3. Confidence: Medium.
6. Run a 2-hour Ubuntu probe with the disk loop and an iGPU workload as the platform-only control, grepping for Invalid mmio. Probe stick, no OK beyond Bash's presence. Evidence: 2.2 and 2.8. Confidence: Medium.
7. Raise slto_us for one stall run to see whether the stall is finite. Boot-arg in NVRAM, needs Bash's OK. Evidence: 2.1 and 2.8. Confidence: Low.
8. Optionally comment on i915 16052 with cold/warm and dGPU facts. Outside post: Bash decides, and the issue is slated to close on 2026-10-27. Evidence: 2.2. Confidence: Medium.
9. Do not chase BIOS flashes or microcode injection. None is available; any BIOS change needs Bash's OK. Evidence: 2.4. Confidence: High.

1. Run XeGfx with xegfx.nvram_trace=0 in the next xe-guard batch (XeGfx, xe-guard queue). Highest value per risk: one existing switch, never tested (xg_kext.cpp, DESIGN.md). Confidence Medium. Needs Bash's OK (it changes what a guarded boot runs).
2. Write the N-294 attribution note before booting (docs: handoff and the attempt README): base-change items (2.5.4, 2.5.5) listed apart from our commits, the two switches, a cold-cache warning (release, 370). Confidence High. No OK needed.
3. Port the ArrowWhatever unwire fix as our own commit after reading the patch against xg_vm.c (XeGfx shim, branch xe-2.6.2), logged as "race removed", not as an I-116 attempt (patch). Licence matches ours. Confidence Medium. Needs Bash's OK (kext change).
4. Test N-294 drag work with a heavily redrawing terminal, the two switches toggled (NvGfx plugin, my-settings block of nvrm610.conf), and record the result for 412. Confidence Medium. Needs Bash's OK for staging and the reboot.
5. Keep the existing gtawake=1|2 and irqoff_check=0 A/Bs, one variable per boot (xe-guard queue), and read any "TLB flush timeout" panic as CPU-side (mp.c). Confidence Medium. Needs Bash's OK.
6. Add the 615.71.10 and 615.78.08 diff finding, and one table of the 50, 100 and 115 W figures, to notes/power.md and the power evidence folder (compare, NVIDIA). Confidence High. No OK needed (docs; the PSREF line still has to be read by a PDF reader).
7. Outside posts are Bash's call: a 385 test result, a 354 datapoint, and the open jwx29 A/B reply would help others, but nothing is sent without his decision (385, 354). Confidence High that they are useful.

1. Correct the 25G330 wording in the tracker research rows (R073, R074), the handoff and the issue 4 follow-ups, and record the OTA provenance (25G241 plus Intel delta, verified by result SHA-1 and bill of materials, shortened identities only). Docs only, no OK needed. Evidence: AppleDB 25G332. Confidence: High.
2. Ask 25G332 reporters for ioreg -rc MtkWlanNative -l -w0 | grep -E "MtkNativeDeclined|MtkNativeLast", and whether LegionBtFix and MtkBt loaded, so the real refusal reason is on record. Read-only, on our own issue; Bash decides on any post elsewhere. Evidence: MtkNativeAbi.hpp. Confidence: High.
3. Review the three kcabi differences by hand: read the callers of _kern_netif_queue_rx_enqueue in MtkWlanNative against the 0x4d8 to 0x4e8 move and confirm no MtkWlanNative code uses the NAN interface classes. Analysis only, no OK needed. Evidence: kcabi. Confidence: Medium.
4. Check LegionBtFix's byte window and page hash against the 25G332 bluetoothd without touching system files. First explain why the live /usr/sbin/bluetoothd differs from the OTA pre.bom CRC32 (read-only), then apply the patch to the right base or ask a reporter for his file. The read-only part needs no OK; any LegionBtFix change touches a kext and needs Bash's OK. Evidence: LegionBtFix. Confidence: Medium.
5. Turn the OTA route into a small standard-library helper beside kcabi, named plainly, and add airportd and other changed user-space files to its BOM diff. Keep Apple binaries and long hashes out of git and the public repos. Tooling and docs only. Evidence: bxdiff50.go. Confidence: High.
6. Keep the Legion on 25G241 and ask Bash before any update. If he approves one: a cold power-off (the MT7925 warm-restart wedge, issue 1), the kcabi refresh, the gpu-guard and xe-guard flows, an expected LegionBtFix decline, and a restorable 25G241 EFI and volume. Needs Bash's explicit OK. Evidence: Apple macOS page. Confidence: High.
7. Decide whether to add 701.48~2 to the MtkWlanNative allow-list as an unverified build for 25G332 reporters. Touches a kext, so Bash must say yes; the Legion cannot test it without updating macOS (item 6), so only a reporter could. Evidence: 4.3 and 4.4. Confidence: Low.
8. Read-only BIOS and OpenCore survey: the VT-d and X2APIC rows in S2CN26WW and a MADT dump. The A/B of SetupVirtualMap on with ForceExitBootServices off on OCEFI (stick untouched) needs Bash's OK. Evidence: 1401 issue 58, ASUS FX608LP EFI. Confidence: Low.
9. Port Linux ideas after a diff read: ROC lifetime through the 4-way handshake, drv_pmctrl and fw_pmctrl return checks, a reset on WMT timeout in MtkBt, and a 20261016 firmware A/B with the old pair as rollback. Kext changes, so Bash's OK. Evidence: ac22c8c723c6, b3078bb2ee12. Confidence: Low.
10. Compare the LenovoLegionLinux 0x5508 fan table with the LegionFan curve (read-only), and publish a dated MT7925-on-macOS comparison or a 1401 note only if Bash wants them. Outside posting is Bash's decision. Evidence: LenovoLegionLinux. Confidence: Low.

Scope and framing. The brief was a technical research question with an implementation-planning purpose: what the public web, up to late October 2026, knows that helps the project. The inferred type is technical research plus claim verification, with the project's own tracker rows treated as claims to check and not as ground truth. It is not a high-stakes domain in the legal or medical sense, but changes to boot configuration can leave the machine unbootable, so every action lists whether it needs Bash's explicit approval.

Plan. Fifteen aspects were derived from the six questions in the brief, each with queries covering a primary source, a recent source, an adversarial angle, a practitioner angle and a failure angle where they applied: GuC CT stalls (1), MMIO and forcewake (2), TLB invalidation and the free worker (3), C-states, RC6, DC and PSR (4), platform errata, microcode and BIOS (5), Arrow Lake enablement, workarounds, firmware and Mesa (6), FreeBSD and OpenBSD ports (7), NVIDIA on macOS through NullMoth and forks (8), Blackwell laptop power (9), Intel Xe on macOS (10), macOS 26.7.2 (11), offline kernel collections (12), MT7925 on macOS (13), Legion Gen 10 and Arrow Lake Hackintosh reports (14) and early resets after ExitBootServices (15).

Execution. The skill's Workflow tool was not available in this session, so the same roster ran as parallel agent calls. Wave one was fifteen aspect agents, each writing a report of 30 to 44 KB with a per-claim tier, date, confidence and direct-versus-inference label. Wave two was four agents over the whole set: a source auditor (domain counts, regrade of tiers, citation loops, weak sources, recommended removals), a contradiction hunter that also re-verified load-bearing facts independently (and corrected several), a timeline agent and a practitioner-reality agent. Four theme drafters then wrote the main findings from the aspect reports and the wave-two files, a devil's advocate attacked the drafts, and the editor assembled the dossier and applied the gate.

Tools and reach. Reads used gh api for GitHub (read-only GET), the GitLab REST and GraphQL interfaces for freedesktop.org, plain HTTP with range requests for Apple's delta OTA listing, local reads of the project's own evidence and source, and web fetches. The shared web-search budget ran out part way through, after which only direct fetches were possible. The limits that follow from this are in the gaps section.

Tiers. S is a primary artifact (a commit, source code, a specification or a vendor document). A is maintainer or expert text with data. B is a user report, an issue thread or a self-reported project. C is press or a blog. The auditor regraded the agents' own labels, which were inflated: by the agents' labels about 75 percent of unique URLs were S or A, by the auditor's rule-based regrade about 50 percent. The sources table uses the regrade. Every claim in the evidence table carries High, Medium, Low, Unverified or Contradicted, with the date checked (2026-10-27).

Claim hygiene. A claim from one self-reported repository is Unverified until reproduced. A reading of a commit message is Medium unless the source code also shows it. Anything that rests on the panic text alone, with no register offset in the report, is inference and is labelled so. Where the verification pass disagreed with an aspect report, the verification wins and the text says so.

Privacy. The dossier names no serials, MAC addresses, keys or recovery data. Apple download paths that embed random identifiers are cited through the appledb entry that lists them. Long hashes are shortened to the form commit messages use. Nothing downloaded from Apple or third parties is stored in the repository or run; the reconstruction of the 26.7.2 collections happened in a scratch folder.

Quality gate (editor's scoring, 0 to 1).

Counts: 229 sources in the table, of which 108 are S or A tier by the auditor's and editor's regrade (an upper bound; the auditor's stricter reading of the whole corpus gives about 170 of 337 canonical URLs). The key-insight list has 14 entries and each theme adds five. Verdict: PASS for use as a planning document for this project, WARN on source diversity and on the limited reach of the search; it should not be read as a complete survey of non-English communities.

Tiers: S primary artifact (commit, source code, specification, vendor document), A expert or maintainer text with data, B user report, issue thread or self-reported project, C press or blog. The first part lists the sources the research reports used, with the auditor's regrade; the second part lists further links that the sections above cite directly, tiered by source type. "Used in" names the research reports (A1 to A15, one per aspect) or the dossier sections that cite the link. Dates checked: 2026-10-27 unless stated.

Counts: 229 sources listed. S-tier 88, A-tier 20, B-tier 116, C-tier 5. The tiers are the auditor's and editor's, and the audit found the agents' own labels inflated; the S and A count is therefore an upper bound.