Jump to content
About Just Joined group Read more... ×

2,089 posts in this topic

Recommended Posts

Advertisement

Release 196 is uploaded to sf.net including HWMonitorSMC2 v2.4.6

Снимок экрана 2019-05-08 в 6.06.03.png

 

@vector sigma

Menu font is too large for me. Is there a way to tune it?

3 minutes ago, Slice said:

 

 

@vector sigma

Menu font is too large for me. Is there a way to tune it?

Yes! It works!

Снимок экрана 2019-05-08 в 6.18.53.png

 

Share this post


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

Release 196 is uploaded to sf.net including HWMonitorSMC2 v2.4.6

Снимок экрана 2019-05-08 в 6.06.03.png

 

@vector sigma

Menu font is too large for me. Is there a way to tune it?

Yes! It works!

Снимок экрана 2019-05-08 в 6.18.53.png

 

Hi Slice, I'm so sorry to have few time lately to put in this project but sincerely I have few forces at the end of the day. Locally I have more changes for the app and the fan's control for W836x.kext which work ok for me ...just I have to implement the control by the app to make it usable by users. Hope to find time to finish soon..

 

Glad that you can change fonts as you want.

Share this post


Link to post
Share on other sites
On 5/15/2019 at 11:40 AM, fabiosun said:

I have different behavior in fan speed reading using latest 196 commit 

Yes, see this post for the solution. There's a bug which I've only fixed locally. I'm working slowly to implement Fan's control... but I didn't finish the job yet:

FanControl.png.5367b419e4c235d03b92e81d8488bc46.png

coming soon.

 

Share this post


Link to post
Share on other sites

Hi guys, today I've created the "development" branch where I'll put new code from now on. What's on the new branch?

The Fan control from HWMonitorSMC2 for all kexts that support writing SMC keys, Apple or not.

 

W836x.kext (Nuvoton and Windbond chips) is highly modified and uses the NVRAM to store settings across reboots, and this is how it works:

  1. Install the FakeSMC.kext and W836x.kext from the dmg attached. Will not work with old FakeSMC.kext.
  2. To enable the Fan control you have to add the new kernel flag -fanCtrl and reboot.
  3. Use the new HWMonitorSMC2.app, always from the attached dmg.
  4. Go to the preferences and enable "Fan Control", restart the app for the changes to take effect. If you want to show min and max values you have to enable "Show Min/Max speed" as well.

FanControl.png.ffc3590a4768fe551115f7b0b97fc4f3.png

 

 

How W836x.kext knows the min and max rpms can do a fan?

Simply by calibrating them during the first attempt ever made, by slow down at minimum your fans... so it will know the minimum rpms, and so the same for the max values. Values will be saved to the NVRAM, so next times this will not happen again.

You can recalibrate fans by setting the following nvram variable to the max:

sudo nvram HW_fanControl=%ff

..and you will hear your fans slow down firstly, and then go at max for some seconds. The third stage is to restore the motherboard defaults, so that you can decide if enable the fan control for a specific fan.... directly in HWMonitorSMC2.app:

PWM.png.687869f08267b28167683f6b47c4347b.png

pay attention that you have to enable the PWM checkbox otherwise you will not be able to edit its value.

(By disabling the PWM checkbox... the fan will be in auto mode, or to be more precise how is set in the BIOS)

 

 

Warning: as you can see my CPU Fan is controllable while "Fan 0" isn't and have equal min and max values. Why? This fan is not a PWM one because only have a 3 pin connector. In Fact to be controllable fans must have 4 pins:

PWM.jpg.9b7f224136850c0728c8da08033c4e36.jpg

 

Legacy and new SMC keys

 

In 2018 Apple introduced new SMC keys that sobstitute the old "FS! ", and in new models keys are in the format of "F1Md". This latest is the default method, but you can switch back in using the old one by adding the kernel flag "-legacyFan"

 

Why the nvram to store settings?

  1. Is persistent across reboots for all the users.
  2. You don't have to save a file somewhere or install scripts and daemons.
  3. nvram saving will only be used if HW_fanControl variable is already present in nvram... in this case published by W836x.kext. If this var is not present the app will try to write smc keys directly, but it is not persistent without a daemon that save/read somewhere smc keys involved at power off and/or power on time. Also that means that in real Mac, or with other plugins, nvram will be not touched.

