Cómo diagnosticar demasiados kernel panics en un iMac Retina 2017 de 21" ejecutando Monterey

Has activado la simbología del kernel y hemos comprobado que no proporciona un backtrace legible para los humanos. Las posibilidades para esto son (1) que Apple haya eliminado repentinamente la capacidad de simbolización (poco probable), o (2) que las direcciones pertenezcan a un rango que no se asigne a una región simbolizada del código. Ninguna de las dos cosas sería un comportamiento esperado en esta situación.

Además, no conozco ninguna herramienta disponible públicamente para decodificar el macOSProcessedStackshotData campo del informe, lo que podría haber dado lugar a algo procesable.

No obstante, disponemos de información útil incluso sin símbolos:

1. Los cuatro informes de pánico incluyen lo siguiente idéntico firma:

   Machine-check capabilities: 0x0000000000000c0a
   family: 6 model: 158 stepping: 9 microcode: 240
   signature: 0x906e9
   Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
   10 error-reporting banks
   Processor 0: IA32_MCG_STATUS: 0x0000000000000005
   IA32_MC0_STATUS(0x401): 0xb200000000030005

   Esta firma significa que su problema pertenece a una clase de pánico llamada Excepción de comprobación de la máquina (MCE), que se inicia en el silicio x86 en lugar de xnu . Así que, con toda probabilidad, el backtrace mostrado sólo mostraría el manejador de pánico MCE AST y no indicaría nada sobre el origen del MCE. Esto es fuertemente sugerido por el hecho de que restando el deslizamiento KASLR de cada una de las direcciones de retorno del marco se obtiene una pila interna idéntica:

   0xffffffxxxxxxxxxx : 0xffffffxxxxx81c8d
   0xffffffxxxxxxxxxx : 0xffffffxxxxxe1596
   0xffffffxxxxxxxxxx : 0xffffffxxxxxd0963
   0xffffffxxxxxxxxxx : 0xffffffxxxxx21a70
   0xffffffxxxxxxxxxx : 0xffffffxxxxx8205d
   0xffffffxxxxxxxxxx : 0xffffffxxxxx81816
   0xffffffxxxxxxxxxx : 0xffffffxxxxx15163
   0xffffffxxxxxxxxxx : 0xffffffxxxxxd19d7
   0xffffffxxxxxxxxxx : 0xffffffxxxxx1c94c
   0xffffffxxxxxxxxxx : 0xffffffxxxxx222cf

   Ese es el patrón en 3 de los 4 pánicos. El cuarto ( Kernel-2022-05-27-160805.panic ) parecía estar en medio de otra operación cuando se produjo el AST. Podría haber sido marginalmente útil saber lo que estaba haciendo, pero supongo que sólo machine_idle() o algo así.

   En otras palabras: Los backtraces no son útiles en este caso.

2. Echando un vistazo a Manual del desarrollador de software de Intel, vol. 4, cap. 15-16 su informe muestra sistemáticamente que el primer registro MCA local del núcleo ( MC0 ) en su BSP ( Processor 0 ) tiene un error de paridad interna no corregido ( 0xb...05 ). Es más, la CPU no fue capaz (o no tuvo sentido) de identificar una dirección asociada a ese error, por lo que no hay IA32_MC0_ADDR valor del registro a examinar. El código de error específico del modelo ( 0x...3... ) no es decodificable a través de la documentación pública por lo que no sabemos lo que significa para su CPU específica ( Core i5-7500 ).

3. El hecho de que las cuatro firmas sean idénticas significa que su problema se debe a una causa específica y reproducible.

Y, sin embargo, a pesar de estos importantes indicios, simplemente no disponemos de suficiente información ni de herramientas de depuración para obtener datos más granulares sobre cuál podría ser la causa. Las causas root de los MCE abarcan todo el hardware, el firmware y el software: un fallo en cualquiera de ellos puede manifestarse como un MCE. Debido a la naturaleza de bajo nivel de los MCE y al hecho de que detienen la ejecución de la CPU, la cantidad de datos de diagnóstico útiles que se pueden recopilar de un sistema cerrado en tiempo de ejecución de esta generación de núcleos Intel es muy limitada (en comparación con un pánico del kernel "ordinario", cuando la CPU continúa obteniendo y ejecutando instrucciones y xnu a menudo es capaz de seguir funcionando en gran medida, lo que permite la depuración interactiva).

Lo que esto significa para ti es que estamos como atrapados en un clavo ardiendo por nuestra cuenta. Indicas que has hecho algunos experimentos de aislamiento de hardware. Sólo hay un par de cosas menores que se me ocurren ahí:

• Qué interfaz(es) (cable(s)) ¿usas para conectar tu(s) disco(s) externo(s) a tu Mac?
• ¿Puedes probar a correr en Modo seguro (mantener Shift durante el arranque) durante un tiempo y ver si el pánico desaparece por completo o sigue repitiéndose?
• ¿Puede intentar ejecutar un prueba de memoria ampliada ? (Descargue la versión gratuita y dd el memtest86-usb.img imagen en una unidad flash, y luego arrancar desde ella). Apple Diagnostics a menudo pasa por alto los errores que MemTest86 detecta, así que ejecute eso y vea si obtiene algún error (¡tomará un tiempo!).