Jump to content

2,077 posts in this topic

Recommended Posts

What is changed except the kext? Something else? 

The main difference is reporting SMC keys, but it is not influencing on system.

May be broken permissions?

 

Nothing else has changed. I have tried your latest HWSensor automatic installation package as well as extracting the package with Pacifist and then installing the resulting appropriate kexts via Chameleon Wizard. I have installed both versions several times using the same installation methods, and rolled them back to the previous version several times even running Disk Utility each time for good measure.

 

In both instances, there are no permission errors and kextstat and System Information both show the FakeSMC.kext and its plugins installed correctly. Each time, the latest FakeSMC.kext version 3.4.0 causes a black screen upon system Wake while FakeSMC.kext 3.3.1 presents no such issue.

 

In the past several years, I have never experienced any issues with your branch of FakeSMC HWSensors, and I have also never experienced black screen upon system Wake for any reason.

FakeSMC:

  Version: 3.3.1
  Last Modified: 12/11/14 4:16 PM
  Kind: Intel
  Architectures: i386, x86_64
  64-Bit (Intel): Yes
  Location: /System/Library/Extensions/FakeSMC.kext
  Kext Version: 3.3.1
  Load Address: 0xffffff7f81a04000
  Valid: Yes
  Authentic: Yes
  Dependencies: Satisfied

Share this post


Link to post
Share on other sites
Advertisement

 

Nothing else has changed. I have tried your latest HWSensor automatic installation package as well as extracting the package with Pacifist and then installing the resulting appropriate kexts via Chameleon Wizard. I have installed both versions several times using the same installation methods, and rolled them back to the previous version several times even running Disk Utility each time for good measure.

 

In both instances, there are no permission errors and kextstat and System Information both show the FakeSMC.kext and its plugins installed correctly. Each time, the latest FakeSMC.kext version 3.4.0 causes a black screen upon system Wake while FakeSMC.kext 3.3.1 presents no such issue.

 

In the past several years, I have never experienced any issues with your branch of FakeSMC HWSensors, and I have also never experienced black screen upon system Wake for any reason.

FakeSMC:

  Version: 3.3.1
  Last Modified: 12/11/14 4:16 PM
  Kind: Intel
  Architectures: i386, x86_64
  64-Bit (Intel): Yes
  Location: /System/Library/Extensions/FakeSMC.kext
  Kext Version: 3.3.1
  Load Address: 0xffffff7f81a04000
  Valid: Yes
  Authentic: Yes
  Dependencies: Satisfied

Compare, please, Info.plist's of these two versions of FakeSMC.kext.

I see no reason for different behavior other then different info.plist.

The version changed because of new output but system can't see it.

Share this post


Link to post
Share on other sites

Compare, please, Info.plist's of these two versions of FakeSMC.kext.

I see no reason for different behavior other then different info.plist.

The version changed because of new output but system can't see it.

 

Both FakeSMC.kext versions Info.plists appear to be identical short of the version number and yet the problem persists.

For now, I will simply continue using the older FakeSMC.kext version 3.3.1.

 

Thank You for your work!

Share this post


Link to post
Share on other sites

Hey

 

thanks for your great work. I have a question. Do you have any idea when and/or if the gm204 chipsets might be supported in the future?

Jan  3 15:39:14 localhost kernel[0]: GeForceSensors (pci1): [Fatal] GM204 not supported yet
Jan  3 15:39:14 localhost kernel[0]: GeForceSensors (pci1): [Fatal] unsupported chipset, 0x124020a1

Cheers

Share this post


Link to post
Share on other sites

Hey

 

thanks for your great work. I have a question. Do you have any idea when and/or if the gm204 chipsets might be supported in the future?

Jan  3 15:39:14 localhost kernel[0]: GeForceSensors (pci1): [Fatal] GM204 not supported yet
Jan  3 15:39:14 localhost kernel[0]: GeForceSensors (pci1): [Fatal] unsupported chipset, 0x124020a1

Cheers

Yes, I think it may be supported in future... but I see these messages not from my project...

Share this post


Link to post
Share on other sites

Revision 11.

Yes, I change project home and begin numeration from zero. Link is in the topic.

 

Change log:

- support more hardware, more NVidia cards, more SMBus chips;

- installer has more options to install. Silent AppleSMC included to not spam in system.log;

- corrected numerous bugs existing here from initial.

Share this post


Link to post
Share on other sites

Can anybody test debug version of new plugin DIMMSensor? It should monitor temperature on DIMM sensors.

SMC keys will be TM0P, TM1P, ...

sudo chown -R root:wheel DIMMSensor.kext
sudo kextutil -v DIMMSensor.kext

There will be many messages in kernel.log

 

Share this post


Link to post
Share on other sites

It doesn't work for me and  I think you mean this messages.

 

 

