Jump to content

2,083 posts in this topic

Recommended Posts

Advertisement

Hi @vector sigma,

is it possible to make somehow HWMonitorSMC2 to NOT autostarted at system launch?

I checkout its preferences.

I exclude in from Login Items.

I checked Luach Daemons.

Anyway after restart the monitor is started again...

 

I need this to debug SMC keys without monitor.

Share this post


Link to post
Share on other sites
4 hours ago, Slice said:

Hi @vector sigma,

is it possible to make somehow HWMonitorSMC2 to NOT autostarted at system launch?

I checkout its preferences.

I exclude in from Login Items.

I checked Luach Daemons.

Anyway after restart the monitor is started again...

 

I need this to debug SMC keys without monitor.

Hi Slice, that already happened to me... but later I've realize that I hade more the one HWMonitorSMC2.app that wanted to load at login (due to some tests with various copies of the source code), and since at app initialization each app unload itself if another HWMonitorSMC2.app is already running ..at next reboot, again, another app was showing up. Please ensure this is not the problem, anyway I'll revise the code.

 

EDIT

For the moment, a simple way to ensure no smc calls are made, just go to the settings and uncheck each sensor group that reads smc keys:

488682568_Screenshot2019-07-19at19_14_27.png.858b09e406e9b0933f73a2f396500874.png

media, ram and battery groups doesn't use the smc. Settings are shared between each app, so this way we can ensure smc doesn't get  opened.

On 7/7/2019 at 9:40 AM, zkingtut said:

Thank you all

Please I got this result but I am not sure !!!

Please see my GPU Sensors ; is it correct ?

Screen Shot 2019-07-07 at 9.30.47 AM.png

looks ok to me

Edited by vector sigma

Share this post


Link to post
Share on other sites
3 hours ago, vector sigma said:

Hi Slice, that already happened to me... but later I've realize that I hade more the one HWMonitorSMC2.app that wanted to load at login (due to some tests with various copies of the source code), and since at app initialization each app unload itself if another HWMonitorSMC2.app is already running ..at next reboot, again, another app was showing up. Please ensure this is not the problem, anyway I'll revise the code.

 

EDIT

For the moment, a simple way to ensure no smc calls are made, just go to the settings and uncheck each sensor group that reads smc keys:

 

media, ram and battery groups doesn't use the smc. Settings are shared between each app, so this way we can ensure smc doesn't get  opened.

looks ok to me

This moment I am sure having only one app. But I don't know if macOS remembered it twice.

I resolved the problem deleting the app. Next time I will restore it from archive.

 

I have many news about using SMC keys so FakeSMC and plugins will be updated.

Share this post


Link to post
Share on other sites

Hi @Slice per my earlier message, were I tried your plugin for the ITE IT8987VG, I suspect that I have too few SMC keys reported by your SMC_util3 as its output has no visual indication of a FAN being reported, FNum shows 0...!

 

Could this mean that the Intel NUC8's DSDT is reporting no fans, despite visible in the BIOS page? Can we help this situation by creating an SSDT-xxx.AML to retrieve that FAN data or recreate it from the disassembled DSDT? This is very curious, why would Intel block these keys...

 

Also, can you confirm that IntelCPUMonitor supports officially the Coffee Lake (Bean Canyon) generation? It's Intel Core i7-8559U / Intel Iris Plus Graphics 655.

 

Any ideas/help are welcome. Thanks again.

Share this post


Link to post
Share on other sites

Yes, IntelCPUMonitor supported CoffeeLake processores model 0x9E. See dmesg->kernel.log to find any messages about CPU.

Give me your DSDT and I will look if there is something to do with it. And all SSDT as well!

Share this post


Link to post
Share on other sites
On 7/22/2019 at 4:31 AM, Slice said:

Yes, IntelCPUMonitor supported CoffeeLake processores model 0x9E. See dmesg->kernel.log to find any messages about CPU.

Give me your DSDT and I will look if there is something to do with it. And all SSDT as well!

Thanks for your kind offer.

BIOS v56 ACPI Tables (DSDTs/SSDTs) attached. 

Intel NUC8i7BEH BIOS v56 ACPI Tables.zip

Share this post


Link to post
Share on other sites
On 7/26/2019 at 8:16 PM, MacKonsti said:

Thanks for your kind offer.

BIOS v56 ACPI Tables (DSDTs/SSDTs) attached. 

Intel NUC8i7BEH BIOS v56 ACPI Tables.zip

I see you have "ITE8708" so usual plugin ITE87X should work on your hardware but there is no such id

there are

  IT8705F = 0x8705,
  IT8712F = 0x8712,

