Leyendo el SMC

2

Un consejo común para la solución de problemas es "restablecer el SMC!"

Pero en realidad no está muy claro por qué y cómo esto arregla las cosas.

Apple también solo muestra algunos síntomas en:

  

Cómo restablecer el Controlador de gestión del sistema (SMC) en tu Mac   Obtenga información sobre cuándo y cómo restablecer el SMC en un Mac basado en Intel.

     

Lo que hace el SMC ...

Pero esto no te dice lo que podría estar realmente mal allí. Tenga en cuenta que esta pregunta cómo diagnosticar-el-smc apunta a los síntomas , no los datos reales.

¿Cómo leemos qué valores se almacenan allí? Es decir: todos ellos y en su estado original.

  

Si alguna vez ha mirado bajo la cubierta a una aplicación de Mac OS X para controlar a los fanáticos o leer datos de sensores, indudablemente habrá visto dos archivos: smc.c y smc.h. Se usa en casi todos los proyectos que se basan en la lectura de valores SMC.

     

El problema es que estos archivos se han convertido en una especie de magia oscura, sin comentarios ni explicaciones reales en ningún lugar, sin enlaces para las clases de NS * y falta de implementación de OOP.

Si observamos aplicaciones de terceros para este tipo de tareas, podríamos encontrar: SMCKit que lee algunos valores; SMCmonitor está detrás de una pared y smc-command (que ya no se admite y no se genera).

¿Ninguno de estos parece ser capaz de leer realmente todos los valores? ¿Hay algún método para leer todos los valores y configuraciones?

Esto es desde la perspectiva de un usuario final o de un solucionador de problemas: debería ser útil para verificar qué salió mal o está mal, cuando un restablecimiento de SMC podría ser necesario, si eso efectivamente solucionó un problema, o si se realizó o no un reinicio SMC (el usuario final no presiona las teclas correctas, sin el cable de alimentación conectado, con otros periféricos).

Actualmente, el tamaño de una sola caja se adapta a todos: "Algo es raro" - "¡Realice un reinicio SMC!" Suena como un consejo vudú, con demasiada frecuencia. (Como lo indican muchos comentarios en este sitio que extienden la conversación anterior con "No hice nada útil")

Ejemplo concreto para aplicar esto a: En la respuesta a Problema de GPU: el sistema se bloquea en la pantalla gris una variable EFI se escribe en la NVRAM. Esto funciona durante un tiempo bastante bien. Pero después de un tiempo, el sistema se bloquea al despertarse después de simplemente cerrar la tapa; pero, por lo general, aún no se bloquea al despertar después de emitir el comando de suspensión mediante el menú o el temporizador. Este sueño de tapa generalmente funciona como los demás después de aplicar el truco y comienza a funcionar nuevamente después de restablecer el SMC y volver a aplicar el truco.

Usando el binario smc de smcFanControl listado arriba, podemos volcar un montón de variables (extracto):

TCGC  [sp78]  40.000   (bytes 28 00)
TCSA  [sp78]  36.000   (bytes 24 00)
TCTD  [sp78]  0.098    (bytes 00 19)
TG0D  [sp78]  -128.000 (bytes 80 00)
TG0P  [sp78]  30.500   (bytes 1e 80)
THSP  [sp78]  28.500   (bytes 1c 80)
TM0S  [sp78]  54.969   (bytes 36 f8)
TMBS  [sp78]  0.000    (bytes 00 00)

Después de hacer esto guardando los datos en un archivo por un tiempo, ahora tengo algunos datos a lo largo del tiempo. Pero no logro identificar las partes cruciales. ¿Qué variables controlan el comportamiento del sueño? ¿Hay más documentación exacta sobre esto?

    
pregunta LangLangC 05.11.2017 - 17:03

0 respuestas

Lea otras preguntas en las etiquetas