Jan 30 21:32:23 localhost kernel[0] <Notice>: ARPT cannot assert wake from D3cold
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] init
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] probe
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] start
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] conf: 0x1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] IRQ: 19
Jan 30 21:32:23 localhost kernel[0] <Notice>: Controller: Intel 82801H (vendor ID: 8086, device ID: 284b)
Jan 30 21:32:23 localhost kernel[0] <Notice>: FakeSMC: opensource SMC device emulator by netkas © 2009
Jan 30 21:32:23 localhost kernel[0] <Notice>: FakeSMC: plugins & plugins support modifications by mozodojo, usr-sse2, slice © 2010
Jan 30 21:32:23 localhost kernel[0] <Notice>: FakeSMCDevice: 21 preconfigured key(s) added
Jan 30 21:32:23 localhost kernel[0] <Notice>: FakeSMCDevice: successfully initialized
Jan 30 21:32:23 localhost kernel[0] <Notice>: IntelCPUMonitor: CPU family 0x6, model 0xf, stepping 0xd, cores 2, threads 2
Jan 30 21:32:23 localhost kernel[0] <Notice>: FireWire runtime power conservation disabled. (3)
Jan 30 21:32:23 localhost kernel[0] <Notice>: IntelCPUMonitor: Using efi
Jan 30 21:32:23 localhost kernel[0] <Notice>: IntelCPUMonitor: BusClock=166MHz FSB=665MHz
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: op 1, addr 0x18, cmdlen 1, len 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: St 0x40
Jan 30 21:32:23 localhost kernel[0] <Notice>: IntelCPUMonitor: CPU Tjmax 100
Jan 30 21:32:23 localhost kernel[0] <Notice>: HWInfo: SMC Platform: M75
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: Ctl 0x49
Jan 30 21:32:23 localhost kernel[0] <Notice>: VoodooPS2SynapticsTouchPad Version 1.8.12 loaded...
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] Register decoded: 0x44<BUSY=0,INTR=0,DEVERR=1,BUSERR=0,FAILED=0,SMBAL=0,INUSE=1,BDONE=0>
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] marker = 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: op 1, addr 0x19, cmdlen 1, len 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: St 0x0
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: Ctl 0x49
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] Register decoded: 0x44<BUSY=0,INTR=0,DEVERR=1,BUSERR=0,FAILED=0,SMBAL=0,INUSE=1,BDONE=0>
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] marker = 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: op 1, addr 0x1a, cmdlen 1, len 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: St 0x0
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: Ctl 0x49
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] Register decoded: 0x44<BUSY=0,INTR=0,DEVERR=1,BUSERR=0,FAILED=0,SMBAL=0,INUSE=1,BDONE=0>
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] marker = 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: op 1, addr 0x1b, cmdlen 1, len 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: St 0x0
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: Ctl 0x49
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] Register decoded: 0x44<BUSY=0,INTR=0,DEVERR=1,BUSERR=0,FAILED=0,SMBAL=0,INUSE=1,BDONE=0>
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] marker = 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: op 1, addr 0x1c, cmdlen 1, len 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: St 0x0
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: Ctl 0x49
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] Register decoded: 0x44<BUSY=0,INTR=0,DEVERR=1,BUSERR=0,FAILED=0,SMBAL=0,INUSE=1,BDONE=0>
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] marker = 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: op 1, addr 0x1d, cmdlen 1, len 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: St 0x0
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: Ctl 0x49
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] Register decoded: 0x44<BUSY=0,INTR=0,DEVERR=1,BUSERR=0,FAILED=0,SMBAL=0,INUSE=1,BDONE=0>
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] marker = 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: op 1, addr 0x1e, cmdlen 1, len 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: St 0x0
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: Ctl 0x49
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] Register decoded: 0x44<BUSY=0,INTR=0,DEVERR=1,BUSERR=0,FAILED=0,SMBAL=0,INUSE=1,BDONE=0>
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] marker = 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: op 1, addr 0x1f, cmdlen 1, len 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: St 0x0
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] exec: Ctl 0x49
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] Register decoded: 0x44<BUSY=0,INTR=0,DEVERR=1,BUSERR=0,FAILED=0,SMBAL=0,INUSE=1,BDONE=0>
Jan 30 21:32:23 localhost kernel[0] <Notice>: [iCHSMBus] marker = 1
Jan 30 21:32:23 localhost kernel[0] <Notice>: FireWire (OHCI) VendorID 1180 ID 832 PCI now active, GUID 00241b002fd83c00; max speed s400.
Jan 30 21:32:23 localhost kernel[0] <Notice>: [DIMM] Device matching failed.
 

Share this post


Link to post
Share on other sites

46395098.png

 

Apparently it doesn't work with my GTX 970.

 

 

I installed it like this:

 

CPU -> Intel CPU

LPC chip type -> winbond

GPU type -> Nvidia -> New Geforce

FakeSMC

SMBus chip type

Share this post


Link to post
Share on other sites

46395098.png

 

Apparently it doesn't work with my GTX 970.

 

 

I installed it like this:

 

CPU -> Intel CPU

LPC chip type -> winbond

GPU type -> Nvidia -> New Geforce

FakeSMC

SMBus chip type

It is a conflict with Kozlek's HWMonitor application.

There is another one HWMonitor in the package.

Share this post


Link to post
Share on other sites

Hi Slice,

Does this application works if FakeSMC is an injected kext (Clover and 10.10 folder routine) via clover on USB pen?

Yes, as usual.

These kexts will work if injected by a bootloader.

I prefer place all kexts into SLE because injection requires additional time while SLE will be cached.

Share this post


Link to post
Share on other sites

Ok its working now but I only see one GPU in the list I have three. I have 2 x 970 and one 570.

 

How do one change fan speed with this version?

 

post-36193-0-26568000-1423227130_thumb.png

Share this post


Link to post
Share on other sites

i cant get my cpu fan reading in fake smc 

pls help me 

my dump and screenshot is added

OK.

You are using kexts and HWMonitor application v6.x from Kozlek while the thread about HWSensors3 by me.

There is a difference.

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