Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

daveo31

macrumors newbie
Original poster
Hi all, can anyone help with this. Apple has done two repairs and I still get the fault. I'm at my wit's end and can't afford to buy a new Mac :-(
Thanks,
Dave

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.
 
I think you’ve done an excellent job documenting this, and based on what you’ve posted, I’d be looking much more toward a low-level hardware or firmware issue than a software one.

The btn_rst,finger_reset force_off signature isn’t what I’d expect from an ordinary macOS or third-party software problem—it indicates that the Power Management Unit (PMU) believes the Mac experienced a forced shutdown involving the power button/Touch ID reset path rather than a kernel panic, which is supported by the complete absence of any panic log. The PMU is controlling and coordinating many low-level hardware power functions. It’s not just about battery charging—it plays a central role in how the Mac powers on, sleeps, wakes, resets, and shuts down.

The fact that the log then shows PMRD: Clamshell opened immediately before the restart sequence is important imho. I am assuming the restarts only happen when the lid is opened or when waking from sleep; if that’s true, it strongly suggests the failure is occurring during the wake sequence itself rather than during normal operation.

The accompanying AppleMesaSEPDriver and AppleBiometricSensor errors are also important. “Mesa” is Apple’s internal name for the Touch ID subsystem, and it communicates through the Secure Enclave Processor (SEP), so those errors are at least consistent with that portion of the hardware failing to initialize correctly after the reset. However, I’d be cautious about concluding they’re the root cause—they could just as easily be secondary effects of the abrupt reset.

What really makes this puzzling is that Apple has already replaced both the logic board and the Touch ID/power-button assembly, yet the identical finger_reset signature continues. That makes me wonder whether the issue could involve another part of the wake path that wasn’t replaced, such as a flex cable, connector, top-case circuitry, hall-effect sensor (what determines whether the lid is open/closed), or another component associated with lid-open detection or wake.

If I were taking it back to Apple, I’d ask for an engineering escalation rather than another standard repair, specifically pointing out that every occurrence produces the same PMU boot faults (btn_rst,finger_reset force_off) with no kernel panic and asking whether another component in the top case or wake circuitry could be intermittently initiating the reset path. I think you’ve collected exactly the sort of evidence that gives Apple engineering something meaningful to investigate. This is NOT a software problem imho!
 
  • Like
Reactions: ocdeal
@FreakinEurekan I’m not convinced this is a kernel panic. The diagnostic information @daveo31 posted doesn’t include a panic report, and DumpPanic specifically says the panic buffer is empty (“No paniclog data found”). Instead, the consistent evidence is the PMU boot-fault signature btn_rst,finger_reset force_off, which suggests the restart is being initiated below the macOS kernel rather than the kernel crashing. While it’s impossible to completely rule out an early panic that failed to be recorded, the information posted doesn’t support calling this a conventional kernel panic.
 
Thank you so much for the quick replies!! This is extremely helpful and broadly matches my understanding.

To clarify the timing, the restarts occur as I open the lid: the display may flash briefly, go off, and then the Mac boots. The <span>Clamshell opened</span> and Mesa/biometric messages are captured during the resulting boot, so I agree they may be consequences rather than proof of the initiating fault.

Regarding a kernel panic, I cannot completely exclude an extremely early panic that failed to record. However, both recent incidents produced a ResetCounter report with <span>btn_rst,finger_reset force_off</span>, while DumpPanic successfully read the 3 MB panic area and reported that it was entirely zeroed with “No paniclog data found.” There is also no separate panic report. That is why I’m hesitant to classify these as conventional kernel panics.

Given that the logic board and Touch ID/power-button module have already been replaced, an un-replaced cable, connector, top-case component or lid/wake sensor seems worth investigating. I’ll ask Apple specifically for an engineering escalation focused on the complete lid-wake and power-button/Touch ID reset path. Nothing external was connected during either recent incident: no USB or Thunderbolt devices, dock, hub, or external display. Only magsafe charger connected. May have to escalate with Apple.
 
This could come down to a single defective flex cable. Such damage is impossible to spot with the naked eye and the store employees aren't trained or given the equipment to spot or repair that or board component level issues leaving them with only one option: Swap a component and hope it's fixed, rinse repeat.

If they don't even know what exactly is wrong then how are you supposed to be able to trust them that the next repair will actually fix the issue? My main concern would actually be that your warranty expires on this older device before it's fixed. Apple themselves have a history of selling faulty Macs and not actually repairing them properly until the warranty expires at which point you're stuck with a defective device.

This has happened with some MacBook Pro series since the 2007 series where the logic board contained a faulty graphics chip that would sooner or later lead to a machine that could no longer boot. Some customers had 3 or 4 repairs and still had their Mac brick itself when the warranty eventually expired and the issue returned. The reason was that Apple didn't actually repair the fault on the logic board and instead merely swapped out the board with another one that was new but contained the flawed graphics as well.

Unless they swap out every part that's still original possibly even including the display assembly unit there is no guarantee that this will be fixed after the next repair. And if they were willing to swap everything out over the course of multiple repairs it's cheaper to give you a used/renewed replacement than it is to have a tech spend all the hours taking apart the Mac again and again.

Let them send the Mac to Cupertino and let engineering keep it. I would also look into lemon laws in your state and see if despite the age of the device there isn't some limitations on how often repairs for the exact same issue can be attempted before you can ask for an expedited fix and device swap.

I would explain to Apple how the lid might be opened and closed more than a dozen times a day whenever you leave the desk for a break or whenever you bring it with you to a meeting room and that you are now worried every time you close the lid that the Mac might crash and you lose unsaved data. How are you supposed to trust it and get work done? I'd really try to escalate this issue, Apple already had their chance to fix a botched repair, fool me once fool me twice...
 
Last edited:
Hi

Normally, your device should be replaced now, since three repair attempts have already taken place.
 
the btn_rst / finger_reset pattern with no panic log is telling — that's the PMU forcing a state change below the kernel, so a plain macOS reinstall genuinely won't touch it. two things worth trying before the next repair, both cheap:

first, a full DFU restore with Apple Configurator 2 from a second Mac. that reflashes the low-level firmware (SEP, PMU firmware, EFI), which a normal erase-and-install skips entirely. if the PMU state itself is corrupted, this is the one thing that can clear it. it's the same process Apple internal tools use, just user-accessible.

second — check for anything magnetic near the palm rest or under the base. on the M1 lineup lid state is detected with a Hall sensor in the display bezel/upper case. magnetic laptop stands, magnetic desk mats, even some phone MagSafe pucks stashed nearby can trigger transient "lid closed" events that read as force_off in the reset log. if you use any, try a week without them and see if the cadence changes.

if it's a hardware Hall sensor fault, the fix is usually a display/top-case assembly replacement — worth naming that signature to the tech at the next Genius Bar visit so they don't just swap the logic board again.
 
  • Like
Reactions: gymrat2k
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.