Jump to content

2,089 posts in this topic

Recommended Posts

Advertisement
3 hours ago, vector sigma said:

No grid = no horizontal grid, no vertical grid

Dashed Horizontally = it has only the dashed horizontal grid

 

Andrey, try this: HWMonitorSMC2.app_gridColor.zip

With option "grid color", now I see a difference.
Works good, thanks.

Edited by Andrey1970

Share this post


Link to post
Share on other sites
10小时前,矢量西格玛说:

一切都很好,没有任何人的愤怒。法布里森和我?我们有同样的脾气.....任何人都没有问题,也没有问题。

I see. It seems that we need to abandon the "slice" non-renewal sensor. After adjusting, I got what I wanted. I haven't looked carefully at the previous discussion. I'm sorry.

Share this post


Link to post
Share on other sites
On 11/26/2018 at 8:09 AM, Alpha22 said:

vector sigma 

possible to have the latest version to try

thank 

There's no latest version other then last one you can find here: https://sourceforge.net/projects/hwsensors3.hwsensors.p/files/.

The very very latest is under testing by me and not commited, but soon I'll post it to let you try before doing a commit.

 

Share this post


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

The app read everythings is connected through pci and has a gpu compatible class-code. Everything is fine becouse macOS connect thunderbolt devices like that as pci devices. The IOAccelerator is what we need to show properties of your card because contains the "PerformanceStatistics", but eGPU doesn't respond to this class and "PerformanceStatistics" is published under a children of display0 (or whatever it is connected).

So, I need to think on how retrieve those info before, and then create code to try:)

Edited by vector sigma

Share this post


Link to post
Share on other sites

FYI only

The information in the ioreg is true. The first two strings is Vega RX64 and the second two strings is VegaFE.

[losinka@mac-pro]:~/Downloads$ ioreg -l | perl -lne 'print $1, $2 while /(?:"PerformanceStatistics".*\K("Temperature\(C\)"=\d+)|("Fan Speed\(RPM\)"=\d+))/g'
"Fan Speed(RPM)"=1510
"Temperature(C)"=28
"Fan Speed(RPM)"=2011
"Temperature(C)"=22
[losinka@mac-pro]:~/Downloads$

 

Share this post


Link to post
Share on other sites

My RX580 GPU not showing in HWMonitorSMC2 App.

This is what I did:

I just downloaded HWSensors3 DMG from SF.

I removed my existing FakeSMC.kext from E/C/K/Other (and related sensor kexts).

I copied the new FakeSMC, IntelCPUMonitor, ITEIT87x and RadeonMonitor to E/C/K/Other and rebooted.

 

HWMonitorSMC2 App shows no GPU:1505120447_Screenshot2018-12-10at16_57_21.png.9750a903763862cb3aeb9c9fa6e38e23.png

 

Then I go into preferences for the App and tick the box "Use IOAccelerator's monitoring for GPUs" and restarted the App.

 

Now I see :

1968251761_Screenshot2018-12-10at16_58_30.png.49dc66513067afe7e350c44d02e6509e.png

 

So, what is the point of RadeonMonitor.kext ?

How to display GPU info without  ticking "Use IOAccelerator's monitoring for GPUs" box ?

 

Edited by MacNB
typo

Share this post


Link to post
Share on other sites

Hi, I'd like to know what I could do to improve those readings. No doubt those reading are wrong. Here're some info from HWMonitor dump.

My config: Asus Prime Z370A + 8700K + GTX650Ti

Mainboard Model		PRIME Z370-A

LPCIO
-------------------------------------------------------------------------

LPCIO Vendor			Nuvoton
LPCIO Model			NCT6793/NCT5563
LPCIO Vendor ID			0x5CA3
LPCIO Chip ID			0xD1
LPCIO Revision ID		0x21

