Jump to content

2,087 posts in this topic

Recommended Posts

Advertisement
On 10/3/2019 at 3:08 AM, vector sigma said:

Big bug in Intel Power Gadget 3.6.1, first try return 0 randomly. Restart multiple time (joke) or use HWMonitorSMC2 v2.5.0


Nice,, thank you very much :D

 

 image.thumb.png.a407a4fdc3fa294cd7679139a0b3c578.png

Share this post


Link to post
Share on other sites
On 10/2/2019 at 10:08 PM, vector sigma said:

Big bug in Intel Power Gadget 3.6.1, first try return 0 randomly. Restart multiple time (joke) or use HWMonitorSMC2 v2.5.0

 

Hi @vector sigma thanks for your feedback!

Please, just to understand your post;

a) Your link to HWMonitorSMC2 v2.5.0 is an official repository that we should look from now onwards? Is this maintained by you?

b) Do you recommend Intel Power Gadget 3.6.1 to be installed or not, eventually?

Unless you mention that Intel Power Gadget 3.6.1 only works with this new HWMonitorSMC2 v2.5.0 ?

Thanks for confirming! Cheers.

Share this post


Link to post
Share on other sites

Hmm, I just noticed I don't get fan RPM for my exhaust fan... Known bug? FANIN0 is intake and FANIN1 is CPU. FANIN2-4 don't show up and if I increase the FANINLIMIT past the value of 5, I don't get any fan info so the maximum value seems to be 5 / FANIN4. 

Share this post


Link to post
Share on other sites
On 10/6/2019 at 5:01 PM, MacKonsti said:

Hi @vector sigma thanks for your feedback!

Please, just to understand your post;

a) Your link to HWMonitorSMC2 v2.5.0 is an official repository that we should look from now onwards? Is this maintained by you?

b) Do you recommend Intel Power Gadget 3.6.1 to be installed or not, eventually?

Unless you mention that Intel Power Gadget 3.6.1 only works with this new HWMonitorSMC2 v2.5.0 ?

Thanks for confirming! Cheers.

a) yes

b) no, install any versions of Intel Power Gadget you like starting from 3.5 as previous ones was never tested by me.

Share this post


Link to post
Share on other sites
On 10/11/2019 at 4:31 PM, unixb0y said:

Hmm, I just noticed I don't get fan RPM for my exhaust fan... Known bug? FANIN0 is intake and FANIN1 is CPU. FANIN2-4 don't show up and if I increase the FANINLIMIT past the value of 5, I don't get any fan info so the maximum value seems to be 5 / FANIN4. 

Difficult to say w/o know at least what chip and what plugin are you using. Any way the index of the fan must respect the max number of registers availabe for your chips. The chip is always the same but OEM vendors can decide to attach fans just where they like.

Share this post


Link to post
Share on other sites

Hi - is it possible on the AMD X570 platform with Ryzen 3900x to expose the temperature sensors and fans in order to control fan speeds? My motherboard (Aorus x570 i pro Wifi) apparently has an ITE chip.

Share this post


Link to post
Share on other sites
2 hours ago, Murmur2k said:

Hi - is it possible on the AMD X570 platform with Ryzen 3900x to expose the temperature sensors and fans in order to control fan speeds? My motherboard (Aorus x570 i pro Wifi) apparently has an ITE chip.

ITE chips are supported in general. See kernel log about loading appropriate kexts.

Share this post


Link to post
Share on other sites
On 10/19/2019 at 8:08 PM, Slice said:

ITE chips are supported in general. See kernel log about loading appropriate kexts.

 

Sorry I'm a beginner on this front - so I need to look at the log to see where sensors fail to load a kext? Is it not just a case of running your installed selecting the chipset etc? Also I see in 2014 you mentioned no fan control - is that still the case? Appreciate any help.. many thanks

Edited by Murmur2k
Additional question

Share this post


Link to post
Share on other sites

