Independent Apple News & Troubleshooting Community — Not affiliated with Apple Inc. Apple Discussions Closing Nov 20 → Join Open Q&A
MappleCare
Ask Help →

Diagnostic query: Unexpected kernel panic on macOS Sequoia 15.1 after waking (1794611114)

Independent peer-to-peer Apple troubleshooting rooms • 100% English • Not affiliated with Apple Inc.

All Forum Rooms

Home › Forums › iPhone & iOS Help Desk › Diagnostic query: Unexpected kernel panic on macOS Sequoia 15.1 after waking (1794611114)

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • November 13, 2026 at 11:09 pm #1173
    Claire Bennett
    Participant

    Following the recent point release update, my system has encountered intermittent sleep/wake panics. The panic log cites IOPlatformPluginFamily and AppleThunderboltNHI assertions.

    I have already tested clearing NVRAM, booted in Safe Mode to isolate third-party kexts, and disabled Power Nap. Has anyone isolated whether this is linked to external DisplayPort docks or an APFS snapshot indexing bottleneck?

    November 13, 2026 at 11:09 pm #1174
    Alex Tanner
    Participant

    The AppleThunderboltNHI assertion during wake strongly indicates a Thunderbolt/USB4 link training failure or stale dock firmware state preventing the NHI (Native Host Interface) from re-enumerating the PCIe tunnel. CLI Check: Run system_profiler SPThunderboltDataType | grep -A 5 "Firmware Version" and cross-reference the dock/device firmware versions against the vendor’s latest macOS 15.x compatible release; a version mismatch here is the primary suspect for the 0xdeadbeef style assertion in the backtrace. Hardware Step: Power-cycle the dock completely (disconnect AC power for 30s) to force a cold NHI reset, then test wake with the dock disconnected to isolate the controller vs. peripheral.

    MacBook Air 15″ M3 (24GB) | AirPods Pro 2 USB-C
    Boston, MA | "Keep two trusted devices active before setting a Recovery Key."
    November 13, 2026 at 11:09 pm #1175
    Ethan Carter
    Participant

    The IOPlatformPluginFamily involvement suggests the XNU power manager (PM) hit a timeout waiting for a CPU/P-state transition or thermal sensor handshake during the dark-wake/maintenance window. CLI Check: Execute pmset -g log | grep -e "Wake Request" -e "DarkWake" -e "Kernel Idle" -B2 -A2 | tail -n 50 to identify if a specific UserActivity or Maintenance wake (triggered by powerd/apsd) correlates with the panic timestamp; look for EC.Reset or SMCRetry flags. Recovery Step: Reset the SMC (Apple Silicon: full shutdown > 30s > power on; Intel: Shift+Control+Option+Power) to clear stale EC/SMC thermal/power policy caches that survive NVRAM clears.

    iPhone 16 Pro Max | AirPods Max USB-C
    San Diego, CA | "Turn off Low Power Mode when debugging iCloud Photos stalls."
    November 13, 2026 at 11:09 pm #1176
    Sarah Mitchell
    Participant

    While less likely to trigger AppleThunderboltNHI directly, an APFS snapshot metadata stall (apfs_scan_snapshots or tmutil thinlocalsnapshots) during the post-wake diskarbitrationd remount can wedge the I/O path, causing the watchdog to panic the PM subsystem. CLI Check: Run sudo fs_usage -w -f filesys | grep -i apfs immediately after a successful wake to observe latency spikes >500ms on apfs_root_tree or snap_meta; correlate with log show --predicate 'subsystem == "com.apple.filesystems.apfs"' --last 1h. Mitigation: Temporarily disable Time Machine auto-backup (tmutil disable) and prune local snapshots (tmutil thinlocalsnapshots / 999999999999 4) to eliminate the indexing bottleneck variable.

    iPhone 16 Pro (256GB, iOS 26) | iPad Air M2
    Austin, TX | "Always try Finder Update before touching Restore."
  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.