Jump to content

2,085 posts in this topic

Recommended Posts

5 hours ago, Andrey1970 said:

Already there for a long time, just not shown:

// Power (Watts)
#define KEY_CPU_PACKAGE_CORE                    "PCPC" // SNB
#define KEY_CPU_PACKAGE_GFX                     "PCPG" // SNB
#define KEY_CPU_PACKAGE_TOTAL                   "PCPT" // SNB

Try this: HWMonitorSMC2.app_IPG_beta4.zip, you should able to see those keys under "CPU Power", but "-" for no sign of life or a number that ends with 'W' (Watt) when working.

2 hours ago, iCanaro said:

 

@vector sigma la password è il tuo nome

MacProZ97_1070.ioreg.zip

Got it, but for that I'll need more time.. saturday.

Share this post


Link to post
Share on other sites
Advertisement
21 hours ago, Extreme™ said:

 

Thank you for new beta Vector Sigma

 

I tested it and i  found that the GPU UTILIZATION value is high even though the GPU is not under stress. As seen in the first screen that i attach.

Furthermore, it appears that the processor power value corresponds to the DRAM of IPG (second screen attached): is correct?

screenshot_208.jpg

screenshot_207.jpg

Sorry but DRAM make no sense to me, and the key name returned by the framenwork say other, it is a question for Intel.

The "GPU Utilization" comes from this function:

bool GetGPUUtilization(float *util);

has float precision (like 12,85% ??) and the true value is just what you see +100 (as I've subtract it): maybe isn't a percentage even if looks like. Saturday I'll take a better look

Share this post


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

Already there for a long time, just not shown:


// Power (Watts)
#define KEY_CPU_PACKAGE_CORE                    "PCPC" // SNB
#define KEY_CPU_PACKAGE_GFX                     "PCPG" // SNB
#define KEY_CPU_PACKAGE_TOTAL                   "PCPT" // SNB

Try this: HWMonitorSMC2.app_IPG_beta4.zip, you should able to see those keys under "CPU Power", but "-" for no sign of life or a number that ends with 'W' (Watt) when working.

Got it, but for that I'll need more time.. saturday.

hack 4 ora con l'ultimo beta 4 di HWMonitorSMC viene visualizzata la nvidia 970M, ottimo! con le precedenti versioni questo non avveniva

 

hack 4 now with the last beta 4 of HWMonitorSMC the nvidia 970M is displayed, excellent! with previous versions this did not happen

Schermata 2018-10-10 alle 22.04.34.png

Share this post


Link to post
Share on other sites
26 minutes ago, iCanaro said:

hack 4 ora con l'ultimo beta 4 di HWMonitorSMC viene visualizzata la nvidia 970M, ottimo! con le precedenti versioni questo non avveniva

 


hack 4 now with the last beta 4 of HWMonitorSMC the nvidia 970M is displayed, excellent! with previous versions this did not happen

Schermata 2018-10-10 alle 22.04.34.png

Oh, only now I see that 'CPU Power' for you it is working, less the CPU Package Total... (keys Andrey1970 is looking for :wink_anim:)

and your GFX just it consumes like the oven in my house:blink:

Edited by vector sigma
typo

Share this post


Link to post
Share on other sites

@vector sigma mi serve molta energia per alimentare genesys e dare via al giorno del giudizio :D battute a parte, forse è presente qualche errore con le virgole

 

I need a lot of energy to feed genesys and give away the day of judgment :D beats apart, maybe there are some errors with the commas

Share this post


Link to post
Share on other sites
9 minutes ago, iCanaro said:

@vector sigma mi serve molta energia per alimentare genesys e dare via al giorno del giudizio :D battute a parte, forse è presente qualche errore con le virgole

 

I need a lot of energy to feed genesys and give away the day of judgment :D beats apart, maybe there are some errors with the commas

I know ^_^. I think they are just wrong, unless they are milliwatts and no Watts

HWSensors-3

// Power (Watts)
#define KEY_CPU_PACKAGE_CORE                    "PCPC" // SNB
#define KEY_CPU_PACKAGE_GFX                     "PCPG" // SNB
#define KEY_CPU_PACKAGE_TOTAL                   "PCPT" // SNB

VirtualSMC

[PCPC] type [sp78] 73703738 len [ 2] attr [C0] -> ATTR_WRITE|ATTR_READ
CPU package core power (PECI) in watts
This is a modern key present in e.g. MacBookPro12,1. Has many types.

...

Edited by vector sigma

Share this post


Link to post
Share on other sites

..an SMC dump will clear some doubts.

     case CPUPowerGroup: {
        unsigned int W = 0;
        bcopy([value bytes], &W, 2);
        W = [HWMonitorSensor swapBytes:W];
        return [[NSString alloc] initWithFormat:@"%uW",W];
      }

 

maybe the swap is unneeded.

Share this post


Link to post
Share on other sites

hello thank you for your hard work.

Intel HD630 indicators will not work out(you have tried before)?

1653725641_00_04_29.thumb.png.ece48b9ff6c5c493bda780011af04927.png

 

Share this post


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

Intel HD630 indicators will not work out(you have tried before)?

I can see it is 0 in both applications 

1 hour ago, Andrey1970 said:

The comma after two characters on the right is required.

Can be, but if you show me an smc dump I'll be happy.

Share this post


Link to post
Share on other sites
2 minutes ago, thenightflyer said:

I don't know why but not all cores are shown using your app...i've i9 7980XE and only 16 cores instead of 18 are shown....why?

 

Try SMCProcessor :wink_anim:

18 hours ago, Andrey1970 said:

My smc dump. 

smcdump.zip

Thanks! very usefull! 

58 minutes ago, ctich said:

Values taken from IntelPowerGadget.framework, but in different times.

21 hours ago, Andrey1970 said:

CPU Power is uprated approximately by 100 times.

The comma after two characters on the right is required.

Now is for sure, thanks.

Share this post


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

Try SMCProcessor :wink_anim:

Thanks! very usefull! 

Values taken from IntelPowerGadget.framework, but in different times.

Now is for sure, thanks.

SMCProcessor is already loaded....

Share this post


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

SMCProcessor is already loaded....

Sorry no idea then. I'm looking for someone who will help me telling where the error is (if there is). In the mean time can you show me a picture of other apps that show you all the sensors? ..I can take a look then on the source code... (or even decompiling the binary if not published). Thanks.

Share this post


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

Sorry no idea then. I'm looking for someone who will help me telling where the error is (if there is). In the mean time can you show me a picture of other apps that show you all the sensors? ..I can take a look then on the source code... (or even decompiling the binary if not published). Thanks.

The strange thing is that with an old version of the app i saw all cpu cores....i cannot tell you exactly what version because i deleted when i upgraded and the old version is no more available.

Share this post


Link to post
Share on other sites
26 minutes ago, thenightflyer said:

The strange thing is that with an old version of the app i saw all cpu cores....i cannot tell you exactly what version because i deleted when i upgraded and the old version is no more available.

Can you gime an SMC dump? I need datas, but no one provide it almost never Lol

Edited by vector sigma

Share this post


Link to post
Share on other sites

my bad sorry..

 have had another app open and this one produce a correct number with strange core names but right count

for now for me it is a best solution using VirtualSMC ad SMCProcessor

 

Edited by fabiosun

Share this post


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

@thenightflyer, please try that: HWMonitorSMC2.app_beta5.zip (a doubt that this is cause by the localization system), let me know

here you can see also other results with HWsensorSMC2 old and new release with Virtulasmc on the left

Fakesmc on right part of my image

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