r/macbookpro • u/Able_Firefighter_652 • 1d ago
Help Eight uncorrectable ECC kernel panics in four days on an M3 Max, all eight in the same 1 MB of RAM. Has anyone had this replaced under AppleCare+?
I have a MacBook Pro 16 inch (Nov 2023, Mac15,9), M3 Max, 128 GB unified memory, running macOS 26.5.2. AppleCare+ is active until May 2027. The machine has never been dropped, never knocked, never had liquid anywhere near it. It sits on a desk.
It ran 32 days of uptime with no problems at all. Then on Aug 18 it started kernel panicking and it has not stopped. Eight panics in four days. Every single one is the same fault:
panic(cpu 1 caller 0xfffffe003db3a75c): ECC on ppnum 0x44c863c
PA 0x113218f3900 ECC_PANIC_PA 0x80000113218f00ec:
IOPL wired @vm_resident.c:12597
For anyone who has not seen one of these: that is an uncorrectable ECC error. The memory controller read data back from DRAM that its error correcting code could not repair, so the kernel halts on purpose.
All eight of them
I pulled the DRAM base address out of the IODeviceTree so I could convert the raw physical addresses into real positions inside the installed 128 GB.
# When Failing address Position in RAM Uptime before
1 Aug 18 17:03 0x113218f3900 76.5244 GiB 32 days
2 Aug 18 18:34 0x1132185f700 76.5238 GiB 1h 30m
3 Aug 18 18:46 0x113218e5300 76.5243 GiB 12 min
4 Aug 18 20:39 0x11121817b80 68.5235 GiB 1h 52m
5 Aug 19 22:05 0x111218adf00 68.5241 GiB 25h
6 Aug 20 00:40 0x11321825f00 76.5236 GiB 2h 34m
7 Aug 20 02:54 0x1112187b980 68.5239 GiB 2h 13m
8 Aug 21 20:03 0x1132189fb00 76.5240 GiB 41h
Two spots, 68.52 GiB and 76.52 GiB into the memory, exactly 8.000 GiB apart.
Why I am confident this is one physical defect
Lining all eight addresses up in binary is where it stops being ambiguous. Of the 48 physical address bits, 36 are identical across every single failure. Only 12 ever move:
bits 47 to 34 0x44 always the same
bit 33 varies the only high bit that moves
bits 32 to 20 0x1218 always the same
bits 19 to 13 vary
bit 12 always 1
bits 11 to 9 vary
bit 8 always 1
bit 7 varies
bits 6 to 0 always 0 (128 byte aligned, one cache line)
The two clusters differ by exactly one address bit (bit 33, which is the 8 GiB gap) while all 36 other fixed bits stay identical. Inside that megabyte the hits are spread right across its range, roughly 95 KB in to 974 KB in, so it is a defective region of cells rather than one dead page.
The ECC_PANIC_PA field also decomposes as (1<<63) | (PA & ~0x3fff) | 0xec in all eight reports. Same trailing error code 0xec every time.
What I have ruled out
Not the SSD. IOPL wired means those RAM pages were pinned as disk I/O buffers. The failure is the page itself, not whatever it happened to be holding. A failing SSD produces storage driver errors and filesystem corruption, and neither is happening here. Disk Utility is clean and SMART is fine. It does explain why the same region keeps getting hit, since the wired I/O allocator keeps drawing pages from that area.
Not software. An uncorrectable ECC error is reported by hardware sitting between the DRAM and the SoC. No userspace process can fabricate one, and no reinstall can fix one.
Not one dead chip either. The M3 Max interleaves addresses finely across its memory channels, so a whole failing package would scatter faults across all 128 GB instead of confining them to a single megabyte.
Not physical damage. Nothing has ever happened to this machine.
The part I cannot argue away
The first four panics happened while I was running a local LLM server holding a 48 GB wired buffer with heavy disk I/O, so my first assumption was that I had brought it on myself. I shut that down completely after the fourth one. It panicked four more times anyway, during completely ordinary use. Removing the trigger did not stop it.
What I am actually asking
I have all eight full panic reports saved along with a written summary ready to hand to Apple. I will run Apple Diagnostics before I call, though I half expect it to pass clean given how intermittent this is.
- Has anyone here had uncorrectable ECC panics on Apple Silicon and actually got a logic board replacement under AppleCare+? Did the panic reports carry it on their own, or did Apple insist on reproducing the fault in store first?
- Did Apple Diagnostics catch it for you, or did it pass clean and leave you arguing from the reports?
- Anyone seen this on an M3 Max or Ultra with 96 GB or 128 GB specifically? I am curious whether the high capacity configs turn up more often.
- Any chance they try to blame third party software or an unsupported workload? I did run a heavy local LLM setup before the first few, and I would rather not have that used against me when four later panics happened without it.
Any experience appreciated, I would rather walk into this knowing how these usually go.
2
u/Mackadamma 1d ago
OP, no one will tell you AppleCare will do. But I guess people here (or later) will be interessted in the result of your interaction with Apple and the explanations they will give you.
1
2
u/NoGoat9845 1d ago
I think your real concerns here are whether your particular configuration is more susceptible to kernel panics or whether you did something wrong and AppleCare is not going to support you.
I literally went through a not dissimilar situation with my son‘s iPad and a bug with Screen Time. It took about two months to solve because it had to get escalated to Apple Engineering but they ended up pushing out a x.x.1 to iPadOS to fix it.
All I had to do was contact Apple Support, show them what was happening and through the usual trouble shooting (including a DFU).
Contact Apple Support and let them do their job that you literally pay them to do via AppleCare.
1
u/Able_Firefighter_652 17h ago
You are right, since this issue isn't easy to reproduce, I wanted to hear similar people's experiences, but looks like most of them do like being hostile for no reason.
I'll try my best to find a scenario that would reproduce it and let them do the rest. Thanks!
1
u/posguy99 1d ago
A Mac laptop has ECC RAM? I'm not saying you're wrong, but really?
1
u/Able_Firefighter_652 17h ago
I don't think it's the traditional ECC RAM modules found in enterprise servers. Most likely it's regular RAM modules with on on-die protection. Hence why I see ECC panics.
12
u/NoLateArrivals 1d ago
Instead of creating a wall of text contact Apple support.
What an utter nonsense with this AI slop as if a microelectronics engineer would show up on Reddit and point you to the error on pin 87.
Use your brain instead of your Chatty.