I’m trying to determine whether this is a known macOS/firmware issue, a hardware issue, or something else in the Apple-silicon sleep/power-management path.
Hardware / software:
MacBook Pro 14-inch (Nov 2023), M3 Pro
Model identifier: Mac15,6
11-core CPU, 14-core GPU, 18 GB RAM
macOS Tahoe 26.6.2 (25G83)
SoC T6030, revision 11
iBoot / firmware: mBoot-18000.161.10
Symptom:
The Mac intermittently performs a full reset/reboot while the lid is closed and it should be asleep. I usually discover this when I open the lid and find that the machine has rebooted rather than waking normally.
A particularly disruptive aspect is that this happens when I transport the Mac while the lid is closed. If I put the sleeping MacBook in a backpack and carry it, or even simply carry it in my hands with the lid closed, I can later find that it has reset (the startup sound plays) and booted to the startup disk selection / startup options screen instead of remaining asleep.
This behavior makes normal closed-lid transport unreliable. The correlation with movement while the lid is closed is one of the reasons I initially suspected something involving the lid sensor, sleep-state handling, or another hardware/power-management component. However, I can also reproduce the reset with the computer completely stationary on a desk, so physical movement is not required to trigger the failure.
The failure is strongly correlated with clamshell sleep/dark-wake transitions. It can happen shortly after closing the lid or several minutes later.
This is not just an application crash. Multiple reproductions have generated ResetCounter reports and PMU watchdog/reset fault data.
Most recent reproduction (verified Safe Mode):
I booted using Apple-silicon Safe Mode and personally verified that “Safe Boot” was displayed before testing. I then closed the lid normally and left the Mac alone. It rebooted after a few minutes, while the lid was closed.
Immediately afterward macOS created a new type-115 ResetCounter report. Relevant fields:
Boot failure count: 1
Boot faults: rst btn_rst,btn_seq_reset target_off_shutdown
Boot stage: 0x40
socId: 6030
socRevision: 11
DumpPanic then read auxiliary PMU fault data containing:
wdog,reset_in_1
rst_in,reset_in_1_deassert
During the same boot, the AppleSPMIPMU driver logged:
rst crash,crash_in wdog,reset_in_1 rst_in,reset_in_1_deassert
and another PMU entry contained the same sequence plus:
rst btn_rst,btn_seq_reset target_off_shutdown
I am not assuming undocumented meanings for every PMU flag. For example, I am not treating btn_rst as proof that a physical power button was pressed. The important point is that the same low-level watchdog/reset pattern has occurred repeatedly.
Also, DumpPanic successfully read 3,145,728 bytes from the panic area, but reported:
it did not contain any paniclog data (buffer was all zeros)
No paniclog data found in local device
So there is no normal surviving kernel panic report to inspect.
Earlier controlled reproduction after reinstalling macOS:
I performed an in-place reinstall of macOS from Recovery. The machine was confirmed to be running 26.6.2 (25G83) afterward.
Immediately after the reinstall I ran another controlled test while recording kernel/powerd/powerexperienced/DumpPanic logs. I closed the lid once and did not touch the machine.
The logs showed a normal physical close sequence:
SMC HID Event: 03 01 00
PMRD: Clamshell closed
clamshell closed 1
sleep reason Clamshell Sleep
macOS then entered the clamshell sleep path.
Shortly afterward it transitioned from dark wake to full wake due to HID activity, even though I had not physically reopened the lid. A corresponding low-level Clamshell opened event was not present in the captured stream, and the kernel continued to report:
clamshell closed 1
It then attempted clamshell sleep again and entered dark wake with:
DarkWake: sleepASAP 1, clamshell closed 1
The machine later reset.
On the following boot a new ResetCounter reported Boot failure count: 1, and the auxiliary PMU fault data again contained:
wdog,reset_in_1
rst_in,reset_in_1_deassert
The kernel PMU log also contained crash,crash_in.
DumpPanic again read 3,145,728 bytes and found the panic buffer all zeros.
There was another earlier controlled reproduction with the same PMU watchdog/reset class, so this is not a single isolated event.
Lid-angle / clamshell testing:
I separately monitored the low-level lid events while deliberately opening and closing the display. Normal physical movements produced coherent pairs such as:
SMC HID Event: 03 01 00 / PMRD: Clamshell closed
and:
SMC HID Event: 03 00 01 / PMRD: Clamshell opened
I did not observe simple spontaneous open/close flickering while the display was stationary.
This does not completely rule out an intermittent lid sensor/flex/magnet issue, but it does not look like a straightforward continuously-failing lid sensor.
Other troubleshooting:
Apple Diagnostics reports no issues.
The issue survived an in-place macOS Recovery reinstall.
The issue reproduces in verified Safe Mode.
I have not found a conventional kernel panic payload for these failures.
I am not attributing the issue to Wi-Fi, Bluetooth, Chrome, ANE, or any other subsystem based only on incidental log messages.
Previous Apple repair:
Earlier this year Apple serviced the machine for the same exact symptoms. The service summary says the following parts were replaced:
Logic board — symptom category: System Startup/Stability/Unexpected Restart/Shutdown
Lid Angle Sensor — symptom category: System Startup/Stability/Will Not Sleep
Touch ID board
MagSafe 3 board
The same closed-lid reset problem continues after that repair.
What I’m trying to understand:
Is this PMU watchdog/reset pattern known on M3 Pro / T6030 systems during clamshell sleep or dark wake?
Are there specific sysdiagnose, power-management, PMU, or firmware logs that would be useful to Apple engineering?
Would a DFU firmware Revive be a meaningful next isolation step given that Recovery reinstall, Safe Mode, diagnostics, and a prior logic-board/lid-sensor replacement have not resolved it?
I can provide sanitized ResetCounter output and relevant unified-log excerpts. I have intentionally omitted serial numbers, repair identifiers, CrashReporter keys, account information, and other identifying details here.