physmap-fault — Software
Mensagem escrita pelo kernel (osfmk/arm64/sleh.c) quando o processador sinaliza, em modo kernel, uma falha de acesso (página não mapeada, flag de acesso ou permissão) num endereço da “abertura física” (physmap), a área que mapeia toda a memória RAM. O kernel nunca espera uma falha nesse lugar: um trecho de código do kernel leu ou escreveu uma página que não estava (ou não estava mais) mapeada, por um ponteiro vencido ou corrompido. Portanto é, antes de tudo, um tipo de bug de software do kernel, não um driver em particular; uma corrupção de memória por hardware (bit invertido num ponteiro) é possível, mas rara, e não se repete de forma idêntica. Em dois logs de iPhone 16 (iOS 18.6.2) analisados: mesma instrução com falha apesar de endereços diferentes (KASLR), mesmo processo (mediaplaybackd), mesmo caminho via apfs, cópia a partir de uma página physmap não mapeada (ESR 0x96000007 = falha de tradução de nível 3): panic reproduzível num caminho de código preciso, o que aponta para um bug do iOS e não para a memória ou o SoC.
iPhone
Software primeiro (bug do kernel do iOS / sistema de arquivos); memória ou placa só se persistir com iOS limpo
Primeira verificação
Atualizar o iOS; se o panic voltar, restaurar pelo computador como novo iPhone sem backup e anotar o processo envolvido (“panicked task”): se for sempre o mesmo (ex.: mediaplaybackd, reprodução de mídia), procurar o app ou o conteúdo que dispara o problema.
Fontes
- 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 status de falha: FSC_TRANSLATION_FAULT_L3 = 0x07) ↗
- Apple Developer Forums #124127 – iOS system panic “Kernel data abort”: resposta do engenheiro do DTS (panic de kernel = bug do sistema, a reportar com um sysdiagnose) ↗
- iFixit – iPhone Kernel Panics (wiki): panic de kernel, “software primeiro” quando nada aponta para um componente ↗