Jump to content

2,089 posts in this topic

Recommended Posts

Advertisement
15 minutes ago, pico joe said:

@Slice my RX 460 show fans monitoring

This depend by the OS driver and not by the plugins. Don't know if that happens on a not supported id(??) and we cannot do other then hide those values. Only when aren't good values. I'll do that in a next commit as soon as I'll have time.

Edited by vector sigma
typo

Share this post


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

Guys, ooc what can be a max value for a Fan? How many rpm can have a pump?

There is no physical limits because drive has DC power.

But in common sense it will not be more then 4000rpm.

Share this post


Link to post
Share on other sites
On 4/5/2019 at 6:07 PM, vector sigma said:

Guys, ooc what can be a max value for a Fan? How many rpm can have a pump?

 

Mine actually run at under 1k (Noctua) :thumbsup_anim:

Share this post


Link to post
Share on other sites

v2.4.6 (r195) no rpm on RX64 GPU:

 

1550216657_2019-04-1021_40_23.png.0aee469794c5b7945f7844db8176b8fd.png

 

The vclist it shows ok:

 

[losinka@imac]:~/Downloads$ ./vclist
----------------------------------------------------
vclist (vector sigma 2018), found 3 graphics cards!
----------------------------------------------------
Model               = Intel HD Graphics 530
vendor ID           = <86800000>
vendor ID           = <12190000>
revision ID         = <06000000>
subsystem ID        = <00d00000>
sub system VendorID = <58140000>


Device Utilization  = 0%
vram Used           = 71426048 bytes
vram Free           = 7444766720 bytes
----------------------------------------------------
Model               = Radeon RX Vega 64
vendor ID           = <02100000>
vendor ID           = <7f680000>
revision ID         = <c1000000>
subsystem ID        = <7fe30000>
sub system VendorID = <a21d0000>


Device Utilization  = 0%
Total Power         = 10 Watts
Temperature         = 42°
Fan Speed           = 0 RPM
Fan Speed           = 36%
vram Used           = 63299584 bytes
vram Free           = 314453952 bytes
----------------------------------------------------
Model               = Radeon Vega Frontier Edition
vendor ID           = <02100000>
vendor ID           = <63680000>
revision ID         = <00000000>
subsystem ID        = <766b0000>
sub system VendorID = <02100000>


Device Utilization  = 0%
Total Power         = 7 Watts
Temperature         = 27°
Fan Speed           = 673 RPM
Fan Speed           = 13%
vram Used           = 7208960 bytes
vram Free           = 16934801344 bytes


[losinka@imac]:~/Downloads$

 

upd: No FAN's on this version:

 

1219306799_2019-04-1021_56_54.png.bcc25610cf5fe5ad8a7698f120f193b3.png

Edited by losinka

Share this post


Link to post
Share on other sites

Hi Slice,

 

HwmonitorSMC2 conflicts with iojones (1.2.2, 1.1) and ioregistry explorer( 1.x, 2.x , 3.x) :

 

whenever hwmonitorSMC2 is running, iojones keeps crashing, and ioregistry explorer will be extremely slow to open and to browse. Quit it solves the issue.

 

can you take a look at it? Thanks.  

Share this post


Link to post
Share on other sites
20 hours ago, losinka said:

v2.4.6 (r195) no rpm on RX64 GPU:

 

1550216657_2019-04-1021_40_23.png.0aee469794c5b7945f7844db8176b8fd.png

 

The vclist it shows ok:

 


[losinka@imac]:~/Downloads$ ./vclist
----------------------------------------------------
vclist (vector sigma 2018), found 3 graphics cards!
----------------------------------------------------
Model               = Intel HD Graphics 530
vendor ID           = <86800000>
vendor ID           = <12190000>
revision ID         = <06000000>
subsystem ID        = <00d00000>
sub system VendorID = <58140000>


Device Utilization  = 0%
vram Used           = 71426048 bytes
vram Free           = 7444766720 bytes
----------------------------------------------------
Model               = Radeon RX Vega 64
vendor ID           = <02100000>
vendor ID           = <7f680000>
revision ID         = <c1000000>
subsystem ID        = <7fe30000>
sub system VendorID = <a21d0000>


