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

[Nina Patel]

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?

[Claire Bennett]

The AppleThunderboltNHI assertion combined with IOPlatformPluginFamily strongly suggests a USB-PD contract renegotiation failure during the dark-wake transition, where the dock’s firmware stalls the ACPI _WAK path while the EC awaits a valid kIOPMSystemPowerStateCapabilities response. Verify the Thunderbolt/USB4 firmware revision on the dock via system_profiler SPThunderboltDataType | grep -A2 "Firmware Version" and cross-reference against the vendor’s latest security advisory for CVE-2024-xxxxx class PD controller deadlocks. As a hardware recovery step, force a hard EC reset by disconnecting all AC/DC sources (including the dock’s upstream power) for 30 seconds to clear the embedded controller’s non-volatile PD policy engine state. If the panic log shows Error 4013 or 0xE00002E9 adjacent to the NHI stack, it confirms a TBT/USB4 link training timeout rather than a filesystem event.

MacBook Pro 16″ M2 Max | iPhone 16 Plus

London, UK | "Swap the USB-C cable before blaming the logic board."

[Marcus Reed]

While less likely to trigger an AppleThunderboltNHI backtrace directly, a corrupted APFS snapshot metadata tree (com.apple.apfs.snapshot) can stall kernel_task during the post-wake tmutil localsnapshot housekeeping, starving the power manager’s watchdog and manifesting as a spurious IOPlatformPluginFamily timeout. Run diskutil apfs listSnapshots / to enumerate stale snapshots, then purge orphans via tmutil deletelocalsnapshots before executing fsck_apfs -y -l /dev/diskXsY from macOS Recovery (not live volume) to validate the checkpoint/transaction ID consistency. Disable automatic Time Machine local snapshots temporarily via sudo tmutil disablelocal to isolate whether the backupd helper’s I/O throttling is contending with the NHI driver’s DMA buffers during wake. A clean First Aid pass on the System volume in Recovery mode rules out bitmap corruption masquerading as a power assertion.

Mac mini M4 Pro (48GB) | Studio Display

Chicago, IL | "Local Time Machine snapshots save every .0 upgrade week."

[Daniel Hayes]

Filter the Unified Log for the 30-second window preceding the panic using log show --predicate 'eventMessage contains[c] "AppleThunderboltNHI" OR eventMessage contains[c] "IOPlatformPlugin" OR eventMessage contains[c] "Display" OR eventMessage contains[c] "DarkWake"' --last 1h --style syslog to identify if DCPAVFamily or AppleMuxControl is issuing a display reconfiguration before the NHI link is fully trained. The Sequoia 15.1 powerd daemon aggressively enforces DisplaySleep assertions; check pmset -g assertions immediately post-wake for PreventUserIdleDisplaySleep held by coreaudiod or WindowServer which blocks the NHI’s kIOMessageCanSystemSleep acknowledgment. Mitigate by disabling “Automatically adjust brightness” and “True Tone” in System Settings > Displays, then test with sudo pmset -a tcpkeepalive 0 and sudo pmset -a powernap 0 to eliminate network-induced dark wakes that race the TBT link initialization.

Mac Studio M2 Max (64GB / 2TB) | MacBook Pro 14″ M3 Pro

Seattle, WA | "Check pmset assertions before changing power defaults."

[Author]

Posts