watchthelight labs

Intel panel: NMIntelFB hangs the machine at start (write-combined map of the DSM framebuffer) #15

openarea:displaykind:bug
watchthelight 2026-10-21

NMIntelFB matched at boot passes BAR0 map, plane/timing reads, the frame counter, the boot-console check and IOFramebuffer::start, then the machine hangs in IODeviceMemory::withRange(0x70800000, 16 MB)->map(kIOMapWriteCombineCache) (NVRAM step breadcrumbs, two boots). 0.3 maps on demand only; first boot inconclusive. Parent: #12

watchthelight 2026-10-21

Review of the stage-8 hang (code reading plus Linux evidence):

  • The breadcrumb does not prove the hang is in our own map(): the window between step 8 and 9 also covers WindowServer opening the newly registered framebuffer and IOFramebuffer's console takeover. WindowServer was crash-looping every 10 s when the framebuffer appeared (~84 s after boot).
  • A WC mapping of the firmware framebuffer is not unsafe in itself: Linux simpledrm scanned out of 0x70800000-0x7179ffff (BOOTFB) for ~15 minutes on this machine before i915 loaded. Candidate on XNU: the video console maps the same pages uncached (VM_WIMG_IO) and keeps writing under -v, so a write-combined alias is an undefined memory-type alias.
  • IOFBDependentID/Index 4 set while no NVRM framebuffer exists (with -nvoff) leaves an IOFBController with no index 0; IOGraphics dereferences fFbs[0] in asyncWork. To be fixed in the next NMIntelFB build (set them only when NVRM is up, and before IOFramebuffer::start).
  • Also to change: release the BAR0 mapping right after the register reads; class name without "Intel" (CoreDisplay vendor sniff).
    NMIntelFB is parked while #14's simpler fix is tested: if Apple's IONDRV drives the panel, NMIntelFB is only needed for the NVIDIA copy path (#16).
watchthelight 2026-10-21

New suspect for the freeze: WhateverGreen's IOFramebuffer::initFB hook without gfxrst=4 (copies the boot console into the new framebuffer on first open; with NMIntelFB returning the stolen-memory console range, that is a second kernel mapping of the same DSM pages, and a panic with a broken console looks like a silent freeze). If N-201 works, the next NMIntelFB boot runs with gfxrst=4 and nmintelfbstop=7 as the control.

watchthelight 2026-10-21

N-201 shows IOFramebuffer's own write-combined mapping of the 0x70800000 range works (WindowServer's software compositor draws through it). So a WC map of DSM is not the hang by itself; WhateverGreen's initFB console copy (now off with gfxrst=4) remains the main suspect for the NMIntelFB freezes. NMIntelFB is no longer needed for an unaccelerated panel; it stays parked.

Reply on GitHub