How other projects should be able to use the nvram variables saved by HWMonitorSMC2.app and use the same method?

  1. The driver must post the nvram variable HW_fanControl with a value in byte >= 0 (but less then 0xff). This way HWMonitorSMC2.app knows that we want to use nvram method.
  2. being able to read and parse the HW_fanControlData variable in nvram composed by 44 bytes: 
    // example with only one fan, Fan at index 1, and with PWM turned on
      UInt8 nvFanControls[44] = {
        0x02, 0x00, /* 16 bits, bit at index 1 enabled for fan at index 1. Value for 'FS! ' or 'F1Md'*/
        0x00, 0x00, /* UInt16 value, fan at index 0 target speed                                     */
        0x05, 0xdc, /* UInt16 value, fan at index 1 target speed, in this case  0x05dc i.e. 1500 rpm */
        0x00, 0x00, /* UInt16 value, fan at index 2 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 3 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 4 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 5 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 6 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 0 min speed                                        */
        0x03, 0xE8, /* UInt16 value, fan at index 1 min speed     in this case  0x03e8 i.e. 1000 rpm */
        0x00, 0x00, /* UInt16 value, fan at index 2 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 3 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 4 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 5 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 6 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 0 max speed                                        */
        0x07, 0xd0, /* UInt16 value, fan at index 1 max speed     in this case  0x07d0 i.e. 2000 rpm */
        0x00, 0x00, /* UInt16 value, fan at index 2 max speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 3 max speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 4 max speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 5 max speed                                        */
        0x00, 0x00  /* UInt16 value, fan at index 6 max speed                                        */
      }; // max 7 fans supported.

     

Tested only with nuvoton chips as I don't own other mobos.

 

HWSensors-3_r199.dmg.zip

 

@Slice, tell me if is ok for you.

Edited by vector sigma
typos

Share this post


Link to post
Share on other sites
11 hours ago, vector sigma said:

Hi guys, today I've created the "development" branch where I'll put new code from now on. What's on the new branch?

The Fan control from HWMonitorSMC2 for all kexts that support writing SMC keys, Apple or not.

 

W836x.kext (Nuvoton and Windbond chips) is highly modified and uses the NVRAM to store settings across reboots, and this is how it works:

  1. Install the FakeSMC.kext and W836x.kext from the dmg attached. Will not work with old FakeSMC.kext.
  2. To enable the Fan control you have to add the new kernel flag -fanCtrl and reboot.
  3. Use the new HWMonitorSMC2.app, always from the attached dmg.
  4. Go to the preferences and enable "Fan Control", restart the app for the changes to take effect. If you want to show min and max values you have to enable "Show Min/Max speed" as well.

FanControl.png.ffc3590a4768fe551115f7b0b97fc4f3.png

 

 

How W836x.kext knows the min and max rpms can do a fan?

Simply by calibrating them during the first attempt ever made, by slow down at minimum your fans... so it will know the minimum rpms, and so the same for the max values. Values will be saved to the NVRAM, so next times this will not happen again.

You can recalibrate fans by setting the following nvram variable to the max:


sudo nvram HW_fanControl=%ff

..and you will hear your fans slow down firstly, and then go at max for some seconds. The third stage is to restore the motherboard defaults, so that you can decide if enable the fan control for a specific fan.... directly in HWMonitorSMC2.app:

PWM.png.687869f08267b28167683f6b47c4347b.png

pay attention that you have to enable the PWM checkbox otherwise you will not be able to edit its value.

(By disabling the PWM checkbox... the fan will be in auto mode, or to be more precise how is set in the BIOS)

---------------------------------------------------------------------------------------------------------------------------

Hi,@vector sigma, I downloaded the 199 version of hwsensors, replacing the old sensor file, but did not display the fan content after rebooting into the system, even the motherboard related content is not displayed.

 

nvram and cache have been cleaned up the problem remains.

 

Switching back to the old sensor file and Fakesmc will display the fan speed and motherboard temperature.

 

I uploaded my ioieg file, please help me to see where the problem is? Thank you!

 

My motherboard sensor model

Sensors.png.20e0f7dfe92b924b3c3fb9df1d795b71.png

 

New and old contrast

905637559_-1.thumb.jpg.ab232d12e36eed853d8406c0c3bec258.jpg

 

iMacPro 1,1-Ioieg.zip

Share this post


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

Hi guys, today I've created the "development" branch where I'll put new code from now on. What's on the new branch?

