Jump to content

2,080 posts in this topic

Recommended Posts

8 hours ago, Andrey1970 said:

@vector sigma

HWMonitorSMC2 from r222, indications "Package IGPU" are frozen at the time of an application launch.
Earlier (the version with "GT") worked well. Please fix.

 

P.S.

I on former see two sensors "Package IGPU", from SMC keys and from IPG. I think better an settings option IPG shall switch sources.

 

 

1906235619_2019-08-0823_26_09.thumb.png.333544eb6b283c1a2b10414f44e22872.png

I see no such problem

Снимок экрана 2019-08-09 в 7.49.54.png

 

The value can't be from SMC as no such sensor.

Share this post


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

Yep, but I think is solved, please try r226

Strange, but I had a problem of build of the last versions.

Please upload the app.

Share this post


Link to post
Share on other sites
17 hours ago, Slice said:

OK, I will add it.

@Slice I built a new pkg based on r227 (I see you added code for the NCT6797D chip). However, the W836x.kext fails to load. See attachment. What can I do to help get this working?

error.png

Share this post


Link to post
Share on other sites
On 8/9/2019 at 9:22 PM, curtistn73 said:

@Slice I built a new pkg based on r227 (I see you added code for the NCT6797D chip). However, the W836x.kext fails to load. See attachment. What can I do to help get this working?

error.png

The kext must be compiled with SDK10.11.

And FakeSMC must be version 3.5.2, not 6, not 1800.

Take release package from sf.net.

Share this post


Link to post
Share on other sites
14 hours ago, Slice said:

The kext must be compiled with SDK10.11.

And FakeSMC must be version 3.5.2, not 6, not 1800.

Take release package from sf.net.

Hi @Slice, I used the r227 release package from SourceForge, and (unfortunately) have the same results: W836x kext does not load and the same error is present in the logs.

error2.png

Share this post


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

Take package 234.

I tried r234. However, it didn't help and W836x still doesn't load.

Share this post


Link to post
Share on other sites
52 minutes ago, Andres ZeroCross said:

How to compile HWSensor3?? Got stuck in this line...

 

 

svn up

 

1 hour ago, curtistn73 said:

I tried r234. However, it didn't help and W836x still doesn't load.

Can you provide some logs for more info?

Or I have to propose that you just using wrong version of FakeSMC?

Share this post


Link to post
Share on other sites
17 hours ago, Slice said:

 

 

Can you provide some logs for more info?

Or I have to propose that you just using wrong version of FakeSMC?

Thanks for your help @Slice. I hope the attached information will be useful.

non-apple-kexts.jpg

hwmonitor.jpg

boot-log.txt

system-log.txt

Share this post


Link to post
Share on other sites
5 hours ago, Slice said:

Thanks for detailed logs.

Test this version. If OK then I have to replace default downloaded package.

W836x.kext.zip

We are making progress! This kext loads and information is shown in HWMonitorSMC2. However, the voltages do not appear to be correct (see attached pic). Also, CPU Fan and System Fan seem to be swapped.

kexts.png

new-systemlog-w836x.txt

hwmonitor2.png

Share this post


Link to post
Share on other sites
On 8/9/2019 at 3:29 PM, Andrey1970 said:

Strange, but I had a problem of build of the last versions.

 

On 8/13/2019 at 8:16 PM, Andres ZeroCross said:

How to compile HWSensor3?? Got stuck in this line...

 

image.thumb.png.06c29dcdb695ae0debbc91191a9db2b0.png

Hi guys, not sure where the problem reside for you, but can you try debug version?

 

just make a copy of ./hwconf.profile in your Home directory (or just edit it in place) from Release to Debug:

export PREFERRED_CONF_APPS='Debug'

let me know

Share this post


Link to post
Share on other sites

For additional information.

I have 10.13.6 with XCode 10.1 and swift 4.2.

The build process told me that "swift 4.2.1 is not found, back to 4.2" and then compilation is successful. Just take a whole minute to do.

Share this post


Link to post
Share on other sites
9 minutes ago, Slice said:

For additional information.

I have 10.13.6 with XCode 10.1 and swift 4.2.

The build process told me that "swift 4.2.1 is not found, back to 4.2" and then compilation is successful. Just take a whole minute to do.

Thanks. Swift 4.2.1 is ok, I'll fix it. But I guess a minute for building from scratch (make fresh) is just fine, the problem is with some Xcode and the shipped parser that goes crazy solving very easy statements like is too complicated, for example this alone took 3 seconds to be resolved (strings concatenation using +):

 

return String(describing: UnicodeScalar(self >> 24 & 0xff)!) +
       String(describing: UnicodeScalar(self >> 16 & 0xff)!) +
       String(describing: UnicodeScalar(self >> 8  & 0xff)!) +
       String(describing: UnicodeScalar(self       & 0xff)!)

while this just took few ms:

return "\(String(describing: UnicodeScalar(self >> 24 & 0xff)!))\(String(describing: UnicodeScalar(self >> 16 & 0xff)!))\(String(describing: UnicodeScalar(self >> 8  & 0xff)!))\(String(describing: UnicodeScalar(self & 0xff)!))"

... to do just the same. Also they have problems with "concurrency building" vs "one by one", why I suggested to use "Debug" because use the second. Hope Apple fix it soon. No problems here with Xcode 10.2.1.

 

Share this post


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

Thanks for detailed logs.

Test this version. If OK then I have to replace default downloaded package.

W836x.kext.zip

Hello again @Slice I appreciate your help. I am currently working on creating a profile for my motherboard. Would you merge the code from this W836x.kext into the main branch?

I'd like to experiment, as it appears my motherboard (with NCT6797D chip) is using voltage sensors up to VIN15. Thanks in advance!

Share this post


Link to post
Share on other sites
On 8/16/2019 at 4:47 PM, curtistn73 said:

Hello again @Slice I appreciate your help. I am currently working on creating a profile for my motherboard. Would you merge the code from this W836x.kext into the main branch?

I'd like to experiment, as it appears my motherboard (with NCT6797D chip) is using voltage sensors up to VIN15. Thanks in advance!

Already done.

The chip support done in rev 224, and compilation errors fixed in 237.

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