Jump to content

2,079 posts in this topic

Recommended Posts

Advertisement
13 minutes ago, Andrey1970 said:

Vcore always multi=1
You shall give heavy load of the CPU to see.

Unable to get the correct data using "OC" boot. Using clover boot is the right data.

Share this post


Link to post
Share on other sites

@vector sigma

Thanks! :thumbsup_anim:

Tell me, is it difficult to add the ability to sort sensors? To install in the correct order.

Example:

CPUVCORE

+12V

+5V

3VCC

3VSB

VIN0

....

VIN8

Знімок екрана 2020-01-22 о 20.23.30.png

Share this post


Link to post
Share on other sites

Ideally, HWSensors could be configured (e.g. by plist) to only show values of interest.

So I can select what information I can display in what order.

As an example... most fans are not active or relevant, so it makes a lot of sense to only pick the relevant ones.

 

Share this post


Link to post
Share on other sites
9 hours ago, tyufhl said:

@vector sigma hi, after the launch of DarwinDumper / CPU 2077731448_2020-01-2322_04_32.png.7c4ab1ff3615431c17ec53f828b3f261.pngsuch a picture 

DarwinDumper contains Pike R. Alpha's' AppleIntelInfo.kext v2.9. which is very wrong and dangerous.

Exclude it from

/DarwinDumper.app/Contents/Resources/public/drivers/AppleIntelInfo.kext

Move to trash!

 

Share this post


Link to post
Share on other sites
On 1/22/2020 at 7:18 AM, jinbingmao said:

 

On 1/22/2020 at 7:26 AM, Andrey1970 said:

Thanks, but wait a moment. If we are going to create a database, we need rules naming things:

 

1)

SYS_FAN2 or Sys Fan 2?

What is CPU_OPT?

What to do with unconnected sensors? My NTC sensor has more fans than the motherboard have, so I'm going to skip the sensor:

2129907392_Schermata2020-01-24alle12_58_50.png.60ee7df4c521cb3c273ab4e10c508d40.png

Is that the case for your CPU_OPT? I mean, if the LPC chip has has an unused line (no connector on the motherboard), this must be skipped.... my 2 cents.

 

2) if we have a convention for naming things, and we follow it, the app can translate SYS_FAN2 (or Sys fan 2) into your native language. 

 

What do you think?

 

On 1/22/2020 at 7:33 PM, ctich said:

@vector sigma

Thanks! :thumbsup_anim:

Tell me, is it difficult to add the ability to sort sensors? To install in the correct order.

Example:

CPUVCORE

+12V

+5V

3VCC

3VSB

VIN0

....

VIN8

 

It can be done at app initialization, in alphabetical order, what ever will be. I'll take a look on it when I have more time with out priority.

Share this post


Link to post
Share on other sites
On 1/23/2020 at 1:03 AM, Mike Ranger said:

Ideally, HWSensors could be configured (e.g. by plist) to only show values of interest.

So I can select what information I can display in what order.

As an example... most fans are not active or relevant, so it makes a lot of sense to only pick the relevant ones.

 

That is why I say we need rules. Once a configurations is made, that configuration must contains all the fans that a motherboard can really have: you cannot have the chassys Fan for your own purpose (the noise) but the configuration must include it because this will help other users.

 

Later I'll add the possibility to load a config from the nvram (a path to a plist), so anyone can customize even more names or skip unused sensors. This can be usefull when you doesn't have Fans... but Pumps.

 

Share this post


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

 

Thanks, but wait a moment. If we are going to create a database, we need rules naming things:

 

1)

SYS_FAN2 or Sys Fan 2?

What is CPU_OPT?

What to do with unconnected sensors? My NTC sensor has more fans than the motherboard have, so I'm going to skip the sensor:

2129907392_Schermata2020-01-24alle12_58_50.png.60ee7df4c521cb3c273ab4e10c508d40.png

Is that the case for your CPU_OPT? I mean, if the LPC chip has has an unused line (no connector on the motherboard), this must be skipped.... my 2 cents.

 

2) if we have a convention for naming things, and we follow it, the app can translate SYS_FAN2 (or Sys fan 2) into your native language. 

 

What do you think?

 

 

I wrote as on the motherboard. CPU_OPT it for cpu pump or cpu fan2.

Parameter skip is good idea.

I offer such names:

System Fan Х
CPU Fan Х

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