Jump to content

2,079 posts in this topic

Recommended Posts

I have similar probs.

 

Can it be that the FakeSMC sensors can only loaded together with Fakesmc in the Clover / kext? 

I use IntelCPU with success (its in Clover/kext together with Fakesmc)

 

BUT, if i try to sudo kextload any of (for same Fakesmc version!!!) the sensors -like LPC, GPU, ...  i always get that kextload error.

PS: I try to kextload the .kext from desktop (already set chown -R  root:wheel for that.

 

Sometimes it is better, for only check something, not to use the sensors all time and kextload them.

 

Or did we download some wrong "set" of fakesmc / sensors?

Thanks for the reply

 

I tried putting them in SLE - they loaded fine, but I still do not see any CPU info in HWsensors

One last question, here is my AIDA64 sensors - which kext is for this, seems like texas instruments

 

post-1908018-0-15140300-1511629587_thumb.jpg

 

 

Share this post


Link to post
Share on other sites
Advertisement

The error 

means you use wrong FakeSMC.

Take another one from HWSensors3 project.

I did, but also problem with dependencies. DL from the HWSensors Site: HWSensors3v51.dmg (latest shown in Files there)

 

kextstat :   27   ...      org.netkas.FakeSMC (3.5.0) 8F36EF78-E2BD-3B4F-AB1A-8545F12F247B <11 7 5 4 3>

 

kextutil -v /Users/andreasm/Downloads/RadeonMonitor.kext 

Defaulting to kernel file '/System/Library/Kernels/kernel'
/Users/andreasm/Downloads/RadeonMonitor.kext - dependency 'org.netkas.FakeSMC' not found.
/Users/andreasm/Downloads/RadeonMonitor.kext - dependency 'org.netkas.FakeSMC' not found.
/Users/andreasm/Downloads/RadeonMonitor.kext - dependency 'org.netkas.FakeSMC' not found.
Diagnostics for /Users/andreasm/Downloads/RadeonMonitor.kext:
Dependency Resolution Failures: 
    No kexts found for these libraries: 
        org.netkas.FakeSMC

Share this post


Link to post
Share on other sites

The error 

means you use wrong FakeSMC.

Take another one from HWSensors3 project.

If I put the FakeSMC and IntelCPU kexts into SLE, then both load without that error:

kextstat -l | egrep -v "com.apple"
   21    1 0xffffff7f8265f000 0xd000     0xd000     org.netkas.FakeSMC (3.5.0) A63F6CAD-05B3-335C-8084-9D034A5E7F83 <11 7 5 4 3>

 

   22    0 0xffffff7f8266c000 0x6000     0x6000     org.slice.IntelCPUMonitor (1.2.0) 306E344D-630E-39CC-B0E7-A0F51C3E8461 <21 7 5 4 3>
 
In Clover I put CPU Type =0x0a05 and FakeCPUID as 0x0506E4 otherwise I can't boot - does this cause any issue ?
 

Attached is a new DarwinDumper with both in SLE

 

Also in post 404, I put a screen shot of AIDA64 sensor, which kext does this chipset belong to ?

 

Thanks !

DarwinDumper_iMac17,1_High Sierra_17B48.zip

Share this post


Link to post
Share on other sites

Interesting!

Is it possible that FakeSMC must be in /S/L/E if some of the Sensor.kext wanted to be loaded later (after boot) by sudo kextload?

Can you try to leave your FakeSMC in /S/L/E but remove IntelCPUMonitor.kext from /S/L/E,

reboot after kernel cache got rebuild and then try again sudo kextload IntelCPUMonitor.kext (not from EFI, from somewhere else, be sure to chown -R root:wheel to that kext if moved - otherwise maybe some permissions/owners error can happen. 

IntelCPUMonitor can of course stay always in use / loaded. 

But for try of critical (KP & more) sensor.kext it would be much more safe to kextload them - if KP doenst matter because not always injekted/loaded.

Share this post


Link to post
Share on other sites

If I put the FakeSMC and IntelCPU kexts into SLE, then both load without that error:

kextstat -l | egrep -v "com.apple"
   21    1 0xffffff7f8265f000 0xd000     0xd000     org.netkas.FakeSMC (3.5.0) A63F6CAD-05B3-335C-8084-9D034A5E7F83 <11 7 5 4 3>

 

   22    0 0xffffff7f8266c000 0x6000     0x6000     org.slice.IntelCPUMonitor (1.2.0) 306E344D-630E-39CC-B0E7-A0F51C3E8461 <21 7 5 4 3>
 
In Clover I put CPU Type =0x0a05 and FakeCPUID as 0x0506E4 otherwise I can't boot - does this cause any issue ?
 

Attached is a new DarwinDumper with both in SLE

 

Also in post 404, I put a screen shot of AIDA64 sensor, which kext does this chipset belong to ?

 

Thanks !

Slice, do you have any idea why I still can't see CPU sensors even though both FakeSMC and IntelCPU are loaded ?

 

Thanks !

Share this post


Link to post
Share on other sites

Slice, do you have any idea why I still can't see CPU sensors even though both FakeSMC and IntelCPU are loaded ?

 

Thanks !

Must works.

0      0    kernel: (kernel) IntelCPUMonitor: [Warning] Unsupported Intel processor found ID=0x55, kext will not load

This is old version of IntelCPUmonitor.kext.

New version does support processor model 0x55.

Share this post


Link to post
Share on other sites

Must works.

0      0    kernel: (kernel) IntelCPUMonitor: [Warning] Unsupported Intel processor found ID=0x55, kext will not load

This is old version of IntelCPUmonitor.kext.

New version does support processor model 0x55.

I have tried "HWSensors3v51.dmg" and "Release350.zip".

 

Both are ver 1.2.0. Is this the latest ? If not where can I get the latest ?

Share this post


Link to post
Share on other sites

Thanks Slice ! That's working now & I can see CPU temp & speed info.

 

For the motherboard sensors, which kext should I use ? I posted my AIDA64 in post 404

 

And can you please link the latest kext for NVIDIA GTX1080ti stats ?

 

Thanks !

From your AIDA report I see LM78 chip for which we have no kexts.

Fjr Nvidia Pascal test, please, this debug version. There is expected many messages in system.log.

Later I will make release version.

GeforceSensor.kext_2.zip

Share this post


Link to post
Share on other sites

From your AIDA report I see LM78 chip for which we have no kexts.

Fjr Nvidia Pascal test, please, this debug version. There is expected many messages in system.log.

Later I will make release version.

attachicon.gifGeforceSensor.kext_2.zip

Thanks Slice !

 

The GeforceSensor works, but I only see the temp GPU0 Proximity. Is this all the info that can be shown ?

 

Oh that's a pity there is no LM78 kext, hopefully someone will make one

Share this post


Link to post
Share on other sites

Thanks Slice !

 

The GeforceSensor works, but I only see the temp GPU0 Proximity. Is this all the info that can be shown ?

 

Oh that's a pity there is no LM78 kext, hopefully someone will make one

I study Linux kernel-4.14 for these questions. Still found nothing.

Share this post


Link to post
Share on other sites

Attached is the data sheet

 

Thanks

Thanks,

this chip differs from 6776. The kext must be rewritten.

HD 7790

Picos-Mac-Pro:radeon pico$ ./RadeonDump1 -n 6b0,c0300014

Found a device of class RadeonPCI: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PEGP@1/IOPP/GFX1@0/RadeonPCI

it matched on name "ATY_GPU"

0xc0300014: 0x       0

So this is other family

Test follow

./RadeonDump1 -r 714,7f4

 

 ./RadeonDump1 -n 6b0,c0300e0c

Share this post


Link to post
Share on other sites

Sir recently use seen ur post regarding injecting Machine Id for AGPM.

Sir Ive Injected AGPM For my AMD Radeon HD 7650M via FakeSMC.

Sir I've used MBP 9,2 Board id for CPU and MBP 8,3 board id for GPU PM, sir is it good way for getting PM !

Sir should v Inject SMC key according to CPU Model !

 

The reason m curious is coz in 

MBP 9,2 SMC Key is 2.2f44 and MBP 10,1 SMC Key is 2.6f57 

 

N both have same CPU i.e i5 3210M, so which one should i use ?

 

My Model has SMC Key 2.3f36

 

Sir its very imp  as I've seen some Performance improvement after i played around SMC keys, but i needed ur opinion  :)

 

Sir was the diff between RehabMan FakeSMC(k) n Ur Version of FameSMC !  

 

Edit: Found appropriate thread from Slice Sir :)

Share this post


Link to post
Share on other sites

Slice sir can i get uninstall .cmd for HWSensor.pkg :(


There is influence of Machine ID on GPUPM.

But there is no influence of SMC Rev on performance.

Sir wen i change SMC Rev to 2.2f44 i see CPU(i5 3210M) performance 

for example CPU Utilisation,Frequency and Temperature  increases or decrease drastically. Ive noticed it sir :)  

Share this post


Link to post
Share on other sites

I wish to announce HWSensors3 revision 75 is available now at sourceforge.net. The link is in my signature.

It includes:

FakeSMC 3.5.0

IntelCPUMonitor supporting CPU up to Kabylake 2.

AmdCPUMonitor

ACPIMonitor for custom monitoring

RadeonMonitor  supporting HD5xxx, 6xxx, 7xxx, R7 2xx, RX4xx, RX5xx and similar

GeforceSensors supporting cards up to Pascal. It has monitoring Core, Shader and Memory clocks.

SuperIO chip monitoring including Fintek, ITE, Winbond, Nuvoton and SMC LPC chips. 

VoodooBatterySMC to show laptop battery voltage and current amperage dynamically.

HWMonitorSMC application to show all these values

as well iStatPro widget

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