Jump to content

2,083 posts in this topic

Recommended Posts

1 hour ago, vector sigma said:

mine looks good:

 

Which doesn't mean, that there is no bug somewhere.

Edited by holyfield

Share this post


Link to post
Share on other sites
Advertisement
1 hour ago, vector sigma said:

IO Accelerator->PerformanceStatistics

 

What exactly is generating these values on macOS (Catalina)? 

  • SMIMonitor.kext
  • ITEIT87x.kext
  • IntelCPUMonitor.kext
  • FakeSMC.kext
  • ACPIMonitor.kext

Share this post


Link to post
Share on other sites
22 minutes ago, holyfield said:

 

Which doesn't mean, that there is no bug somewhere.

I cannot be sure of that honestly, but:

14 minutes ago, holyfield said:

 

What exactly is generating these values on macOS (Catalina)? 

  • SMIMonitor.kext
  • ITEIT87x.kext
  • IntelCPUMonitor.kext
  • FakeSMC.kext
  • ACPIMonitor.kext

none of them. just mac OS vanilla drivers. Values published by the drivers .... has no calculations that can be misscalculated, it is just a read.

 

I'll be happy to see a ioreg from your system.

Edited by vector sigma

Share this post


Link to post
Share on other sites
On 12/15/2019 at 6:27 PM, vector sigma said:

I cannot be sure of that honestly, but:

none of them. just mac OS vanilla drivers. Values published by the drivers .... has no calculations that can be misscalculated, it is just a read.

 

I'll be happy to see a ioreg from your system.

 

Thank you vector sigma!

 

After digging deeper we figured out that original iMac (iMac19.1) has 4GB of shared memory (with 8GB of RAM). The known argument that maOS can have only up to 2GB of shared memory is an invalid myth. Value ~7GB shown in my system is actually correct has I have installed 64GB of memory.

 

 

Share this post


Link to post
Share on other sites
28 minutes ago, holyfield said:

After digging deeper we figured out that original iMac (iMac19.1) has 4GB

Yep, 4.29 GB in the vanilla ioreg We saw. Apple also state that memory can be dynamically allocated, so this also depend by the workload. However this appear to be true for newer IGPU than my HD 4000. Another things that we must to say, is that all this get measured by the Open GL/Metal drivers shipped with the OS.

Edited by vector sigma

Share this post


Link to post
Share on other sites

Hi everyone! Happy 2020.

I found out that recently Intel Power Gadget updated to v3.6.2, in the usual Intel's page.

Has anyone noticed any incompatibilities or hiccups?

There is no changelog posted.

I have just updated to this version and with HWMonitorSMC2 v2.5.0 it seems to work just fine.

Thanks

Edited by MacKonsti

Share this post


Link to post
Share on other sites
23 hours ago, MacKonsti said:

Hi everyone! Happy 2020.

I found out that recently Intel Power Gadget updated to v3.6.2, in the usual Intel's page.

Has anyone noticed any incompatibilities or hiccups?

There is no changelog posted.

I have just updated to this version and with HWMonitorSMC2 v2.5.0 it seems to work just fine.

Thanks

Yes, hwmonitorsmc2 v2.5.0, which shows the data perfectly all the time. Thank you very good vector Sigma!

Edited by jinbingmao

Share this post


Link to post
Share on other sites

Hi everyone!

 

I've got this line below with FakeSMC v3.5.3 (no plugins installed) on macOS 10.15.3 Beta 2

 

(AppleSMCLMU) AppleLMUController::smcReadKey Error: received error 0x84 when reading key 'MSLD'

 

Share this post


Link to post
Share on other sites
23 minutes ago, Matgen84 said:

Hi everyone!

 

I've got this line below with FakeSMC v3.5.3 (no plugins installed) on macOS 10.15.3 Beta 2

 


(AppleSMCLMU) AppleLMUController::smcReadKey Error: received error 0x84 when reading key 'MSLD'

 

No plugins - no MSLD.

The key can be produced by VoodooBatterySMC or manually by ACPImonitor or just add constant into FakeSMC Info.plist like LID is always opened.

Share this post


Link to post
Share on other sites
On 1/16/2020 at 7:06 PM, Andres ZeroCross said:

@vector sigma some sensor in CPU Section is missing with Intel Power Gadget 3.7.0. Maybe need new update for HWMonitorSMC2 :)
Thanks you

Test it: . This version doesn't like IntelPowerGadget.app to be opened at same time, and vice versa, because the code is set to use the PMU functionality provided:

 

/*@function PG_UsePMU
* @abstract Enable or disable the use of the Performance Monitoring Unit (PMU) by the Power Gadget library.
* @discussion Enabling the use of the PMU by the Power Gadget Library allows for ReadSample to collect higher accuracy data with lower overhead; however, this also prevents the use of the PMU by other software. Disabling the use of the PMU by the Power Gadget library will enable compatibility with other software that uses the PMU.
* @param iPackage Index of Intel processor package to query. Must be less than the value from PG_GetNumPackages.
* @param flag Set to true to enable the use of the PMU, and false to disable.
* @result True on success, false on failure. */
bool PG_UsePMU(int iPackage, bool flag);