Hardware monitor		Nuvoton NCT6791D
	Voltage 0		5.08 Volts [0x7F] (+5V)
	Voltage 1		3.38 Volts [0xD3] (+3.3V)
	Voltage 2		12.29 Volts [0x80] (+12V)
	Voltage 3		1.07 Volts [0x86] (VIN3)
	Voltage 4		1.94 Volts [0x79] (VIN4)
	Voltage 5		0.67 Volts [0x2A] (VCORE)
	Temperature 0		28 degC (82 degF) [0x1C] (Mainboard)
	Temperature 1		30 degC (86 degF) [0x1E] (CPU)
	Temperature 2		28 degC (82 degF) [0x1C] (TMPIN2)
	Temperature 3		30 degC (86 degF) [0x1E] (TMPIN3)
	Temperature 5		50 degC (122 degF) [0x32] (TMPIN5)
	Temperature 6		22 degC (71 degF) [0x16] (TMPIN6)
	Fan 1			830 RPM [0x33E] (CPU)

 

image.thumb.png.c6273cdd2c274b2d489c783f5d4e5555.png

Edited by p.H

Share this post


Link to post
Share on other sites

Hi Guys,

 

I recently swapped out my old GTX980Ti for a Vega 64 Liquid Cooled GPU in my video edit Hack so i could update to Mojave (now running 10.14.2)

I wanted to see what sort of temps .. etc the Vega was running at so I removed the old HWMonitor App, FakeSMC and Sensor plugins 

and installed the latest HWMonitorSMC2 App and the FakeSMC, IntelCPUMonitor & W836x kexts and enabled the option to use the IOAccelerator's for GPU Monitoring.

 

It works great and i can finally monitor whats going on with my Vega 64 ... great work guys !!

 

However there is something very odd going on with the Vega 64 Total Power reading ..

If i run a benchmark like FurMark in the default window mode then the Power reading seems about right at around 360W (yes Vega 64 really are that power hungry)

 

1470509963_Screenshot2018-12-20at00_15_30.png.e52009579ef46acf6c30d6bc93f2e5ea.png

 

However if i run FurMark (or any other Benchmark) in fullscreen (3440x1440) the reading almost doubles to around 680W which is obviously incorrect

 

970062433_Screenshot2018-12-20at00_15_55.png.c7a2562b695be9040dfebf87a038f300.png

 

I know AMD Vega's are power hungry devices but that clearly is not correct, the result is the same with any app that uses the GPU for 3D Open GL/CL Rendering

such as Vally, Heaven, FurMark  ... etc,  if the output is windowed the Total Power seems correct, but if i run it full screen then Total Power is crazy high ??

 

When running heaven or valley in window mode ... the bigger the window the higher the reading ?

 

It's very strange .... has anyone else seen this issue ?

Pretty sure its a MacOS thing as if i execute the terminal command

 

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

 

It also reports incorrect Power readings when running a 3d app ad fullscreen :-

 

MonkeyMac-Pro-2018:~ Jay$ ioreg -l |grep \"PerformanceStatistics\" | cut -d '{' -f 2 | tr '|' ',' | tr -d '}' | tr ',' '\n'|grep 'Temp\|Fan\|Power'
"Fan Speed(%)"=45
"Fan Speed(RPM)"=1501
"Temperature(C)"=33
"Total Power(W)"=683
MonkeyMac-Pro-2018:~ Jay$ 

 

Cheers

Jay

 

 

Edited by jaymonkey

Share this post


Link to post
Share on other sites

It is already great achievement if you can start macOS on such hardware. Sensors monitoring looks to be a minor problem.

Test HWMonitorSMC2.app and report what is wrong.

 

Share this post


Link to post
Share on other sites
19 hours ago, p.H said:

Hi, I'd like to know what I could do to improve those readings. No doubt those reading are wrong.

 

About Voltages  ... You need to find or calculate correct Ri/Rf for your motherboard and place it into kext info.plist

These values can be found in Linux LMSensors sources, sometimes in DSDT

Example

<key>VIN3</key>

<dict>

<key>Name</key>

<string>3VCC</string>

<key>Rf</key>

<integer>100</integer>

<key>Ri</key>

<integer>100</integer>

<key>VRef</key>

<integer>0</integer>

</dict>

 

 

Edited by Rodion2010

Share this post


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

It is already great achievement if you can start macOS on such hardware. Sensors monitoring looks to be a minor problem.

Test HWMonitorSMC2.app and report what is wrong.

 

Already got macos 10.13.6 installed and booted up : )
i also got macos 10.13.6 installed on many other AMD Threadripper 1950x systems but they all dont show temperatures. same problem as with this system.

