Import FreeBSD LinuxKPI fixes for Meteor Lake and Arc (drm-kmod #315, #418, #468) #4

Upstream scout, 2026-10-22, two LinuxKPI lessons from the same stack on other machines:

• Lost wake-up. VedCloud's Meteor Lake port saw false GuC TLB-invalidation timeouts; the cause was their LinuxKPI woken callback not keeping TASK_WAKING under the sleep-channel lock. Worth checking our wait/wake path for the same window before blaming GuC. README, implementation section
• Pageable GEM backing. FreeBSD drm-kmod #527: an i915 GPU hang on drm-612-kmod 6.12.110 (the base we build on) when shmem backing pages got swapped out; turning swap off avoids it. On XNU the GEM backing should stay wired.

Their i915/DRM patches are GPL-2.0 and LinuxKPI ones BSD-2 (per their LICENSE), so the fixes can be compared directly. Write-up: https://github.com/watchthelight-labs/research/blob/main/scout/xe/2026-10-22.md

One fix in, credited to VedCloud: FreeBSD's woken_wake_function sets WQ_FLAG_WOKEN but never TASK_WAKING. A waiter that checks its condition and then sleeps through schedule_timeout() only skips the sleep when it sees TASK_WAKING under the channel lock. So a wake that lands between the check and the sleep is lost, and the waiter sleeps until timeout. On Meteor Lake that showed up as "GuC TLB invalidation response timeout" followed by a GPU hang.

VedCloud found it (ROADMAP Phase 4, NullMoth/gpu-port/xkpi/override/src/linux_schedule.c). Our FreeBSD tree (d2145e9) still has the bug, so the NvGfx overlay now carries FreeBSD's file with that one change: watchthelight-labs/NvGfx@0c84c33 (in the 0.0.9 build, not yet run on hardware).

Already in our tree, nothing to do: the signal_irq_work use-after-free (drm-kmod #489, FreeBSD 0d022baa047a, irq_work under RCU).
Still to check by code rather than hash: FreeBSD 79e290d967 (cancel_delayed_work_sync return value) and 2ff9182d89 (delayed-work cancel accounting).

Two things from this week's scan.

lutzbichler/drm-kmod pr/7.3 has a few Intel fixes worth checking against our import: is_arrowlake_s_by_host_bridge() always returned false (lutzbichler/drm-kmod@ade98e619a), DMC load-address and payload checks, and an RPS interrupt unmask race. No LinuxKPI changes in it.

zep245/IrisXe-macos-driver runs drm-kmod i915 and LinuxKPI inside the macOS kernel on Tiger Lake, and its design notes list the panics it hit: the thread_call group thread limit, preemption_level -1 from cond_resched inside ggtt_pin and shmem_get_pages, a TLB flush timeout, and a machine check at the stolen memory base. Useful to compare against I-116 (desktop died under heavy I/O). PolyForm Noncommercial, so ideas only.

Write-up: https://github.com/watchthelight-labs/research/blob/main/scout/xe/2026-10-27.md