5

A common troubleshooting advice is to "reset the SMC!"

But it is actually a bit unclear why and how this fixes things up.

Apple also only lists a few symptoms 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…

But this does not tell you what might be really wrong there. Note that this question how-to-diagnose-the-smc aims at symptoms, not the real data.

How do we read what values are stored there? That is: all of them and in their 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.

If we look at third party applications for this kind of task we might find: SMCKit which reads some values; SMCmonitor is behind a wall and smc-command (which is not supported anymore and doesn't build?).

None of these seem to be able to really read all values? Is there a method to read all values and settings?

This is from an end user or troubleshooter perspective: it should be useful to check what went wrong or is wrong, when an SMC reset might be needed, if that did indeed fix a problem, or whether or not an SMC reset was indeed performed (end user not hitting the right keys, without power cord connected, with other peripherals).

Currently the one size fits all black box approach of: "Something's weird" – "Perform an SMC reset!" sounds like voodoo advice, all too often. (As indicated by many comments on this site that extend the above conversation with "Didn't do anything useful.")

Concrete example to apply this to: In the answer to GPU problem - Boot Hangs on Grey Screen an EFI variable is written to NVRAM. This works for a time quite beautifully. But after a while the system hangs on waking from sleep after just closing the lid; but usually still does not hang on wake after issuing the sleep command via menu or timer. This lid-sleep works usually like the others after applying the hack and starts to work again after resetting the SMC and re-applying the hack.

Using the binary smc from smcFanControl listed above we are able to dump a bunch of variables (excerpt):

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)

After doing this saving the data to a file for a while I now have some data over time. But I fail to identify the crucial parts. Which variables control the sleep behaviour? Is there more exact documentation out there on this?

LаngLаngС
  • 8,279
  • 1
    SMCWrapper (which you've linked to in the question) has the intention to do exactly what you are asking here, so I wonder what exactly you are looking for here in terms of an answer? Also the question as written (especially with all the references to code) is primarily in the software development space which would make it off-topic here. Do you want to edit it to make it more specific and on-topic? – nohillside Nov 05 '17 at 16:38
  • @patrix Thx for the hint. When I checked SMCWrapper just listed temp and fans values ('wrapping a sensor readout api'?). There has to be much more to make "reset it" a viable strategy. Currently this is about insight gaining for a more rational trouble shoot and diagnosis. – LаngLаngС Nov 05 '17 at 17:03
  • 1
    See also How to diagnose the SMC? for a question with a similar intent. – Graham Miln Nov 15 '17 at 14:17
  • 2
    Given the workings of Apple's System Management Controller (SMC) chipset is proprietary, have you considered asking Apple's engineers directly through an Apple Developer Technical Support (DTS) incident? I presume they will be the only people who really know what is going on inside. – Graham Miln Nov 15 '17 at 14:20
  • 1
    IMO, "Reset the SMC" is the defacto, conditioned response to 99% of the issues encountered while using a Mac though it in all reality has nothing to do with most of the problems a service restart (reboot) won't fix. The only time I have reset an SMC in the last 3 years (personally speaking) is when I replaced a battery in my MacBook Pro. Too much credence is give to resetting chipsets. – Allan Nov 15 '17 at 14:33
  • "Too much credence is give to resetting chipsets" - thing is that it is one of the very few official Apple-sanctioned methods to affect Apple hardware. There are a few more, and finally "go to the Apple store". It is not "too much credence" it is lack of Apple-sanctioned alternative. Even cleaning your macbook with compressed air is not "apple-sanctioned". –  May 27 '21 at 06:00
  • And there is no way to read the SMC. At least in early 2010s models the chip they used for SMC had "password-protected" read (32bit password). One uses wrong password, one not only fails to read the contents, but actively erases the firmware, so "guessing" the password was not an option. –  May 27 '21 at 06:02

0 Answers0