Lettura fuori SMC

Un consiglio comune per la risoluzione dei problemi è "resettare SMC!"

Ma in realtà è un po 'poco chiaro perché e come questo risolve le cose.

Apple elenca anche solo alcuni sintomi in:

How to reset the System Management Controller (SMC) on your Mac Learn when and how to reset the SMC on an Intel-based Mac.

What the SMC does…

Ma questo non ti dice cosa potrebbe essere veramente sbagliato lì. Nota che questa domanda how-to-diagnose-the-smc punta ai sintomi , non i dati reali.

Come leggiamo quali valori sono memorizzati lì? Cioè: tutti loro e nel loro raw.

If you've ever looked under the hood at a Mac OS X application for controlling fans or reading sensor data, then you will undoubtedly have seen two files - smc.c and smc.h. Used in just about every project that relies upon reading SMC values.

The problem is, these files have become something of a dark magic - with no real comments or explanations anywhere, no bindings for NS* classes and a lack of any OOP implementation.

Se guardiamo alle applicazioni di terze parti per questo tipo di attività potremmo trovare: SMCKit che legge alcuni valori; SMCmonitor è dietro un muro e smc-command (che non è più supportato e non genera?).

Nessuno di questi sembra essere in grado di leggere veramente tutti i valori? Esiste un metodo per leggere tutti i valori e le impostazioni?

Questa è una prospettiva dell'utente finale o dello strumento per la risoluzione dei problemi: dovrebbe essere utile per controllare cosa è andato storto o è sbagliato, quando è necessario un SMC , se ciò ha effettivamente risolto un problema, o indipendentemente dal fatto che sia stato eseguito o meno un reset SMC (l'utente finale non colpisce i tasti corretti, senza il cavo di alimentazione collegato, con altre periferiche).

Attualmente la taglia unica si adatta a tutti gli approcci black box di: "Qualcosa di strano" - "Esegui un reset di SMC!" sembra un consiglio voodoo, troppo spesso. (Come indicato da molti commenti su questo sito che estendono la precedente conversazione con "Non ha fatto nulla di utile".)

Esempio concreto per applicarlo a: Nella risposta al problema della GPU - Boot Hang on Grey Screen una variabile EFI viene scritta nella NVRAM. Questo funziona per un tempo abbastanza bene. Ma dopo un po 'il sistema si blocca svegliandosi dal sonno dopo aver appena chiuso il coperchio; ma di solito non si blocca ancora dopo aver emesso il comando di sospensione tramite menu o timer. Questo coperchio-sonno funziona normalmente come gli altri dopo aver applicato l'hack e riprende a funzionare dopo aver ripristinato l'SMC e aver applicato nuovamente l'hack.

Usando il% co_de binario di smcFanControl elencato sopra, siamo in grado di scaricare una serie di variabili (estratto):

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)

Dopo aver fatto questo salvando i dati su un file per un po ', ora ho alcuni dati nel tempo. Ma non riesco a identificare le parti cruciali. Quali variabili controllano il comportamento del sonno? C'è più documentazione esatta là fuori su questo?