physmap-fault — Software
Mensaje escrito por el kernel (osfmk/arm64/sleh.c) cuando el procesador señala, en modo kernel, un fallo de acceso (página no mapeada, indicador de acceso o permiso) en una dirección de la «apertura física» (physmap), la zona que proyecta toda la memoria RAM. El kernel nunca espera un fallo ahí: una parte del código del kernel leyó o escribió una página que no estaba (o ya no estaba) mapeada, mediante un puntero caducado o corrupto. Por tanto es primero un tipo de bug de software del kernel, no un driver en concreto; una corrupción de memoria por hardware (un bit invertido en un puntero) es posible pero rara y no se repite de forma idéntica. En dos logs de iPhone 16 (iOS 18.6.2) analizados: misma instrucción fallida pese a direcciones distintas (KASLR), mismo proceso (mediaplaybackd), mismo camino por apfs, copia desde una página physmap no mapeada (ESR 0x96000007 = fallo de traducción de nivel 3): pánico reproducible en un camino de código preciso, lo que apunta a un bug de iOS más que a la memoria o al SoC.
iPhone
Primero software (bug del kernel de iOS / sistema de archivos); memoria o placa solo si persiste con un iOS limpio
Primera comprobación
Actualizar iOS; si el pánico vuelve, restaurar desde el ordenador como iPhone nuevo sin copia de seguridad y anotar el proceso implicado («panicked task»): si siempre es el mismo (p.
Fuentes
- Apple XNU – sleh.c, handle_kernel_abort(): «Ensure no faults in the physical aperture…» → panic_with_thread_kernel_state("Unexpected fault in kernel physical aperture") ↗
- Apple XNU – proc_reg.h (códigos de estado de fallo: FSC_TRANSLATION_FAULT_L3 = 0x07) ↗
- Apple Developer Forums #124127 – iOS system panic «Kernel data abort»: respuesta del ingeniero de DTS (pánico del kernel = bug del sistema, hay que reportarlo con un sysdiagnose) ↗
- iFixit – iPhone Kernel Panics (wiki): pánico del kernel, «primero el software» cuando nada apunta a un componente ↗