Jump to content

1,165 posts in this topic

Recommended Posts

:bag:

 

But be carefull with this new SMART feature - I don't tested it much. If I'll lost my drives, I tell you.

Share this post


Link to post
Share on other sites
Advertisement

I got a warning differently to The Kings' plugin http://www.insanelym...dpost&p=1795969

About CPU multipliers, the last IntelThermal works good.

 

Feb 18 00:54:41 localhost kernel[0]: Found ATI Radeon 6738

Feb 18 00:54:41 localhost kernel[0]: NCT677x: [Warning] wrong vendor id (0xffff), continue loading...

Feb 18 00:54:41 localhost kernel[0]: NCT677x: found Nuvoton NCT6776F

Feb 18 00:54:41 localhost kernel[0]: IntelThermal: CPU family 0x6, model 0x2a, stepping 0x7, cores 4, threads 8, TJmax 98

 

 

Schermata 02-2455976 alle 00.58.59.png

Share this post


Link to post
Share on other sites

12def96a38:

W836x: [Warning] wrong vendor id (0xffff), continue loading...

W836x: found Winbond W83627DHG

 

6ea831fe98:

W836x: [Warning] wrong vendor ID=0xa3a3

Share this post


Link to post
Share on other sites

Hello,

 

To fix Hardware id detection in WindbondW386x.cpp

 

Replace value 0

UInt16 vendor = UInt16( ( readByte(0, WINBOND_VENDOR_ID_REGISTER) << 8 ) | readByte(0, WINBOND_VENDOR_ID_REGISTER) );

 

According to data sheet, you need to select good byte to read.

UInt16 vendor = UInt16( ( readByte(0x80, WINBOND_VENDOR_ID_REGISTER) << 8 ) | readByte(0, WINBOND_VENDOR_ID_REGISTER) );

 

Tested on Asus P5B. :)

 

Feb 22 20:51:03 localhost kernel[0]: FireWire (OHCI) TI ID 8023 built-in now active, GUID 0011d800012e2a2c; max speed s400.

Feb 22 20:51:03 localhost kernel[0]: W836x: found Winbond W83627DHG

Feb 22 20:51:03 localhost kernel[0]: IntelThermal: CPU family 0x6, model 0xf, stepping 0x6, cores 1, threads 2, TJmax 80

 

Regards

Share this post


Link to post
Share on other sites

Hello,

 

To fix Fan detection in WindbondW386x.cpp

 

//if (OSNumber* fanlimit = configuration ? OSDynamicCast(OSNumber, configuration->getObject("FANINLIMIT")) : 0)

// fanLimit = fanlimit->unsigned8BitValue();

 

OSNumber* fanlimit = configuration ? OSDynamicCast(OSNumber, configuration->getObject("FANINLIMIT")) : 0;

 

Fix Fan in my case with Asus P5B.

Now two Fans appear in monitor, one is Cpu other is Power Supply.

 

Regards

Share this post


Link to post
Share on other sites
Hello, To fix Fan detection in WindbondW386x.cpp //if (OSNumber* fanlimit = configuration ? OSDynamicCast(OSNumber, configuration->getObject("FANINLIMIT")) : 0) // fanLimit = fanlimit->unsigned8BitValue(); OSNumber* fanlimit = configuration ? OSDynamicCast(OSNumber, configuration->getObject("FANINLIMIT")) : 0; Fix Fan in my case with Asus P5B. Now two Fans appear in monitor, one is Cpu other is Power Supply. Regards

 

This fix keep fanLimit as is. Default value for fanLimit is 3 or depending of chip model. As I understand, without any fix fanLimit sets to 0... :worried_anim:

 

Fixed! Uploaded. Not tested, need feedback.

Share this post


Link to post
Share on other sites

works, thx a lot!

1d69e0f: W836x: found Winbond W83627DHG

 

i have to edit each time:

  <dict>
   <key>Default</key>
   <dict>
 <key>FANIN0</key>
 <string></string>
 <key>FANIN1</key>
 <string>CPU</string>
 <key>FANIN2</key>
 <string></string>
 <key>FANIN3</key>
 <string></string>
 <key>FANIN4</key>
 <string></string>
 <key>FANINLIMIT</key>
 <integer>2</integer>
 <key>TEMPIN0FORCED</key>
 <true/>
 <key>TEMPIN1FORCED</key>
 <false/>
   </dict>
  </dict>

Share this post


Link to post
Share on other sites

This fix keep fanLimit as is. Default value for fanLimit is 3 or depending of chip model. As I understand, without any fix fanLimit sets to 0... :worried_anim:

 

Fixed! Uploaded. Not tested, need feedback.

 

Hello,

 

fanLimit was good just before execute this line.

fanLimit = fanlimit->unsigned8BitValue(); -> result is 0.

 

 

Now, works fine.

 

But this line is not needed test gives 0.

if (fanlimit && fanlimit->unsigned8BitValue() > 0) fanLimit = fanlimit->unsigned8BitValue();

 

 

Regards

Share this post


Link to post
Share on other sites

hi kozlek, your set of monitoring kexts works beautifully on the system in signature, apart nvclockx (updated from your git repository just yesterday)

The temperature detected is not correct, you can see below the difference between windows and osx

 

post-449896-0-38459000-1329999333_thumb.png post-449896-0-79661500-1329999352_thumb.jpg

 

Thanks for your work and your attention.

Cheers.

Share this post


Link to post
Share on other sites

Hello,

 

fanLimit was good just before execute this line.

fanLimit = fanlimit->unsigned8BitValue(); -> result is 0.

 

 

Now, works fine.

 

But this line is not needed test gives 0.

if (fanlimit && fanlimit->unsigned8BitValue() > 0) fanLimit = fanlimit->unsigned8BitValue();

 

 