here is a pic from one of the 1950x system.
Screen_Shot_2018-12-20_at_7_30.06_AM.png.382dde194026ebcd3c14ed7948d96aad.png

 

For temperature the kexts i used is :
1954362515_ScreenShot2018-12-20at5_33_26PM.png.912b537da190d34b81eb0396da7cf1f3.png

in HWmonitorSMC.app it only shows GPU temp and nothing else.
 

Edited by XLNC

Share this post


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

 

About Voltages  ... You need to find or calculate correct Ri/Rf for your motherboard and place it into kext info.plist

These values can be found in Linux LMSensors sources, sometimes in DSDT

Example

<key>VIN3</key>

<dict>

<key>Name</key>

<string>3VCC</string>

<key>Rf</key>

<integer>100</integer>

<key>Ri</key>

<integer>100</integer>

<key>VRef</key>

<integer>0</integer>

</dict>

 

 

 

Thanks for your suggestion. https://github.com/lm-sensors/lm-sensors/tree/master/configs This is the place where I tried to find my config. But I did not find it though.

Just to maker sure I am searching the right place.

Share this post


Link to post
Share on other sites
On 12/9/2018 at 9:23 PM, losinka said:

FYI only

The information in the ioreg is true. The first two strings is Vega RX64 and the second two strings is VegaFE.


[losinka@mac-pro]:~/Downloads$ ioreg -l | perl -lne 'print $1, $2 while /(?:"PerformanceStatistics".*\K("Temperature\(C\)"=\d+)|("Fan Speed\(RPM\)"=\d+))/g'
"Fan Speed(RPM)"=1510
"Temperature(C)"=28
"Fan Speed(RPM)"=2011
"Temperature(C)"=22
[losinka@mac-pro]:~/Downloads$

Yes the second reading comes from the display where a eGPU is attached

 

On 12/20/2018 at 1:29 AM, jaymonkey said:

Hi Guys,

 

I recently swapped out my old GTX980Ti for a Vega 64 Liquid Cooled GPU in my video edit Hack so i could update to Mojave (now running 10.14.2)

I wanted to see what sort of temps .. etc the Vega was running at so I removed the old HWMonitor App, FakeSMC and Sensor plugins 

and installed the latest HWMonitorSMC2 App and the FakeSMC, IntelCPUMonitor & W836x kexts and enabled the option to use the IOAccelerator's for GPU Monitoring.

 

It works great and i can finally monitor whats going on with my Vega 64 ... great work guys !!

 

However there is something very odd going on with the Vega 64 Total Power reading ..

If i run a benchmark like FurMark in the default window mode then the Power reading seems about right at around 360W (yes Vega 64 really are that power hungry)

 

1470509963_Screenshot2018-12-20at00_15_30.png.e52009579ef46acf6c30d6bc93f2e5ea.png

 

However if i run FurMark (or any other Benchmark) in fullscreen (3440x1440) the reading almost doubles to around 680W which is obviously incorrect

 

970062433_Screenshot2018-12-20at00_15_55.png.c7a2562b695be9040dfebf87a038f300.png

 

I know AMD Vega's are power hungry devices but that clearly is not correct, the result is the same with any app that uses the GPU for 3D Open GL/CL Rendering

such as Vally, Heaven, FurMark  ... etc,  if the output is windowed the Total Power seems correct, but if i run it full screen then Total Power is crazy high ??

 

When running heaven or valley in window mode ... the bigger the window the higher the reading ?

 

It's very strange .... has anyone else seen this issue ?

Pretty sure its a MacOS thing as if i execute the terminal command

 

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

 

It also reports incorrect Power readings when running a 3d app ad fullscreen :-

 


MonkeyMac-Pro-2018:~ Jay$ ioreg -l |grep \"PerformanceStatistics\" | cut -d '{' -f 2 | tr '|' ',' | tr -d '}' | tr ',' '\n'|grep 'Temp\|Fan\|Power'
"Fan Speed(%)"=45
"Fan Speed(RPM)"=1501
"Temperature(C)"=33
"Total Power(W)"=683
MonkeyMac-Pro-2018:~ Jay$ 

 

Cheers

Jay

 

 

These values are just read from the ioreg with no interpretation, i.e. HWMonitorSMC2.app just read what your driver says just as you can do using the Terminal. But, why do you think they are wrong?

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