The Fan control from HWMonitorSMC2 for all kexts that support writing SMC keys, Apple or not.

 

W836x.kext (Nuvoton and Windbond chips) is highly modified and uses the NVRAM to store settings across reboots, and this is how it works:

  1. Install the FakeSMC.kext and W836x.kext from the dmg attached. Will not work with old FakeSMC.kext.
  2. To enable the Fan control you have to add the new kernel flag -fanCtrl and reboot.
  3. Use the new HWMonitorSMC2.app, always from the attached dmg.
  4. Go to the preferences and enable "Fan Control", restart the app for the changes to take effect. If you want to show min and max values you have to enable "Show Min/Max speed" as well.

FanControl.png.ffc3590a4768fe551115f7b0b97fc4f3.png

 

 

How W836x.kext knows the min and max rpms can do a fan?

Simply by calibrating them during the first attempt ever made, by slow down at minimum your fans... so it will know the minimum rpms, and so the same for the max values. Values will be saved to the NVRAM, so next times this will not happen again.

You can recalibrate fans by setting the following nvram variable to the max:


sudo nvram HW_fanControl=%ff

..and you will hear your fans slow down firstly, and then go at max for some seconds. The third stage is to restore the motherboard defaults, so that you can decide if enable the fan control for a specific fan.... directly in HWMonitorSMC2.app:

PWM.png.687869f08267b28167683f6b47c4347b.png

pay attention that you have to enable the PWM checkbox otherwise you will not be able to edit its value.

(By disabling the PWM checkbox... the fan will be in auto mode, or to be more precise how is set in the BIOS)

 

 

Warning: as you can see my CPU Fan is controllable while "Fan 0" isn't and have equal min and max values. Why? This fan is not a PWM one because only have a 3 pin connector. In Fact to be controllable fans must have 4 pins:

PWM.jpg.9b7f224136850c0728c8da08033c4e36.jpg

 

Legacy and new SMC keys

 

In 2018 Apple introduced new SMC keys that sobstitute the old "FS! ", and in new models keys are in the format of "F1Md". This latest is the default method, but you can switch back in using the old one by adding the kernel flag "-legacyFan"

 

Why the nvram to store settings?

  1. Is persistent across reboots for all the users.
  2. You don't have to save a file somewhere or install scripts and daemons.
  3. nvram saving will only be used if HW_fanControl variable is already present in nvram... in this case published by W836x.kext. If this var is not present the app will try to write smc keys directly, but it is not persistent without a daemon that save/read somewhere smc keys involved at power off and/or power on time. Also that means that in real Mac, or with other plugins, nvram will be not touched.

How other projects should be able to use the nvram variables saved by HWMonitorSMC2.app and use the same method?

  1. The driver must post the nvram variable HW_fanControl with a value in byte >= 0 (but less then 0xff). This way HWMonitorSMC2.app knows that we want to use nvram method.
  2. being able to read and parse the HW_fanControlData variable in nvram composed by 44 bytes: 
    
    // example with only one fan, Fan at index 1, and with PWM turned on
      UInt8 nvFanControls[44] = {
        0x02, 0x00, /* 16 bits, bit at index 1 enabled for fan at index 1. Value for 'FS! ' or 'F1Md'*/
        0x00, 0x00, /* UInt16 value, fan at index 0 target speed                                     */
        0x05, 0xdc, /* UInt16 value, fan at index 1 target speed, in this case  0x05dc i.e. 1500 rpm */
        0x00, 0x00, /* UInt16 value, fan at index 2 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 3 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 4 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 5 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 6 target speed                                     */
        0x00, 0x00, /* UInt16 value, fan at index 0 min speed                                        */
        0x03, 0xE8, /* UInt16 value, fan at index 1 min speed     in this case  0x03e8 i.e. 1000 rpm */
        0x00, 0x00, /* UInt16 value, fan at index 2 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 3 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 4 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 5 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 6 min speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 0 max speed                                        */
        0x07, 0xd0, /* UInt16 value, fan at index 1 max speed     in this case  0x07d0 i.e. 2000 rpm */
        0x00, 0x00, /* UInt16 value, fan at index 2 max speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 3 max speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 4 max speed                                        */
        0x00, 0x00, /* UInt16 value, fan at index 5 max speed                                        */
        0x00, 0x00  /* UInt16 value, fan at index 6 max speed                                        */
      }; // max 7 fans supported.

     