P.S. tomorrow I'll add sensors from VirtualSMC but now I need to go to bed because I've the flu:help:

 

EDIT

bugs maybe present as I've just finished writing the code.

Edited by vector sigma
Beta app removed

Share this post


Link to post
Share on other sites
5 minutes ago, vector sigma said:

 

Pay attention to rest and take good care of yourself. Thank you

Edited by jinbingmao

Share this post


Link to post
Share on other sites
1 hour ago, vector sigma said:

Test it: HWMonitorSMC2.app_2.5.1_IPG3.7.zip. This version doesn't like IntelPowerGadget.app to be opened at same time, and vice versa, because the code is set to use the PMU functionality provided:

 


/*@function PG_UsePMU
* @abstract Enable or disable the use of the Performance Monitoring Unit (PMU) by the Power Gadget library.
* @discussion Enabling the use of the PMU by the Power Gadget Library allows for ReadSample to collect higher accuracy data with lower overhead; however, this also prevents the use of the PMU by other software. Disabling the use of the PMU by the Power Gadget library will enable compatibility with other software that uses the PMU.
* @param iPackage Index of Intel processor package to query. Must be less than the value from PG_GetNumPackages.
* @param flag Set to true to enable the use of the PMU, and false to disable.
* @result True on success, false on failure. */
bool PG_UsePMU(int iPackage, bool flag);

P.S. tomorrow I'll add sensors from VirtualSMC but now I need to go to bed because I've the flu:help:

 

EDIT

bugs maybe present as I've just finished writing the code.


It's look better

 image.thumb.png.79c2ae01a9ef4939020e639c668c254e.png

Share this post


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

Test it: HWMonitorSMC2.app_2.5.1_IPG3.7.zip. This version doesn't like IntelPowerGadget.app to be opened at same time, and vice versa, because the code is set to use the PMU functionality provided

P.S. tomorrow I'll add sensors from VirtualSMC but now I need to go to bed because I've the flu:help:

EDIT

bugs maybe present as I've just finished writing the code.

 

Hope you are feeling better @vector sigma!

I too, confirm that using IPG v3.7.0 with 2.5.1beta on Mojave latest, the readings are back especially the cores now I see 8 (4x2 threads) instead of just the cores.

I run IPG all the time and seems 2.5.1 shared here, works well with both open and in parallel.

When I quit IPG 3.7.0, I get no frequency readings at all in HWMonitorSMC2.

Looking forward to the final release. Thank you again.

Edited by MacKonsti

Share this post


Link to post
Share on other sites
On 1/16/2020 at 3:53 PM, Slice said:

No plugins - no MSLD.

The key can be produced by VoodooBatterySMC or manually by ACPImonitor or just add constant into FakeSMC Info.plist like LID is always opened.

 

Thanks.

 

@Slice I don't understand why this error from Catalina:

 

(AppleSMCLMU) AppleLMUController::smcReadKey Error: received error 0x84 when reading key 'MSLD'

Because I've a Desktop using Imac19,1 SMBIOS, not a Laptop.

Share this post


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

Test it: HWMonitorSMC2.app_2.5.1_IPG3.7.zip. This version doesn't like IntelPowerGadget.app to be opened at same time, and vice versa, because the code is set to use the PMU functionality provided:...

Hm... If I start and stop IGP, the HWMonitorSMC2 shows me the Temp&Freq of CPU equal 0. I don't use Clover&Fake - OC and VSMC only.

Share this post


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

Sorry, I don't saw/understood. Can you say again please?

 

23 hours ago, vector sigma said:

Test it: HWMonitorSMC2.app_2.5.1_IPG3.7.zip. This version doesn't like IntelPowerGadget.app to be opened at same time, and vice versa, because the code is set to use the PMU functionality provided:

 


/*@function PG_UsePMU
* @abstract Enable or disable the use of the Performance Monitoring Unit (PMU) by the Power Gadget library.
* @discussion Enabling the use of the PMU by the Power Gadget Library allows for ReadSample to collect higher accuracy data with lower overhead; however, this also prevents the use of the PMU by other software. Disabling the use of the PMU by the Power Gadget library will enable compatibility with other software that uses the PMU.
* @param iPackage Index of Intel processor package to query. Must be less than the value from PG_GetNumPackages.
* @param flag Set to true to enable the use of the PMU, and false to disable.
* @result True on success, false on failure. */
bool PG_UsePMU(int iPackage, bool flag);

P.S. tomorrow I'll add sensors from VirtualSMC but now I need to go to bed because I've the flu:help:

 

EDIT

bugs maybe present as I've just finished writing the code.

 

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.
       
×