Regards

 

This line is needed. The logic is to prevent from reading from unavailable registers... I am not sure but it seems not all models has full fan registers set. I took it from open hardware monitor. They are limiting number of fan depending on model.

Share this post


Link to post
Share on other sites

F718x: [Warning] found unsupported chip ID=0x10 REVISION=0x7

 

please can you add a support for this chip also

 

Fintek F71869A

 

this is what the Lm-sensor return to me

 

 

Found `Fintek F71869A Super IO Sensors' Success!

(address 0x295, driver `f71882fg')

 

Thanks for your Help

lm78.txt

Share this post


Link to post
Share on other sites

on the X-code i change all the value of

 

F71869 with F71869A

 

 

and also here to much the value for the Id 10 and the revision 07

 

 

case 0x10:

{

switch (revision)

{

case 0x07:

model = F71869A;

logicalDeviceNumber = FINTEK_HARDWARE_MONITOR_LDN;

break;

}

 

the KEXT is loaded with no problem

 

 

Feb 24 15:03:43 localhost kernel[0]: IntelThermal: CPU family 0x6, model 0x2a, stepping 0x7, cores 4, threads 8, TJmax 98

Feb 24 15:03:43 localhost kernel[0]: F718x: found Fintek F71869A

 

 

but i get a wrong value

 

please check the snapshot

post-216126-0-86957000-1330086640_thumb.jpg

Share this post


Link to post
Share on other sites
on the X-code i change all the value of F71869 with F71869A and also here to much the value for the Id 10 and the revision 07 case 0x10: { switch (revision) { case 0x07: model = F71869A; logicalDeviceNumber = FINTEK_HARDWARE_MONITOR_LDN; break; } the KEXT is loaded with no problem Feb 24 15:03:43 localhost kernel[0]: IntelThermal: CPU family 0x6, model 0x2a, stepping 0x7, cores 4, threads 8, TJmax 98 Feb 24 15:03:43 localhost kernel[0]: F718x: found Fintek F71869A but i get a wrong value please check the snapshot

 

lmsensors like OpenHardwareMonitor uses the same logic to get temperatures from most of supported Fintek chipsets. Could you run openhardwaremonitor on windows and capture the screen?

 

hi kozlek, your set of monitoring kexts works beautifully on the system in signature, apart nvclockx (updated from your git repository just yesterday)

The temperature detected is not correct, you can see below the difference between windows and osx

 

post-449896-0-38459000-1329999333_thumb.png post-449896-0-79661500-1329999352_thumb.jpg

 

Thanks for your work and your attention.

Cheers.

 

Please, install attached debug version of NVClock and show me your kernel.log

NVClockX.kext.zip

Share this post


Link to post
Share on other sites

OK! Here's the kernel log with the nvclock debug version.... tnx

kerneldebug.rtf

 

Seems NVClock wasn't found integrated monitoring device so trying to read temperature directly from video registers but:

 

/* Reading of the internal gpu sensor, it not entirely correct yet */

static int nv50_get_gpu_temp(void *sensor)

{

int temp;

int correction=0;

float offset;

float slope;

/* For now use a hardcoded offset and gain. This isn't correct but I don't know how the new temperture table works yet; this at least gives something */

offset = -227.0;

slope = 430.0/10000.0;

if(nv_card->debug)

{

printf("NV_20008 (0x20008): %08x\n", nv_card->PMC[0x20008/4]);

printf("slope=%f, offset=%f, correction=%d\n", slope, offset, correction);

}

 

temp = nv_card->PMC[0x20008/4] & 0x1fff;

return (int)(temp * slope + offset) + correction;

}

 

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.
       
    • By Slice
      This thread devoted to share information about different SMC keys found or investigated anywhere.
       
      What are they?
      SMC keys is a somehow language to speak between macOS and hardware microcontroller presented in real Mac and absent in Hackintosh.
      They inform macOS about Hardware ID and current status. Moreover macOS can write something through SMC protocol to control hardware.
      FakeSMC ( ©Netkas) is the driver to emulate this microcontroller on PC having no such device which is necessary to boot macOS here.
      But FakeSMC contain only ~20 keys while real Mac answers ~200 keys.
      Some keys we added by HWSensors project reporting temperatures, FAN speeds, voltages etc.
      Some keys are model dependent was added by Clover to be sure if user changed model in GUI then corresponding keys will be changed automatically.
      Clover sets
      LogDataHub(&gEfiMiscSubClassGuid, L"RPlt", &gSettings.RPlt, 8);
      LogDataHub(&gEfiMiscSubClassGuid, L"RBr", &gSettings.RBr, 8);
      LogDataHub(&gEfiMiscSubClassGuid, L"EPCI", &gSettings.EPCI, 4);
      LogDataHub(&gEfiMiscSubClassGuid, L"REV", &gSettings.REV, 6);
      LogDataHub(&gEfiMiscSubClassGuid, L"BEMB", &gSettings.Mobile, 1);
      BEMB - is a mobility sign. =0 -desktop, =1 - mobile.
      REV - SMC hardware revision, changes sometimes with Apple updates.
      RPlt, RBr and EPCI is hardware capabilities, noticed used in Intel HD drivers.
       
      Structure.
      All SMC keys consists of name 4 ascii chars as 32bit integer, type and value.
      Types:
       "flag", len 1
       "ui8 ", len 1
       "ui16", len 2
       "sp78", len 2
       "ui32", len 4
      "fp2e", len 2
      "fpe2", len 2
      "{rev", and others...
       
      List of known keys
      SMC_list.plist.zip
      More keys will be discussed in the thread
       
       
      Feel free to share you knowledge and ask about noticed keys.
×