Tested only with nuvoton chips as I don't own other mobos.

 

HWSensors-3_r199.dmg.zip

 

@Slice, tell me if is ok for you.

Hi,

I think the changes are good but I have no Winbond/Nuvoton to test.

It is possible to do the same for ITE chips because Navi at past did this.

I will look if others are still good.

Share this post


Link to post
Share on other sites

Hi @vector sigma thank you for latest improvement for HWSensorSMC R199

-fanCtrl flag is a boot arg parameter?

Have you tested it in new OpenCore bootloader?

It seems an invalid parameter for it

 

thank you in advance

 

Share this post


Link to post
Share on other sites
4 hours ago, fryysyd said:

 

New and old contrast

905637559_-1.thumb.jpg.ab232d12e36eed853d8406c0c3bec258.jpg

 

iMacPro 1,1-Ioieg.zip

Hi and thanks for testing. From your ioreg I'm sure W836x.kext is not even loaded so it is normal that fans didn't show up. Causes? Not sure, wrong FakeSMC version (require FakeSMC.kext v3.5.2 from the same dmg), a bug or any. Please post a DarwinDumper log with only the kernel  log (kernel buffer messages).

Share this post


Link to post
Share on other sites
1 hour ago, fabiosun said:

-fanCtrl flag is a boot arg parameter?

Yes, is what goes in Boot->Arguments in Clover and or in nvram under 'boot-args'.

 

1 hour ago, fabiosun said:

Have you tested it in new OpenCore bootloader?

no, I don't even know what is it.

 

1 hour ago, fabiosun said:

It seems an invalid parameter for it

Sorry but this is a boot argument for the kernel, not for the bootloader. You have to ensure the kext is loaded or not and the boot argument is really given. In IoRegistryExplorer.app you can simply evaluate that  by selecting IOService and scroll to the end and see if a reference to W836x exists. This to ensure the kext is really loaded.

Also I compile them using Xcode 10.2, but with the 10.11 SDK, so a possible cause is that something goes wrong with the compilation. We can ensure this looking at the kernel log (DarwinDumper).

But I also must to say that this should not be bootloader dependent.

2 hours ago, Slice said:

It is possible to do the same for ITE chips because Navi at past did this.

Sure, just I need time and testers.

2 hours ago, Slice said:

I will look if others are still good.

good!

Share this post


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

Yes, is what goes in Boot->Arguments in Clover and or in nvram under 'boot-args'.

 

no, I don't even know what is it.

 

Sorry but this is a boot argument for the kernel, not for the bootloader. You have to ensure the kext is loaded or not and the boot argument is really given. In IoRegistryExplorer.app you can simply evaluate that  by selecting IOService and scroll to the end and see if a reference to W836x exists. This to ensure the kext is really loaded.

Also I compile them using Xcode 10.2, but with the 10.11 SDK, so a possible cause is that something goes wrong with the compilation. We can ensure this looking at the kernel log (DarwinDumper).

But I also must to say that this should not be bootloader dependent.

Sure, just I need time and testers.

good!

Hi

@vector sigma

In clover all is fine as you can see in attachment 

Problem for now is in OpenCore bootloader for me, but maybe I have to understand better how to use in it -fanCtrl parameter

 

by the way:

OpenCore bootloader link on IM here:

https://www.insanelymac.com/forum/723-opencore/

 

Screen Shot 2019-05-27 at 11.58.13 AM.png

Share this post


Link to post
Share on other sites
1 hour ago, vector sigma said:

Hi and thanks for testing. From your ioreg I'm sure W836x.kext is not even loaded so it is normal that fans didn't show up. Causes? Not sure, wrong FakeSMC version (require FakeSMC.kext v3.5.2 from the same dmg), a bug or any. Please post a DarwinDumper log with only the kernel  log (kernel buffer messages).

 

Thank you for your reply! 

I reset the HWMonitorSMC2, then restarted the computer and it showed up. But only CPU Fan 2 has a display setting Target, CPU Fan 1 does not? My CPU cooler is connected to two fans, and both fans are PWM. How to solve it?

000.thumb.jpg.da4426ca44343ffe60772313d395298a.jpg

 

Edited by fryysyd

Share this post


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

But only CPU Fan 2 has a display setting Target, CPU Fan 1 does not