Hi @Slice have you eventually officially included in the latest code/repo any support/detection for ITE chipset ID 0x8987 (thus possibly detecting the IT8987E-VG per Intel's motherboard specs) or should we use your test-kext you kindly posted some time ago?

 

Otherwise we need to compile the kext as on Sourceforge there's still HWSensors-3_r240.dmg available, yes?

 

Hi @Murmur2k I am also having troubles detecting any trace at all, of my fans or Super I/O chipset, it's like the BIOS or the ACPI code is totally hiding its existence, no direct evidence of it on my Mojave set-up. Check the posts by @Slice here and here that also advised me on what type of logs to check.

 

Can anyone kindly share a latest-compiled working ITE kext ("Release"), please? I would be grateful ! Thank you.

Share this post


Link to post
Share on other sites

Hi @Slice I'm on amd with the configuration in my signature using your fakesmc + sensors in version 3.5.3, my motherboard have the sensor iteit8665e, with the kext iteit87x hwmonitor gave me only the value of temperature and is stuck on 0°C, could you please help me to have working temperature and frequency indication of the cpu ?

 

Thanks for your work

CLOVER.zip

Share this post


Link to post
Share on other sites
12 hours ago, lore3333 said:

Hi @Slice I'm on amd with the configuration in my signature using your fakesmc + sensors in version 3.5.3, my motherboard have the sensor iteit8665e, with the kext iteit87x hwmonitor gave me only the value of temperature and is stuck on 0°C, could you please help me to have working temperature and frequency indication of the cpu ?

 

Thanks for your work

CLOVER.zip

I am sorry but I have no datasheets on AMD Ryzen with information what register number corresponds to temperature reading as well as what MSR or CPUID may reflect frequency.

Share this post


Link to post
Share on other sites
I am sorry but I have no datasheets on AMD Ryzen with information what register number corresponds to temperature reading as well as what MSR or CPUID may reflect frequency.
Well in that case i hope in the future support for amd will be Better, again thanks a lot for all the work you do for the community

Share this post


Link to post
Share on other sites
On 11/8/2019 at 5:42 AM, Slice said:

@vector sigma

Why I can't stretch the window?

Снимок экрана 2019-11-08 в 7.38.09.png

Easy: lock the lock. Or detach it, resize and then reattach it. Since the window is detachable the lock avoid the detach, but also allow the resize while is appended. (dragging it can have one or another action)

Edited by vector sigma

Share this post


Link to post
Share on other sites
Quote

 

Hi @Slice many wishes for a great start at your new home!

Please, two questions. Does the new release r241 include the fix by @vector sigma for HWMonitorSMC2 due to Intel Power Gadget's new way of reporting CPU frequencies?

Also, does this build include the ITE chipset ID=0x8987 that should cover both types of chipset IT8987 and IT8987E ? You may recall that my NUC's datasheet from Intel mentions ITE IT8987E-VG.

Many thanks!

Share this post


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

 

Hi @Slice many wishes for a great start at your new home!

Please, two questions. Does the new release r241 include the fix by @vector sigma for HWMonitorSMC2 due to Intel Power Gadget's new way of reporting CPU frequencies?

Also, does this build include the ITE chipset ID=0x8987 that should cover both types of chipset IT8987 and IT8987E ? You may recall that my NUC's datasheet from Intel mentions ITE IT8987E-VG.

Many thanks!

1. New HWMonitorSMC2 is here https://github.com/CloverHackyColor/HWMonitorSMC2

2. ID=0x8987 is already supported. I still wait for your kernel.log

Share this post


Link to post
Share on other sites
2 hours ago, holyfield said:

Please note there is a bug on showing IGPU memory size

 

Is taken from mac OS

On 12/13/2019 at 1:31 PM, holyfield said:

How do I get Radeon VII temp readings?

 

The attached solution gives temp readings but I don't have fan speeds etc with this solution.

  • Gigabyte Z390 Designare
  • Radeon VII

 

RadeonVII_FakeSMC_Package.zip

no-amd-radeon-vii-temp.jpg

same. Taken form mac OS.

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