Jump to content

2,087 posts in this topic

Recommended Posts

Take, please, the version for test

attachicon.gifGeforceSensor.kext.zip

Thank you, that got it running.

But it only works with provided FakeSMC, which brings number of other issues, particularly

  • Macs Fan Control can't see CPU temp
  • iStat Cpu Package Multiplier goes crazy

post-971287-0-83155700-1514394513_thumb.pngpost-971287-0-17612100-1514394529_thumb.png

post-971287-0-61764500-1514394539_thumb.pngpost-971287-0-67932300-1514394549_thumb.png

Share this post


Link to post
Share on other sites
Advertisement

@DMMA

Take, please, the version for test

attachicon.gifGeforceSensor.kext.zip

 

@vector sigma

Thanks, and I wait you committed the changes.

Done, sf is a pain... often you cannot connect to it..

 

Look at "IOBatteryStatus.m" in getBatteryAmperageFrom and getBatteryVoltageFrom:

if ([IOPMPowerSource objectForKey:@kIOPMPSBatteryInstalledKey] != nil &&
        [[IOPMPowerSource objectForKey:@kIOPMPSBatteryInstalledKey] boolValue]) {
.....

to return zero, looks like your driver publish that "kIOPMPSBatteryInstalledKey" = true

even if a battery is not present, otherwise should return "BAT0_NOT_FOUND" (i.e. -1). Is that possible?

Anyway retry with new changes, and me I'm going to try with VoodooBattery to see if that happen.

 

EDIT

 

ok, Clearly does not return zero, is just empty in your picture. Need to figure out why here does not do the same.

Share this post


Link to post
Share on other sites

@Slice, the bug is that VoodooBatterSMC.kext says there is a battery even if does not exist:

BatteryPowerSource[battery]->setBatteryInstalled(true);

this should be conditional, but can we also assume no one will install VoodooBatterySMC.kext on a Desktop pc Lol. Try w/o it.

On a laptop without battery is another story, we need to check if the battery exist for true. Searching for a workaround...

 

EDIT

Fixed, check r84

 

EDIT 2

app r84 attached.

 

EDIT 3
@Slice you should increase the app version... I've found the short version is 1.3.2 while the bundle version is 732 :surprised:

HWMonitorSMC.app_r84.zip

Edited by vector sigma

Share this post


Link to post
Share on other sites

Thank you, that got it running.

But it only works with provided FakeSMC, which brings number of other issues, particularly

  • Macs Fan Control can't see CPU temp
  • iStat Cpu Package Multiplier goes crazy

attachicon.gifMacs Fan Control - before.pngattachicon.gifMacs Fan Control - after.png

attachicon.gifiStat - before.pngattachicon.gifiStat - after.png

It is your choice what to use.

Share this post


Link to post
Share on other sites

@Slice, the bug is that VoodooBatterSMC.kext says there is a battery even if does not exist:

BatteryPowerSource[battery]->setBatteryInstalled(true);

this should be conditional, but can we also assume no one will install VoodooBatterySMC.kext on a Desktop pc Lol. Try w/o it.

On a laptop without battery is another story, we need to check if the battery exist for true. Searching for a workaround...

 

EDIT

Fixed, check r84

 

EDIT 2

app r84 attached.

 

EDIT 3

@Slice you should increase the app version... I've found the short version is 1.3.2 while the bundle version is 732 :surprised:

You forgot to send temperature_small_dark.png. I did this.

And it looks better

Снимок экрана 2017-12-28 в 20.33.04.png

Share this post


Link to post
Share on other sites

bad copy/paste from a temporary project inside my Desktop, anyway was white like your. Yeah, so in dark mode is even better:

post-2078499-0-04553900-1514488997.pngpost-2078499-0-40364800-1514489006_thumb.png

 

I think is possible to remove also this:

post-2078499-0-99653900-1514485800.png

if no other batteries of any kind are found. 

 

For tens of CPU do you like to regroup them into a sub menu like the following?

 

CPU 0

CPU 1

CPU 2

CPU 3

Other CPU ➪

                        CPU 4

                        CPU 5

                        CPU 6

                        CPU 7

                        etc..

Share this post


Link to post
Share on other sites

Good idea!

 

Ok, had to hack (sub-class) something in the Cocoa framenfork , now I'll start to elaborate a way to do that in a simple way. Just a question, is there any reason why there's a limit of 0xA enumerating CPUs? If I'm not mistaken there is a CPU with 22 cores out there  and mobos with more then one CPU ha ha. Let me know

Share this post


Link to post
Share on other sites

Yep, also new 2066 7980xe extreme (18 cores+18 threads)

and mine 2696 v4 (22 cores/44threads)

Ok, had to hack (sub-class) something in the Cocoa framenfork , now I'll start to elaborate a way to do that in a simple way. Just a question, is there any reason why there's a limit of 0xA enumerating CPUs? If I'm not mistaken there is a CPU with 22 cores out there  and mobos with more then one CPU ha ha. Let me know

 

post-468967-0-14347300-1514829172_thumb.png

Share this post


Link to post
Share on other sites

Ok, looks good (29 core? ha ha), just need to be grouped, Frequencies as well (also the numeration must be decimal instead of hexadecimal)

Grazie (ma ti ci vuole uno schermo a 50 pollici :hysterical: ). Ok need a sub menu.

 

Anyone else with less cpu and anyway > 4?

Share this post


Link to post
Share on other sites

beh basta un monitor 4k..e poi un buon coder potrebbe mettere delle toolbar scrolling bar per sezione!  :)

 

Translation

 

No it is enough a 4k monitor..other things are a joke! :-)

Share this post


Link to post
Share on other sites

so no scrolling bar per section for "poor" user with 44 cores or more? :-)))

thank you for your effort

 

haha nope, I mean the app will show native language detected from the OS  ;)

Share this post


Link to post
Share on other sites

It's called NSScrollView and can contain different kind of object (Safari in that case contains a WebKitView). Unfurtunately this require everythings to be redone from scratch and honestly, my time is running out... soon at job again.

Share this post


Link to post
Share on other sites

Guys tell me, do you want to see info for only phisycal cpu, I'm wrong? Otherwise doesn't make sense to me... 

Attached a tiny command line I made, double click on it:

 

name:             Intel® Core i5-3210M CPU @ 2.50GHz

phisycal core n.: 2

logical  core n.: 4

active   core n.: 4

 

I'm referring to blue line

 

PS What I want to do is to keep HWMonitor auto-detect number of cpu and limit it to that, using this code.

cpuinfo.zip

Share this post


Link to post
Share on other sites

Mon Jan  1 23:06:26 on console

 

cpuinfo 

 

name  Intel® Xeon® CPU W5590  @ 3.33GHz

 

phisycal core n.: 4

 

logical  core n.: 16

 

active   core n.: 16   :thumbsup_anim: 

 

 

 

 

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

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