They are just wrong values? Create a folder to your Desktop called HWBadSensors and restart the app. Show me a picture. Also I need a ioreg if possible, thanks.

3 minutes ago, jinbingmao said:

“GPU Memory Clock”  “GPU Core Clock“ 

What do you mean?:ph34r:

Share this post


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

他们只是错误的价值观?创建一个名为HWBadSensors的桌面文件夹, 然后重新启动应用程序。给我看一张照片 如果可能的话我也需要一个ioreg,谢谢。

你什么意思?:ph34r:

Hope to add these two

Share this post


Link to post
Share on other sites
7 hours ago, fabiosun said:

Screen Shot 2019-05-27 at 11.58.13 AM.png

Fan control is not enabled. Where did you put -fanCtrl? 

forgot me, is well working. Just a lot of values to see

Edited by vector sigma

Share this post


Link to post
Share on other sites
2 minutes ago, jinbingmao said:

Hope to add these two

Core Clock is already present if published by the Apple drivers, usually for NVIDIA. Doing it for every gpu in commerce is hard. Who knows

3 minutes ago, Pavo said:

Can someone link the latest build of HWMonitorSMCv2 please?

already in this page, just some posts above :).

Share this post


Link to post
Share on other sites
18 minutes ago, jinbingmao said:

ioreg -l |grep \"PerformanceStatistics\" | cut -d '{' -f 2 | tr '|' ',' | tr -d '}' | tr ',' '\n'|grep 'Temp\|Fan\|Clock\|Power'

1.thumb.png.61a8465da0ebc85c9548ed86c3f8bdc1.png

Ok, now I've understood you :angel:,. In the mean time you can try to create this two folders inside your Desktop and restart the application?

 

HWBadSensors                 HWGraphics

debug.png.475cc54af9c66905c1dca90a10fb1a9c.png

 

See if values show up and please, post a ioreg and the "HWGraphics" folder only.

 

Edited by vector sigma
typo

Share this post


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

好的,现在我已经了解你了  :天使:与此同时,您可以尝试在桌面内创建这两个文件夹并重新启动应用程序?

debug.png.475cc54af9c66905c1dca90a10fb1a9c.png

1.thumb.png.4351deba37ccd5f624385039b89fb5ab.png

看看是否显示值,请发布ioreg和“HWGraphics”文件夹。

 

 

11 minutes ago, vector sigma said:

好的,现在我已经了解你了  :天使:与此同时,您可以尝试在桌面内创建这两个文件夹并重新启动应用程序?

debug.png.475cc54af9c66905c1dca90a10fb1a9c.png

 

看看是否显示值,请发布ioreg和“HWGraphics”文件夹。

 

 

