Environment:
Device: MacBook Pro (Mac16,7) Chip: M4 Pro (SoC ID 6040, Revision 11) OS: macOS 15.2 (24C101) Kernel: Darwin Kernel Version 24.2.0; root:xnu-11215.61.5~2/RELEASE_ARM64_T6041 Summary:
I am developing a Windows emulator on the MacBook Pro M4 Pro platform. During testing with certain applications, the system frequently triggers an instantaneous reboot. This issue appears to be highly specific to the M4 Pro hardware and current OS version.
Observation & Diagnostic Challenges:
Upon reboot, the system generates a bug_type 210 (SoC Watchdog Reset) report. The panic string indicates: "Unexpected SoC (system) watchdog reset occurred after panic diagnostics were completed".
The primary difficulty in debugging is that the hardware reset happens so rapidly that the kernel fails to capture a stackshot or any detailed panic trace. We have practically no actionable information from the standard diagnostic reports.
However, we did find the following recurring entries in the system log prior to the resets:
Ignored NI0 NI0 niGeneral 1 NO_ACCESS error (0x00000010) cmd/st:0x14(ncrdincr)... srcchildid/srcparentid:0x8ea/0x1d
Comparison & Testing:
We have performed extensive cross-version and cross-device testing to isolate the cause:
M1/M2 Series: Identical tests on M1 and M2 devices running macOS 15 do not trigger this issue. The applications run stably. OS Versions: Interestingly, this issue seems significantly harder to reproduce on newer system builds (e.g., version 26 series), suggesting it might be a regression or a specific incompatibility in the current macOS 15.2 environment for M4 Pro. Request for Assistance:
Since we cannot collect stack traces through conventional means, we are seeking your expertise:
Known Issues: Has Apple received similar reports from other developers working on low-level emulation or virtualization on M4 Pro? Is this a known issue in macOS 15.2 / build 24C101? Debugging Guidance: Given that the system reboots without leaving a stackshot, what are the recommended methods to capture more granular data? Are there specific boot-args or instrumentation tools that can help log the state of the SoC fabric (NI0) before the watchdog kicks in? Architectural Insights: Based on the NI0 NO_ACCESS error and srcchildid: 0x8ea, could you suggest which subsystem or memory operation we should investigate further?