Device Utilization  = 0%
Total Power         = 10 Watts
Temperature         = 42°
Fan Speed           = 0 RPM
Fan Speed           = 36%
vram Used           = 63299584 bytes
vram Free           = 314453952 bytes
----------------------------------------------------
Model               = Radeon Vega Frontier Edition
vendor ID           = <02100000>
vendor ID           = <63680000>
revision ID         = <00000000>
subsystem ID        = <766b0000>
sub system VendorID = <02100000>


Device Utilization  = 0%
Total Power         = 7 Watts
Temperature         = 27°
Fan Speed           = 673 RPM
Fan Speed           = 13%
vram Used           = 7208960 bytes
vram Free           = 16934801344 bytes


[losinka@imac]:~/Downloads$

 

upd: No FAN's on this version:

 

1219306799_2019-04-1021_56_54.png.bcc25610cf5fe5ad8a7698f120f193b3.png

The r195's commit says "don't show bad sensors". fans that says 0 rpm are hide. Anyway if you want to see bad sensors create a file (or a directory) to your Desktop called HWBadSensors:

touch ~/Desktop/HWBadSensors

and restart the app. Tell me if those sensors show up.

Share this post


Link to post
Share on other sites
18 hours ago, justin said:

HwmonitorSMC2 conflicts with iojones (1.2.2, 1.1) and ioregistry explorer( 1.x, 2.x , 3.x) :

Untrue. HwmonitorSMC2 read the IOKit registry using IOKit framenwork, just like the apps mentioned by you. Each time you poll the IO registry the IOKit framework create a snapshot of it, and to do that ..it create a lock (a mutex) to avoid concurrency operations on multiple threads, i.e. it put threads to wait each other. Matter of nanoseconds. 
 

18 hours ago, justin said:

ioregistry explorer will be extremely slow to open and to browse. Quit it solves the issue.

Both iojones and ioregistry explorer do additional tasks like listening for changes while HWMonitorSMC just poll each time you have set in the settings.

Basically you can't blame no one if you want access the same resource  from different apps.

A remedy is only to:

  1. use one of them at time
  2. or disable some sensors (you can do that)
  3. or slow down with polling time of the sensors
  4. or just open, for example IORegistryExplore.app and save the snapshot and watch it off line (i.e. not in real time)....and you should do that.

 

18 hours ago, justin said:

whenever hwmonitorSMC2 is running, iojones keeps crashing

Wrong assumption. Tell that to the developer of iojones since it is his app that crash:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x00007fff7a843258 objc_retain + 24
1   net.sourceforge.IOJones       	0x000000010e476f17 0x10e46b000 + 48919
2   net.sourceforge.IOJones       	0x000000010e4730fc 0x10e46b000 + 33020
3   net.sourceforge.IOJones       	0x000000010e471a4d 0x10e46b000 + 27213
4   net.sourceforge.IOJones       	0x000000010e46fcfc 0x10e46b000 + 19708
5   net.sourceforge.IOJones       	0x000000010e46fe1d 0x10e46b000 + 19997
6   com.apple.framework.IOKit     	0x00007fff524988c8 IODispatchCalloutFromCFMessage + 181
7   com.apple.CoreFoundation      	0x00007fff4fb9d858 __CFMachPortPerform + 282
8   com.apple.CoreFoundation      	0x00007fff4fb9d732 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
9   com.apple.CoreFoundation      	0x00007fff4fb9d690 __CFRunLoopDoSource1 + 527
10  com.apple.CoreFoundation      	0x00007fff4fb8577e __CFRunLoopRun + 2535
11  com.apple.CoreFoundation      	0x00007fff4fb84b45 CFRunLoopRunSpecific + 459
12  com.apple.HIToolbox           	0x00007fff4ee639db RunCurrentEventLoopInMode + 292
13  com.apple.HIToolbox           	0x00007fff4ee63715 ReceiveNextEventCommon + 603
14  com.apple.HIToolbox           	0x00007fff4ee634a6 _BlockUntilNextEventMatchingListInModeWithFilter + 64
15  com.apple.AppKit              	0x00007fff4d1fe90b _DPSNextEvent + 965
16  com.apple.AppKit              	0x00007fff4d1fd6a3 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361
17  com.apple.AppKit              	0x00007fff4d1f77c0 -[NSApplication run] + 699
18  com.apple.AppKit              	0x00007fff4d1e6d00 NSApplicationMain + 777
19  libdyld.dylib                 	0x00007fff7bfdd3d5 start + 1