I will add here 8708 a little later.

Share this post


Link to post
Share on other sites
On 7/29/2019 at 10:39 AM, Slice said:

I see you have "ITE8708" so usual plugin ITE87X should work on your hardware but there is no such id

there are


  IT8705F = 0x8705,
  IT8712F = 0x8712,

I will add here 8708 a little later.

 

Hi @Slice thank you for your time spent on this DSDT pack, I am impressed because Intel's product PDF explicitly mentions ITE IT8987E-VG (most likely chipset ID 0x8987 as I tried to find it by booting to Linux and run some hardware info command) in this official PDF here (see page 2 and page 19). Your comments welcome.

 

On 7/29/2019 at 9:50 PM, Slice said:

@MacKonsti 

Test, please

ITEIT87x.kext.zip

 

Thank you very much, please allow me for some days to reply, I am currently away from home and have no access to the NUC8 hackintosh. Thank you again, I look forward!

 

You think there is a need for a special SSDT-xxx device still? Because plugins or not, you SMC_util3 had reported zero fans :(

Edited by MacKonsti

Share this post


Link to post
Share on other sites
5 hours ago, Slice said:

why HWMonitorSMC2 doesn't show FAN when it really present but for a moment it is silent.

The code suppose that to be a good sensor the value must be greater of 0 and less-equal of 7000, good or not just to not show improbable values:

case .tachometer:
      sensor.stringValue = String(format: "%.0f", v)
      sensor.doubleValue = v
      valid = gShowBadSensors || (v > 0 && v <= 7000)

 

To debug sensors you have to create a file or a directory in to your Desktop called HWBadSensors, and all sensors will show up, even if considered bad (require a restart of the app). 

5 hours ago, Slice said:

If I burn CPU the FAN will rotate but HWMonitorSMC2 will not catch it.

The code I show you above validate sensors at the app start, so later if a FAN is malfunctioning any value is shown. In the project, drivers already do something similar:

   if (readTachometer(i) > 10 || nameLength > 0) {
      if (!addTachometer(i, (nameLength > 0 ? name->getCStringNoCopy() : 0))) {
        WarningLog("error adding tachometer sensor %d", i);
      }
    }

must be > 10 rpm.... so if the FAN is already malfunctioning this is already excluded at startup. We can make it accept v >= 0 in the app, but if readTachometer return 0 the driver will not even add the key.... plus specs for some chips clearly state that a minimum value should be like 1.35e6 / 0xFFFF i.e 20.59... yep, unless we talk about laptop's fan(s).. did you?

 

But then the question is, how distinguish between a bad reading of the sensor and a malfunction or a breakage at start up? 

 

 

P.S. sensors validation happens for all other kinds like voltages, frequencies, temperatures etc. (~/Desktop/HWBadSensors skip it). Code and rules below (please advice for changes):

Spoiler

//MARK: SMC keys validation functions
  func validateValue(for sensor: HWMonitorSensor, data: Data, dataType: DataType) -> Bool {
    let v : Double = decodeNumericValue(from: data, dataType: dataType)
    var valid : Bool = false
    switch sensor.sensorType {
    case .temperature:
      if gShowBadSensors || (v > -15 && v < 125) {
        /*
         -10 min temp + 5 to ensure no one start a pc this way.
         125 (110 °C it is enough) to ensure reading is correct
         */
        sensor.stringValue = String(format: "%.f", v)
        sensor.doubleValue = v
        valid = true
      }
    case .battery: fallthrough /* only if from the smc */
    case .hdSmartLife:          /* only if from the smc */
      var t: Int = 0
      (data as NSData).getBytes(&t, length: MemoryLayout<Int>.size)

      if gShowBadSensors || (t >= 0 && t <= 100) {
        sensor.stringValue = String(format: "%ld", t)
        sensor.doubleValue = v
        valid = true
      }
    case .voltage:
      sensor.stringValue = String(format: "%.3f", v)
      sensor.doubleValue = v
      // voltage sensors only refear to CPU and Motherboard's stuff
      // since Battery voltages are read directly from the IO Registry in this app.
      valid = gShowBadSensors || (v > -15 || v < 15)
    case .tachometer:
      sensor.stringValue = String(format: "%.0f", v)
      sensor.doubleValue = v
      valid = gShowBadSensors || (v > 0 && v <= 7000)
    case .frequencyCPU:  fallthrough
    case .frequencyGPU:  fallthrough
    case .frequencyOther:
      var MHZ: UInt = 0
      bcopy((data as NSData).bytes, &MHZ, 2)
      MHZ = swapBytes(MHZ)
      if sensor.unit == .GHz {
        MHZ = MHZ / 1000
      }
      sensor.stringValue = String(format: "%d", MHZ)
      sensor.doubleValue = Double(MHZ)
      valid = gShowBadSensors || (MHZ > 0 && MHZ < 9000) // OC record is 8794 (AMD FX-8350) on Nov 10 2012
    case .cpuPowerWatt:
      sensor.stringValue = String(format: "%.2f", v)
      sensor.doubleValue = v
      if sensor.key == SMC_IGPU_PACKAGE_WATT {
        valid = gShowBadSensors || (v >= 0 && v < 150) // 30 W max?
      } else {
        valid = gShowBadSensors || (v > 0 && v < 1000) // reached from an Intel i9-7890XE in extreme OC
      }
    case .multiplier:
      var m: UInt = 0
      bcopy((data as NSData).bytes, &m, 2)
      sensor.stringValue = String(format: "x%.f", Double(m) / 10)
      sensor.doubleValue = Double(m)
      valid = gShowBadSensors || (m > 0 && m <= 50)
    default:
      break
    }
    
    return valid
  }

 

 

Edited by vector sigma

Share this post


Link to post
Share on other sites

No, zero value is good. It means the FAN is stopped.

If the FAN not exist then drivers will not produce SMC keys F0Ac, F0ID. As well for FAN2 values F2Ac, F2ID.

 

Share this post


Link to post
Share on other sites
7 hours ago, Slice said:

zero value is good. It means the FAN is stopped

Agreed, the old code was just in this view with the difference that drivers start at boot while you can restart the app after the login. Committed the change, anyway You should do the same with the drivers since a Fan can start at 0 rpm as well.

Share this post


Link to post
Share on other sites
3 hours ago, vector sigma said:

Wants an alert window when this happens?:idea:

..maybe with a sound?

No, it is normal. My laptop started with stopped FAN until temperature increased up to 70 degree. Then FAN started.

Your latest Monitor is fine

Снимок экрана 2019-08-05 в 18.44.29.png

Share this post


Link to post
Share on other sites
1 minute ago, Slice said:

My laptop started with stopped FAN until temperature increased up to 70 degree. Then FAN started.

Because never taken into account laptop's... until now.

2 minutes ago, Slice said:

Your latest Monitor is fine

good!

Share this post


Link to post
Share on other sites

@vector sigma

HWMonitorSMC2 from r222, indications "Package IGPU" are frozen at the time of an application launch.
Earlier (the version with "GT") worked well. Please fix.

 

P.S.

I on former see two sensors "Package IGPU", from SMC keys and from IPG. I think better an settings option IPG shall switch sources.

 

 

1906235619_2019-08-0823_26_09.thumb.png.333544eb6b283c1a2b10414f44e22872.png

Share this post


Link to post
Share on other sites

I'm needing help in getting HWMonitorSMC2 to display information from my motherboard. It uses the Nuvoton NCT6797D (at 0xD451). I've also downloaded the source code (version r222) and noticed this chip is not included. Could you please add it? I've tried to add it and compile, but no luck. Do you need any other information from my motherboard?

Share this post


Link to post
Share on other sites
4 hours ago, Andrey1970 said:

HWMonitorSMC2 from r222, indications "Package IGPU" are frozen at the time of an application launch.
Earlier (the version with "GT") worked well. Please fix.

Thanks, tomorrow I'll take a look on it. 

Share this post


Link to post
Share on other sites
6 hours ago, curtistn73 said:

I'm needing help in getting HWMonitorSMC2 to display information from my motherboard. It uses the Nuvoton NCT6797D (at 0xD451). I've also downloaded the source code (version r222) and noticed this chip is not included. Could you please add it? I've tried to add it and compile, but no luck. Do you need any other information from my motherboard?

OK, I will add it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By kevin_1351
      tl;dr: VirtualSMC causes me a flood of log messages and correlated cpu spikes. FakeSMC doesn't.
       
      Hi, I have almost finalized my Huawei Matebook X Pro Opencore setup and everything is working very well besides wifi/bt ofc (which is about to change).
       
      However, I noticed how the cpu usage sometimes went up a little and when looking at the Console I could see a never-ending flood of:
      default 14:05:05.983292+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:05.982975+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:05.982996+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985932+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.985949+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:06.986134+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426574+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:39.426729+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:39.426585+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431085+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431097+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:41.431246+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433068+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:42.433227+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:42.433078+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434453+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434465+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:43.434622+0100 loginwindow clamshellStateChanged | Clamshell state changed: closed=0, shouldSleepWhenClosed=2 default 14:05:44.436155+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0 default 14:05:44.436166+0100 kernel PMRD: clamshell closed 0, disabled 0, desktopMode 0, ac 0 sleepDisabled 0  
      As you can see, multiple of these per second. Another guy with the same computer is also having this issue and posted a dsdt change to fix it. This fix didn't solve anything though
      He tried to limit the Notify call by implementing a state change requirement before calling Notify.
       
      Here is the original acpi:
      Scope (_SB) { Device (LID) { Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } ^^PCI0.GFX0.CLID = Local0 Return (Local0) } } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } Notify (LID, 0x80) // Status Change } } Which he changed to: 
      Scope (_SB) { Device (LID) { Name (_OLD, One) // assuming everything else.. the lid should start open? Name (_HID, EisaId ("PNP0C0D") /* Lid Device */) // _HID: Hardware ID Method (_LID, 0, NotSerialized) // _LID: Lid Status { Local0 = One Local0 = ^^PCI0.LPCB.EC0.RPIN (0x05, 0x06) If ((Local0 == 0x55)) { Local0 = Zero } Else { Local0 = One } Return (Local0) } } Device (PNLF) { Name (_HID, EisaId ("APP0002")) // _HID: Hardware ID Name (_CID, "backlight") // _CID: Compatible ID Name (_UID, 0x0A) // _UID: Unique ID Name (_STA, 0x0B) // _STA: Status } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0B) } } } Scope (_SB.PCI0.LPCB.EC0) { Method (_Q81, 0, NotSerialized) // _Qxx: EC Query, xx=0x00-0xFF { Local0 = ^^^^LID._LID () If ((Local0 == Zero)) { ADBG ("LID-OFF") SGOV (0x02030009, Zero) SGOV (0x02060000, Zero) } Else { ADBG ("LID-ON") SGOV (0x02030009, One) SGOV (0x02060000, One) Notify (ALSD, 0x80) // Status Change } If ((^^^^LID._OLD != Local0)) { Notify (LID, 0x80) // Status Change ^^^^LID._OLD = Local0 } } } Besides me not seeing any reason to declare _OLD in LID. The idea itself shouldn't be too bad right? Well, as I said, his fix didn't work.
       
      In fact, to prove that Method _Q81 doesn't have anything to do with the issue at all, I created a Clover/Opencore patch to change _Q81 to XQ81. This resulted in my lid not working at all of course, but the log flooding still persisted!
      So _Q81 doesn't have anything to do with the issue afaik.
       
      Now, further Google searches led me to a chinese post where he tied the issue to VirtualSMC. And indeed, by migrating to FakeSMC the issue is no more.
       
      Unfortunately, I'm very fond of VirtualSMC for various reasons. So I would very much like to keep it. If not I'd have to implement the old way of doing Battery monitoring etcetc. Which isn't very elegant and update proof as it requires DSDT patching.
       
      So, I do believe that the issue may very well be in the DSDT code, perhaps in the ambient light part. I'm not very skilled at this and just started studying the ACPI spec 3 days ago.
       
      Could someone please help me out? Thanks a lot in advance
       
       
      origin.zip
      OC.zip
    • By Slice
      Guys,
      Don't mix 6.18 and 3.41.
       
      There are three different projects for monitoring temperatures, voltages, fans speed and other hardware parameters:
      Initially it was FakeSMC with plugins for producing SMC keys for hardware parameters for different hardware. But sometimes ago Kozlek separated own version of FakeSMC and producing new set of plugins while I stay with good working version 3. So..
      1. FakeSMC v3 with Hardware Sensors3  which I still supported.
      2. FakeSMC v6 (rev1800) by Kozlek and supported by Rehabman. AFAIK both are abandoned and the project is not supported. Or may be maintained by coauthors.
      3. New VirtualSMC by vit9696 with own set of sensors kexts. It depends on Lilu.kext. The project is in active development.
      All three project have incompatible interfaces sensors<->SMC so they are incompatible with each other.
       
      There are applications for monitoring hardware parameters and they commonly depends on these projects.
      1. iStat, iStatMenu, iStatPro compatible with real Macs because they use SMC keys just like those presents in real Macs.
      2. HWMonitorSMC by Navi (initial codes from Kozlek)  used in my HWSensors3.
      3. HWMonitor by Kozlek with graphics like in IntelPowerGadget used in his HWSensors version.
      4. HWMonitorSMC2 by Vector_Sigma tends to be universal supporting all project. It also may use sensors information produces by Apple graphics and by IntelPowerGadget.
       
      Let us discuss here differences and common ideas for this projects.
       
×