Home › Panic codes › AOP DART exception (Always-On Processor memory access blocked)
iPhone panic type
AOP DART exception (Always-On Processor memory access blocked)
DART is Apple's IOMMU: every memory access by a coprocessor goes through its DART. "dart-aop ... DART exception" means the Always-On Processor (the always-running part of the chip that services sensors) made an access its DART could not translate, and the kernel panicked. SID is the stream that faulted. ERROR_ADDRESS 0x0 with "no exceptionInfo" gives no target address, so this line alone does not name a sensor or part.
Likely: AOP firmware / iOS (most likely for a single panic, especially soon after an update) · A sensor on the AOP feeding it bad data (only when other AOP panics in the same phone name a sensor)
Decoder match rule
dart-?a[o0]p[^\n]{0,60}?DART\s*(?:DART\s*)?excepSteps
- Note the iOS version and how often it happens. A single panic on a new iOS build: update / DFU restore and watch, no hardware action yet.
- Collect two or three more panic-full files. If they show other AOP panics (SCM timeout, !pulse, I2C, NMI) naming a sensor, follow that sensor's steps.
- Same dart-aop panic again after a clean DFU restore without restoring the backup: front sensor / proximity / Face ID flex and the sensor flexes are the next suspects; swap-test one at a time.
- Do not replace parts or the board on this panic alone.
Sources
- Linux kernel DT binding apple,dart - "Device Address Resolution Table", an IOMMU in front of DMA masters; one stream ID (SID) per master (accessed 2026-10-14)
- iFixit (RU) - iPhone Kernel Panics: "AOP is the Always On Processor, part of the CPU that runs functions that work all the time" (accessed 2026-10-14)
Hinglish me
AOP DART exception (Always-On Processor ka memory access block hua)
DART is Apple's IOMMU: every memory access by a coprocessor goes through its DART. "dart-aop ... DART exception" means the Always-On Processor (the always-running part of the chip that services sensors) made an access its DART could not translate, and the kernel panicked. SID is the stream that faulted. ERROR_ADDRESS 0x0 with "no exceptionInfo" gives no target address, so this line alone does not name a sensor or part.
Note the iOS version and how often it happens. A single panic on a new iOS build: update / DFU restore and watch, no hardware action yet.
Collect two or three more panic-full files. If they show other AOP panics (SCM timeout, !pulse, I2C, NMI) naming a sensor, follow that sensor's steps.
Same dart-aop panic again after a clean DFU restore without restoring the backup: front sensor / proximity / Face ID flex and the sensor flexes are the next suspects; swap-test one at a time.
Do not replace parts or the board on this panic alone.