MacBook Pro (16" M1 Pro) crashes and restarts with lid closed

[maclaw21]

MacBook Pro (16" M1 Pro) sometimes restarts while lid is closed and machine is not in use.



Here is the latest incident report generated by macOS:

panic(cpu 0 caller 0xfffffe00471edccc): "ApplePMGR: void ApplePMGR::_waitForPMPReadyActionGatedv2(UInt32):9826 " "Die 0, Deadline: 0x20ab68f6119, AbsTime: 0x20ab6b0802d PMP Failed to Come Online within 30 seconds" @ApplePMGR.cpp:9826Debugger message: panicMemory ID: 0x1OS release type: UserOS version: 25F71Kernel version: Darwin Kernel Version 25.5.0: Mon Apr 27 20:38:56 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6000Fileset Kernelcache UUID: F25DF7DC8F67305D467D443137781AC1Kernel UUID: 95150041-8FB6-34BD-B7CF-223439CC3824Boot session UUID: 72DE7326-27DC-4390-A195-C8A8FBFF352FiBoot version: mBoot-18000.120.36iBoot Stage 2 version: mBoot-18000.120.36secure boot?: YESroots installed: 0Paniclog version: 15Debug Header address: 0xfffffe0024aad000Debug Header entry count: 3TXM load address: 0xfffffe0034a08000TXM UUID: F0C1A57F-CE44-3DF4-9E86-0CFF02D7C00DDebug Header kernelcache load address: 0xfffffe0044a08000Debug Header kernelcache UUID: F25DF7DC-8F67-305D-467D-443137781AC1SPTM load address: 0xfffffe0024a08000SPTM UUID: D249E718-9C0B-36F5-9F6B-24D58BED4606KernelCache slide: 0x000000003da04000KernelCache base: 0xfffffe0044a08000Kernel slide: 0x000000003da0c000Kernel text base: 0xfffffe0044a10000Kernel text exec slide: 0x00000000420d8000Kernel text exec base: 0xfffffe00490dc000mach_absolute_time: 0x20ab6de0fd5Epoch Time: sec usec Boot : 0x6a0b94f3 0x0006f9b4 Sleep : 0x6a1ac128 0x000585fa Wake : 0x00000000 0x00000000 Calendar: 0x6a1ac146 0x000920c0Zone info: Zone map: 0xfffffe1006000000 - 0xfffffe3606000000 . VM : 0xfffffe1006000000 - 0xfffffe15d2000000 . RO : 0xfffffe15d2000000 - 0xfffffe186c000000 . GEN0 : 0xfffffe186c000000 - 0xfffffe1e38000000 . GEN1 : 0xfffffe1e38000000 - 0xfffffe2404000000 . GEN2 : 0xfffffe2404000000 - 0xfffffe29d0000000 . GEN3 : 0xfffffe29d0000000 - 0xfffffe2f9c000000 . DATA : 0xfffffe2f9c000000 - 0xfffffe3606000000 Metadata: 0xfffffe4836010000 - 0xfffffe483f810000 Bitmaps : 0xfffffe483f810000 - 0xfffffe4842504000 Extra : 0 - 0TPIDRx_ELy = {1: 0xfffffe186e35f410 0: 0x0001000000000000 0ro: 0x0000000000000000 }CORE 0 is the one that panicked. Check the full backtrace for details.CORE 1: PC=0xfffffe00491751b8, LR=0xfffffe00491751b8, FP=0xfffffe5df4a4bee0CORE 2: PC=0xfffffe00491751b8, LR=0xfffffe00491751b8, FP=0xfffffeccdea1bee0CORE 3: PC=0xfffffe00491751b8, LR=0xfffffe00491751b8, FP=0xfffffeccde98bee0CORE 4: PC=0xfffffe00491751b8, LR=0xfffffe00491751b8, FP=0xfffffeccdea7bee0CORE 5: PC=0xfffffe00491751b8, LR=0xfffffe00491751b8, FP=0xfffffeccdec5bee0CORE 6: PC=0xfffffe00491751b8, LR=0xfffffe00491751b8, FP=0xfffffeccde1ebee0CORE 7: PC=0xfffffe00491751b8, LR=0xfffffe00491751b8, FP=0xfffffeccdf7fbee0CORE 8: PC=0xfffffe00491751b8, LR=0xfffffe00491751b8, FP=0xfffffe5ceff1bee0CORE 9: PC=0xfffffe00492bbf98, LR=0xfffffe00492bbf94, FP=0xfffffeccdf4abe40Compressor Info: 14% of compressed pages limit (OK) and 13% of segments limit (OK) with 0 swapfiles and OK swap spacePanicked task 0xfffffe29d201c0e0: 0 pages, 618 threads: pid 0: kernel_taskPanicked thread: 0xfffffe186e35f410, backtrace: 0xfffffe6f5fd928c0, tid: 1819 lr: 0xfffffe004913457c fp: 0xfffffe6f5fd92960 lr: 0xfffffe00492b814c fp: 0xfffffe6f5fd929d0 lr: 0xfffffe00492b60c4 fp: 0xfffffe6f5fd92a90 lr: 0xfffffe00490e1c40 fp: 0xfffffe6f5fd92aa0 lr: 0xfffffe0049134888 fp: 0xfffffe6f5fd92fc0 lr: 0xfffffe0049a385e8 fp: 0xfffffe6f5fd92fe0 lr: 0xfffffe00471edccc fp: 0xfffffe6f5fd93080 lr: 0xfffffe004992b4e4 fp: 0xfffffe6f5fd930f0 lr: 0xfffffe00471edacc fp: 0xfffffe6f5fd93110 lr: 0xfffffe00471f26f0 fp: 0xfffffe6f5fd93260 lr: 0xfffffe004992b4e4 fp: 0xfffffe6f5fd932d0 lr: 0xfffffe00471f253c fp: 0xfffffe6f5fd93310 lr: 0xfffffe0047204e4c fp: 0xfffffe6f5fd93360 lr: 0xfffffe004750ec90 fp: 0xfffffe6f5fd933b0 lr: 0xfffffe004750e79c fp: 0xfffffe6f5fd93400 lr: 0xfffffe004750e544 fp: 0xfffffe6f5fd93460 lr: 0xfffffe0048128eac fp: 0xfffffe6f5fd934e0 lr: 0xfffffe0048130574 fp: 0xfffffe6f5fd93570 lr: 0xfffffe00498da398 fp: 0xfffffe6f5fd935c0 lr: 0xfffffe0046d08150 fp: 0xfffffe6f5fd93640 lr: 0xfffffe0046d0e204 fp: 0xfffffe6f5fd93740 lr: 0xfffffe0046d0f0e4 fp: 0xfffffe6f5fd93880 lr: 0xfffffe0046cbdff8 fp: 0xfffffe6f5fd93940 lr: 0xfffffe0046cba540 fp: 0xfffffe6f5fd93a10 lr: 0xfffffe0046cd14e0 fp: 0xfffffe6f5fd93ac0 lr: 0xfffffe0046ce1694 fp: 0xfffffe6f5fd93cb0 lr: 0xfffffe0046ce2e3c fp: 0xfffffe6f5fd93cd0 lr: 0xfffffe004992b4e4 fp: 0xfffffe6f5fd93d40 lr: 0xfffffe0046cd6df8 fp: 0xfffffe6f5fd93d90 lr: 0xfffffe0046cd6d10 fp: 0xfffffe6f5fd93e10 lr: 0xfffffe0046cc38dc fp: 0xfffffe6f5fd93eb0 lr: 0xfffffe004992b4e4 fp: 0xfffffe6f5fd93f20 lr: 0xfffffe00490e2904 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.IODARTFamily(1.0)[DB9C5931-E7EC-3601-A7FF-E1F3EFBD5BCC]@0xfffffe0048123070->0xfffffe00481371e7 dependency: com.apple.driver.AppleARMPlatform(1.0.2)[85AF824B-70B0-3C11-BE82-F90BD4A57DC8]@0xfffffe004648aa10->0xfffffe00464dddd3 com.apple.driver.AppleH11ANEInterface(9.511.3)[38B577B8-4E93-35FB-9420-6DD2FA2ED732]@0xfffffe0046c7ef90->0xfffffe0046d70aef dependency: com.apple.driver.AppleARMPlatform(1.0.2)[85AF824B-70B0-3C11-BE82-F90BD4A57DC8]@0xfffffe004648aa10->0xfffffe00464dddd3 dependency: com.apple.driver.IODARTFamily(1)[DB9C5931-E7EC-3601-A7FF-E1F3EFBD5BCC]@0xfffffe0048123070->0xfffffe00481371e7 dependency: com.apple.driver.RTBuddy(1.0.0)[4FEFDDA4-3743-34AC-869D-EAE695595A4C]@0xfffffe0048b63bd0->0xfffffe0048ba878b dependency: com.apple.iokit.IOReportFamily(47)[B53BE23F-34ED-35B3-9E6C-12B7BECC2267]@0xfffffe0048496e20->0xfffffe004849996b dependency: com.apple.iokit.IOSurface(393.5.7)[FF2F8375-AC77-319C-B2EB-D557AFA9951F]@0xfffffe004856dba0->0xfffffe004859d983 dependency: com.apple.kec.corecrypto(26.0)[E32A8F10-1A9A-3F79-B28F-FCE426314EB6]@0xfffffe0048ed9140->0xfffffe0048f435eb com.apple.driver.AppleT6000DART(1.0)[08B2D00F-2385-3846-9BFC-16E0D034D95B]@0xfffffe004750b530->0xfffffe004751298f dependency: com.apple.driver.AppleARMPlatform(1.0.2)[85AF824B-70B0-3C11-BE82-F90BD4A57DC8]@0xfffffe004648aa10->0xfffffe00464dddd3 dependency: com.apple.driver.IODARTFamily(1)[DB9C5931-E7EC-3601-A7FF-E1F3EFBD5BCC]@0xfffffe0048123070->0xfffffe00481371e7 com.apple.driver.ApplePMGR(1.0)[42F1AD20-5320-3803-8A70-05104BD5FBA7]@0xfffffe00471be8b0->0xfffffe004721f017 dependency: com.apple.driver.AppleARMPlatform(1.0.2)[85AF824B-70B0-3C11-BE82-F90BD4A57DC8]@0xfffffe004648aa10->0xfffffe00464dddd3 dependency: com.apple.iokit.IOReportFamily(47)[B53BE23F-34ED-35B3-9E6C-12B7BECC2267]@0xfffffe0048496e20->0xfffffe004849996blast started kext at 2522370632: com.apple.filesystems.webdav 3.0.1 (addr 0xfffffe00456d46d0, size 3632)loaded kexts: (skipped, see boot kernelcache)** Stackshot Succeeded ** Bytes Traced 768330 (Uncompressed 1795968) **

I do not have any peripherals plugged into the unit. The only thing plugged in is the MagSafe charging cable.


MacOS is 26.5

 

[VMSwizard411]

I've had the exact same kernel panic since I upgraded from 26.3.1 to 26.4, and then continuing thru the upgrades to 26.4.1 and now 26.5.

As long as I don't close the lid, no overnight panic. Close it and it panics. Happens to me whether the charging cable is attached or not (although sometimes having it not connected will still panic).

Since my usual account is not an administrator, I just use the text below my icon on the login screen as my indicator of the panic: if it says I must enter my password to enable Touch ID then I know it did.

 

[benholt]

Saw the same PMP-failed-to-come-online flavor on my M3 Max 16" after the 26.4 update. Two changes that stopped it for me: turned off Wake for network access (Battery > Options) and unplugged my CalDigit TS4 overnight as a sanity check. Going on three weeks panic-free. The bug itself looks like a sleep/wake race in ApplePMGR but peripherals were the trigger in my case, so worth checking if anything's on the TB ports overnight.

 

[daveo31]

I have a very similar issue:

Repeated forced restarts on lid open: M1 Max MacBook Pro,​

I am looking for guidance on an intermittent forced-restart problem affecting a 2021 14-inch MacBook Pro.

System​

• MacBook Pro (MacBookPro18,4)
• Apple M1 Max, 32 GB RAM
• macOS 26.5.2 (build 25F84)
• The fault has also occurred on earlier macOS point releases.

Symptoms​

The Mac intermittently restarts when I open the lid. It may behave normally for days or weeks between incidents, which has made the problem difficult to reproduce during service. Sometimes the display briefly flashes on and off before the machine boots again.

The two most recent incidents occurred on consecutive days, 19 and 20 July 2026. They produced matching ResetCounter reports:

<span>Reset count: 0<br>Boot failure count: 1<br>Boot faults: btn_rst,finger_reset force_off<br>Boot stage: 0x40<br>Boot app: 0<br>socId: 6001<br>socRevision: 11</span>
The unified log from each boot contains:

<span>(AppleSPMIPMU) pmu fault log: btn_rst,finger_reset force_off<br>(AppleSPMIPMU) pmu fault log: btn_rst,finger_reset force_off sgpio,sgpio_shutdown<br>PMRD: Clamshell opened<br>(AppleMesaSEPDriver) ERROR: sensorStateHandler ... err ... 0xffffffffe00002d8</span>
The latest boot also logged AppleBiometricSensor startup/interrupt errors with <span>0xffffffffe00002c7</span>.

DumpPanic reported:

<span>bootFailCount: 1<br>boot stage: 0x40<br>boot faults: ("btn_rst,finger_reset", "force_off")<br>universal boot faults: ("btn_rst", "force_off")<br>3145728 bytes ... did not contain any paniclog data (buffer was all zeros)<br>No paniclog data found in local device</span>
There is no conventional kernel panic report or recorded sleep/wake failure for these incidents. The same ResetCounter signature has appeared repeatedly on earlier restart dates, including incidents in May, June, and early July.

Repair history​

Apple has already replaced the logic board. The Touch ID/power-button assembly was replaced during that repair and was later replaced again separately. Apple diagnostics have been run more than once without finding another fault, but the same intermittent lid-open restart has continued.

The fault existed at least once before the repair work, so I cannot confidently say the repair caused it. However, the repeated <span>finger_reset</span> signature has continued despite replacement of both the logic board and Touch ID module.

Questions​

1. What does <span>btn_rst,finger_reset force_off</span> indicate on an Apple-silicon Mac?
2. Does this combination, especially with <span>sgpio_shutdown</span>, the adjacent clamshell-open event, and Mesa/biometric errors, suggest the Touch ID/power-button cable or connector, top case, lid/wake circuitry, PMU, or SEP path?
3. Can ordinary third-party software plausibly generate this exact PMU reset signature without leaving a panic log?
4. Is there a specific Apple diagnostic, component-level test, or wording I should ask an Apple Store or authorised service provider to use?
5. Has anyone seen this exact signature on MacBookPro18,4 hardware and found a lasting repair?

I have the complete ResetCounter files and a short boot-log capture for each incident, but I have omitted serial numbers, UUIDs, user information, network details, and incident identifiers here.

 

[benholt]

daveo31 — worth separating those. The panic in this thread (ApplePMGR PMP Failed to Come Online) is a wake-from-sleep race in the power manager that fires on lid-close and shows up in the panic log. Yours reads btn_rst, finger_reset force_off — that's the PMU firmware refusing a warm boot when the lid Hall sensor triggers on open, so the SoC has to cold-boot via the reset controller. Different sleep-path failures with different fixes.

I have my own thread on the PMU one — short version: TS4/CalDigit-style docks can trip finger_reset if they renegotiate USB power delivery during the S4→S3 transition, and DFU restore via Apple Configurator 2 clears any latched PMU state that survives NVRAM reset. Worth checking what's attached at the moment of lid-open.