HWGraphics.zip

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

  • Similar Content

    • By miliuco
      Install macOS 10.15 Catalina on Gigabyte P55-USB3 with Radeon RX 580 graphics card using a USB device created with the createinstallmedia command and Clover as bootloader. Instructions to install macOS 10.14 Mojave on this computer are almost identical, replacing Catalina app with Mojave, so this article is suitable for both versions of macOS. The Gigabyte P55-USB3 motherboard (and some others from the same brand with the P55 / H55 chipset) have made it easy to build a hackintosh and install macOS since 10 years ago. Although it is an old motherboard, the behavior with Mojave or Catalina is very good after changing the classic hard drive (HDD) for a solid state drive (SSD).

      Components of the hackintosh
      Gigabyte GA-P55-USB3 motherboard: P55 chipset, 1156 socket, ALC892 audio, Gigabit RTL8111D network, DDR3 RAM Intel Core i5-750 processor for socket 1156: 4 cores, 8MB cache, clock rate 2.66 GHz Fenvi FV-T919 wireless + Bluetooth card: PCI-Express, wifi is ac type, detected by macOS as Airport and Apple Bluetooth Radeon RX 580 8 GB graphics card: works OOB but with a few details to be considered, it has its own article.  
      Previous requirements
      Install macOS Catalina app in /Applications folder USB flash drive with at least 16GB prepared from Disk Utility with MBR partition scheme and formatted as Mac Os Plus (on older Gigabyte boards like mine, USB sticks partitioned with GUID scheme instead of MBR usually hang the system when booting) Recent version of Clover (I have used r5117) Recent versions of Lilu (at least 1.4.4) and WhateverGreen (at least 1.3.9) to fine-tune the behavior of the graphics card Recent version of RealtekRTL8111 (I have used 2.2.2) FaceSMC version 6.26-322 (newer versions disable automatic mounting of USB devices on my system).  
      Create install USB
      Run this command from Terminal (assuming the target device is called USB):
      Bash: sudo /Applications/Install\ macOS\ Catalina.app/Contents/Resources/createinstallmedia --volume /Volumes/USB /Applications/Install\ macOS\ Catalina.app
      Clover must be installed on the USB memory, I choose the following options:
      Bootloader > Install boot0af on the MBR CloverEFi > CloverEFI 64-bit SATA BIOS Drivers, 64 bit > Recommended drivers > FSInject + SMCHelper + XhciDxe BIOS Drivers, 64 bit > File System drivers > ApfsDriverLoader Install RC scripts on selected volume Optional RC scripts > Disable sleep proxy client.  
      You have to copy 4 kexts to the EFI/CLOVER/kexts/Other folder of the USB device: FaceSMC 6.26-322, Lilu 1.4.4, WhateverGreen 1.3.9 and RealtekRTL8111 2.2.2. Regarding the config.plist file, the most significant is:
      Boot > kext-dev-mode = 1 in Boot arguments GUI > Theme embedded, EmbeddedThemeType Dark, Screen Resolution 1920x1080, Preboot in Hide Volume Graphics > blank, nothing is checked except if foxbox solution is used to have more than 2 connectors enabled RT Variables > 0x28 in BooterConfig and 0x67 in CsrActiveConfig SMBios > iMac14,2 Sytem Parameters> Yes in Inject Kexts and check Inject System ID.  
      Install macOS Catalina

      Boot from the USB device and choose Install macOS from Install macOS Catalina. The installation program runs until the PC restarts. Here choose Install macOS from HDD (the name of the volume you are installing macOS on). With RX 580 graphics card, the screen goes black in this second phase of the installation, it is a phase in which the user has nothing to do until the PC is restarted so you can let it work until the Clover menu again. You have to choose Boot macOS from HDDto boot the installed system from the hard disk, the screen is recovered and you can configure the account and the initial options. From this moment the screen works fine.

      In summary:
      Boot from USB > Clover menu > Install macOS from Install macOS Catalina > screen works fine Boot from USB > Clover menu > Install macOS from HDD > black screen Boot from USB > Clover menu > Boot macOS from HDD > screen works fine.  
      Install Clover and kexts on the hard drive

      Clover needs to be installed on the disk where we just installed macOS. Options are the same as when installing it on the USB memory. You also have to copy the 4 kexts (FaceSMC 6.26-322, Lilu 1.4.4, WhateverGreen 1.3.9 and RealtekRTL8111 2.2.2) into the EFI/CLOVER/kexts/Other folder on the EFI partition of the disk. And review the config.plist file remembering the comments for the USB.

      If everything goes well, the computer starts from the hard disk with a running copy of macOS Catalina.
       
       

    • By Slice
      The thread splitted from HWSensors3.
       
      Tools to testing Radeon state.
      Load RadeonPCI.kext  
      RadeonPCI.kext.zip
       
      How to load
      sudo chown -R root:wheel ~/Downloads/RadeonPCI.kext sudo chmod -R 755 ~/Downloads/RadeonPCI.kext sudo kextutil -v ~/Downloads/RadeonPCI.kext and use RadeonDump utility
      RadeonDump1.zip
       
      Commands to see temperature
      Polaris
      ./RadeonDump1 -n 6b0,c0300014
      SeaIsaland
      ./RadeonDump1 -n 200,c0300014
       
      Old families
      ./RadeonDump1 -r 714,7f4
       
      Other possible methods to find a register for temperature
      ./RadeonDump1 -n 6b0,c0300e0c
      ./RadeonDump1 -n 6b0,1c5
      ./RadeonDump -n 6b0,d8200ca4
      ./RadeonDump -r 59800,59810
      ./RadeonDump -r 678,680

       
       
       
      01.12.2017
      Latest solution RadeonMonitor.kext here
      works for RX 460,480,580
      not works for HD7790, R9 290X?
       
      06.12.2017
      Here works also with HD7790, R9 290X
       
      14.12.2017
      Support VEGA here
       
      13.12.2017
      Version for test modern cards
      RadeonPCI5.kext.zip
       
      06.04.2020
      Version for Catalina
      RadeonPCI5-v2.kext.zip
    • 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.
       
×