..looks like the error relates accessing deallocated memory.

HWMonitorSMC2 open/close connections with different drivers which can make iojones under a condition, i.e. a bug (from it),

in fact as you can see IORegistry explorer doesn't crash.

Edited by vector sigma
typo

Share this post


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

The r195's commit says "don't show bad sensors". fans that says 0 rpm are hide. Anyway if you want to see bad sensors create a file (or a directory) to your Desktop called HWBadSensors:


touch ~/Desktop/HWBadSensors

and restart the app. Tell me if those sensors show up.

This is a not "bad sensors": in idle, Vega RX64 shows 0rpm but in load the RPM's are more than "0"

 

"touch ~/Desktop/HWBadSensors" return the Vega fan back, but did not return the other fan's:

 

708564964_2019-04-1021_56_54.png.951eab214157c0c39d01ca9c1c7b7698.png

 

v2.4.5 is ok

 

Grazie mille! :)

Edited by losinka

Share this post


Link to post
Share on other sites
1 minute ago, losinka said:

This is a not "bad sensors": in idle, Vega RX64 shows 0rpm but in load the RPM's are more than "0"

Ok, that explain a lot. The app doesn't know when it is in idle mode, but a dump made with HWMonitorSMC2 in idle state first, an then in fully operational state  can make me understand if I can detect both modes and so be sure the fans reading is 0 because is idle or just is a bad value.

 

2 minutes ago, losinka said:

"touch ~/Desktop/HWBadSensors" return the Vega fan back, but did not return the other fan's:

try:HWMonitorSMC2.app.zip 

Share this post


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

Ok, that explain a lot. The app doesn't know when it is in idle mode, but a dump made with HWMonitorSMC2 in idle state first, an then in fully operational state  can make me understand if I can detect both modes and so be sure the fans reading is 0 because is idle or just is a bad value.

 

try:HWMonitorSMC2.app.zip 

 

I do not see disconnected fan. It is normal?

 

1139393177_2019-04-1123_06_28.png.8cb0fb389dc6bfb1811dfb95e20fe543.png765149035_2019-04-1123_07_41.png.b18f42476c9c190fba7c8acf0cc426f0.png

Share this post


Link to post
Share on other sites
4 minutes ago, losinka said:

Now shows good, thank you!

can I have those dumps?

45 minutes ago, vector sigma said:

Ok, that explain a lot. The app doesn't know when it is in idle mode, but a dump made with HWMonitorSMC2 in idle state first, an then in fully operational state  can make me understand if I can detect both modes and so be sure the fans reading is 0 because is idle or just is a bad value

 

Share this post


Link to post
Share on other sites
18 minutes ago, vector sigma said:
  1. dump with egpu in idle state
  2. dump with egpu in power state

you give me only 2., I need both to compare. Cпасибо

 load.zip & idle.zip

 

upd: Only RX64 has a 0rpm in idle. VegaFE has always more than "0".

load.zip

Edited by losinka

Share this post


Link to post
Share on other sites
On 4/12/2019 at 3:51 AM, vector sigma said:

Ok, that explain a lot. The app doesn't know when it is in idle mode, but a dump made with HWMonitorSMC2 in idle state first, an then in fully operational state  can make me understand if I can detect both modes and so be sure the fans reading is 0 because is idle or just is a bad value.

 

try:HWMonitorSMC2.app.zip 

@vector sigma

Hi, HWMonitorSMC2.app 2.4.6 version, the menu bar icon is asymmetrical, the spacing between the two sides is not coordinated, it looks very awkward, how can I change it? Or can you change it in the next version?

1.png

2.png

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.

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