Jump to content

2,077 posts in this topic

Recommended Posts

Advertisement

I tried it but it broke my sound (VoodooHDA) and internet (AtherosL1c) -they are injected by Clover-  and HWsensors showed less info.

I had to remove the installed kexts and copy my old (current) FakeSMC and everything fine again.

 

Don't know if I did something wrong here, selected Intel CPU, FakeSMC, LPC ITE87xx snd GPU Type AMD Radeon.

Share this post


Link to post
Share on other sites

I tried it but it broke my sound (VoodooHDA) and internet (AtherosL1c) -they are injected by Clover-  and HWsensors showed less info.

I had to remove the installed kexts and copy my old (current) FakeSMC and everything fine again.

 

Don't know if I did something wrong here, selected Intel CPU, FakeSMC, LPC ITE87xx snd GPU Type AMD Radeon.

Try without LPC

Share this post


Link to post
Share on other sites

i would also like to know that does this bring versus the HWSensors from kozlek. Also, what does ACPI access and LPC chip do ?

Share this post


Link to post
Share on other sites

i would also like to know that does this bring versus the HWSensors from kozlek. Also, what does ACPI access and LPC chip do ?

Wich chip sensor have you ?

Share this post


Link to post
Share on other sites

Thank you Slice, works fine. Tested on my Laptop running 10.9.4

 

P.D.

For MacBookPro6,1-6,2 (Arrandale CPU) "RPlt"="k74"="6B373400 00000000" can be added to FakeSMC "Info.plist" as:

RPlt
ch8*
azc0AAAAAAA=
 

Also, the most recent from Apple MBP6,1-6,2 "REV"="1.58f17"="01580F00 0017" as:

REV
{rev
AVgPAAAX
 
Another data is:
smc-compatible
smc-piketon

 

Additionally, to avoid some startup (console log) error related to SMC key, we can add the "lightshow-version"="LsbV"="1.4a6"="01040A00 06" as:

LsbV
{rev
AQQKAAY=

Share this post


Link to post
Share on other sites

Hi Slice.

 

Tested fine on 10.9.4 and 10.10 DP4 all works fine even  HW Monitor is Yosemite dark mode friendly.

 

Thanks.

 

Tested on Asus Z87 Sabertooth with GT660 discrete.

Share this post


Link to post
Share on other sites

i would also like to know that does this bring versus the HWSensors from kozlek. Also, what does ACPI access and LPC chip do ?

Kozlek decided to make quite different version so I stay with this good working version improving it.

ACPI access is for those people who know how to edit DSDT to get access to hardware parameters. It may be useful if you have no other access.

LPC chips: Winbond, ITE, Fintek etc present on desktop motherboards but absent on notebooks.

 

No plugins inside FakeSMC.kext ! Is this normal ?

It is normal for this branch because plugins used differently from FakeSMC.

Share this post


Link to post
Share on other sites

Sergey ...i have try first with old nvclock ...and work ...

After i have try with new ....strange my pc dont work ...now reinstall again osx ...mhmm

Share this post


Link to post
Share on other sites

Sergey ...i have try first with old nvclock ...and work ...

After i have try with new ....strange my pc dont work ...now reinstall again osx ...mhmm

Yea, GeforceSensors looks buggy. NVClockX is preferable.

Share this post


Link to post
Share on other sites

So can the sensors kexts be used inside a plugins folder in fakesmc or do the have to be installed normally?

I created a plugins folder under Contents,  then added the kexts I loaded the pkg file to an USB drive, then moved the FakeSMC.kext and the plugin files i needed to the relevant EFI kext directories in Clover. This was to avoid the installer writing to S/L/E.

 

See here what I mean - it appears to work very well.

 

http://d.pr/i/ISFA

Share this post


Link to post
Share on other sites

Try without LPC

The same thing happened, it must be buggy, reverting and won't try again, I don't want to destroy my install.

Share this post


Link to post
Share on other sites

Kozlek decided to make quite different version so I stay with this good working version improving it.

ACPI access is for those people who know how to edit DSDT to get access to hardware parameters. It may be useful if you have no other access.

LPC chips: Winbond, ITE, Fintek etc present on desktop motherboards but absent on notebooks.

 

It is normal for this branch because plugins used differently from FakeSMC.

Thank you sir for clarification. I will try this when i get home :)

Share this post


Link to post
Share on other sites

I installed the pgk and after that OS X 10.9.4 didnt boot (seems Fakesmc cant get loaded : waiting dsmos for ever.

Found that all installed .kext got wrong permissions!! After chown -R root:wheel .... for each .kext the problem was gone.

Share this post


Link to post
Share on other sites

I installed the pgk and after that OS X 10.9.4 didnt boot (seems Fakesmc cant get loaded : waiting dsmos for ever.

Found that all installed .kext got wrong permissions!! After chown -R root:wheel .... for each .kext the problem was gone.

Thank you for the note. I was supposed that the installer will keep permissions set in.

I set root:wheel but now I see they changed back somehow... 

Sorry!

Have no time to verify new one. Looks to be corrected

Screen Shot 2014-07-30 at 14.47.14.png

 

HWSensors.pkg.zip

 

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