Update broke sensor detection.
iDumle opened this issue · comments
Describe the bug
Update V187 broke sensor detection for GPU Core for my AMD Radeon 6650 XT graphics card and it's now showing an incorrect/frozen value.
On version 186 the setup was working fine, and the software had no problem detecting the GPU Core sensor, I'm now using GPU Hot Spot instead as that seems to be updating its values.
Right after update the value was stuck at 468 'c, I then tried restarting twice after the update and the error persisted after reboot though GPU core showed a value of 0 'c and then subsequently 8 'c.
I have tried Refresh sensors detection, but it didn't change a thing it's still stuck on the same value.
Is there a log.txt file next to FanControl.exe with recent date entries?
The Error log show no resent entry, though there is one from back in January I suspect it's unrelated, but just in case I'll post it.
log.txt
Relevant hardware specs and setup
The graphics card is a ASUS Radeon RX 6650 XT DUAL OC - 8GB, and I am running window 10, and the newest graphics drivers 24.3.1.
And here is a picture of the whole Fan Control Setup.
With my 7900XT, after update (187) for gpu sensors it only shows the VRSoC temp, where before it showed core and hot spot. Reverted (to 186) and it was fixed.
Windows 11, Powercolor Hellhound 7900XT, 24.3.1 drivers.
I lost all my custom fan names and paired sensors with update 187.
I restored 186 from a backup and all was fine again.
I think update 187 needs to be looked at.
After digging around a bit, I saw your repo for LibreHardwareMonitor had a resent commit 2 days ago and you added that update to v187, I suspect something went wrong in the d22cd1d commit.
So with that I tried swapping LibreHardwareMonitorLib.dll from v186 in to my v187 install and that restored the sensor functionality.
Similar issue, RX 6800, gpu core and liquid showing temps >3000°, gpu hot spot showing a sensible value. Happy to do more to diagnose/whatever, but for now I've just changed the sensor used to the hot spot.
Yeah there is a new method implemented to get sensor values, but there might be a bug in there.
pmlog.zip
I compiled this: https://github.com/GPUOpen-LibrariesAndSDKs/display-library/blob/master/Sample/PMLog/PMLog.cpp
If anyone here is willing to run it and show the output, might be of some help.
I've compiled a test build of LibreHardwareMonitor with a possible fix for the issue. If the users with RX 6000 cards can test, will be useful (LibreHardwareMonitorLib.dll included in zip). The temps should be shown correctly with this build. A test copying the new
LibreHardwareMonitorLib to fancontrol would be useful too.
Yeah there is a new method implemented to get sensor values, but there might be a bug in there. pmlog.zip
I compiled this: https://github.com/GPUOpen-LibrariesAndSDKs/display-library/blob/master/Sample/PMLog/PMLog.cpp
If anyone here is willing to run it and show the output, might be of some help.
@Rem0o
I ran the pmlog file and no output was given to me, a terminal existed for maybe 0.2 sekunds but I am unable to catch if anything is written in it, so I'm not sure how I'm suppose to get an output for you.
I've compiled a test build of LibreHardwareMonitor with a possible fix for the issue. If the users with RX 6000 cards can test, will be useful (LibreHardwareMonitorLib.dll included in zip). The temps should be shown correctly with this build. A test copying the new LibreHardwareMonitorLib to fancontrol would be useful too.
@epinter
I ran the Libre hardware monitor and all the sensor seems to be working correctly, I opened a game and the temp in LHM corresponded to the temp show by the in game monitor.
I swapped the LibreHardwareMonitorLib.dll file from LHM to Fan Control v187 folder and ran the software again, and it seems to be working fine now.
@iDumle
The pmlog sample @Rem0o sent is an official sample from AMD that uses that feature pmlog to collect sensors. To run it, you can use these parameters: pmlog.exe s 0 1000 1000.
Anyway, if the test build shows the values correctly, some boards of RX 6000 series doesn't work with pmlog feature. I will send a PR to LibreHardwareMonitor excluding these boards and use the old method. It's weird that pmlog worked for me with a RX 6750 XT.
Thanks for the test and feedback!
I ran pmlog again with the parameters you gave me and was able to see the output.
I hope it all helps, and your welcome I am glad I can be helpful, It's a fantastic software you guys are building, so just happy to be of aid.
I noticed that pmlog is detecting an edge temp sensor so I ran it in the background while running overwatch and pmlog is updating the temp correctly and it matches with the temp sensor in overwatch.
This should be the same sensor that v187 LibreHardwareMonitorLib.dll was trying to monitor with the new method right?
Not sure what's going on but I though i'd mention it.
I noticed that pmlog is detecting an edge temp sensor so I ran it in the background while running overwatch and pmlog is updating the temp correctly and it matches with the temp sensor in overwatch.
This should be the same sensor that v187 LibreHardwareMonitorLib.dll was trying to monitor with the new method right? Not sure what's going on but I though i'd mention it.
That's weird. Something is breaking the pmlog inside the librehardwaremonitor and not in this sample. I think it's better to make RX 6000 to use old method to collect sensors.
That's weird. Something is breaking the pmlog inside the librehardwaremonitor and not in this sample. I think it's better to make RX 6000 to use old method to collect sensors.
The saying "If it ain't broken, don't fix it" comes to mind :) that said if you at some point decide to give the new method a once over again I'd be happy to test it out.
I'm having the same kind of issue with my 7800 XT, sensors value are corrupted, so fancontrol looses its mind and ramps the fans all the way up. Went back to 186 and no more issue.
I'm having the same kind of issue with my 7800 XT, sensors value are corrupted, so fancontrol looses its mind and ramps the fans all the way up. Went back to 186 and no more issue.
7800 XT doesn't have problems with the build LibreHardwareMonitor fancontrol 187 is based, actually the sensors of 7800 was fixed by that build. Try the build I posted above.
@iDumle
Can you test this LHM build ? It's unchanged, using the new method to get the sensors. Just to be sure, check if all the sensors are stable and match amd adrenalin, or if you get something weird.
@epinter
So I just ran LHM in the background while running overwatch, and as far as I can see the sensors are working fine and lines up with the one in overwatch and amd adrenalin.
So something seems to gets missaligned from LHM to Fan Control.
@epinter So I just ran LHM in the background while running overwatch, and as far as I can see the sensors are working fine and lines up with the one in overwatch and amd adrenalin.
So something seems to gets missaligned from LHM to Fan Control.
Thanks for the test! So LHM is working.
Okay I properly should have done this from the start(feeling a little dumb I didn't do this to begin with), given the new test I did, I tried a complete redownload of v187 and imported my old config, and It seems to working as it should, so now I'm thinking something went wrong with auto updating from v186 to v187 rather then v187 not working.
The downloadable LHM is not the most up to date version. I'm using the latest commit since I'm compiling it myself.
@iDumle
I'll try and make a detailed timeline of my use of the software, maybe it can shine some light on something.
- I first downloaded FanControl after seeing Jays2cent featuring it, this was done on 14/02-2023 03:58 and was version v146
- I unpacked it to its own folder inside my download folder, and it has not been moved afterwards.
- I have since not interacted with the GitHub repo up until now and all subsequent updates has happened inside the software it self when prompted.
- All updates have been without a problem, until the update from v186 to v187, immediately after the update I noted the odd behaviour, did the restarts and documented the behaviour and created this issue.
- Everything else is laid out in this post.
What the actual root course for the odd behaviour I experienced is, I can only speculated on, It could be a windows thing, or maybe related to the fact my first version was v146 and all updated was done in software and never redownloaded from repo, or it might be that I was just unlucky.
What I do know is that I have done a new install from a newly download zip of v187 from the Github repo and unpacked it to its own folder on my desktop and loaded up my old config file, and it's working fine.
I don't know if this is helpful at all but now you have it.
Something is still wonky on the v187 release for me, I just had a cold boot with the new fresh install that I though was working, and now the temp are frozen and incorrect.
Edit
@epinter
After spotting this behaviour in FanControl I ran the LHM(LibreHardwareMonitor-net472-nightly-4d6a755c.zip) you gave me, and It's broken.
I'm having the same kind of issue with my 7800 XT, sensors value are corrupted, so fancontrol looses its mind and ramps the fans all the way up. Went back to 186 and no more issue.
7800 XT doesn't have problems with the build LibreHardwareMonitor fancontrol 187 is based, actually the sensors of 7800 was fixed by that build. Try the build I posted above.
I tested the build you posted, here is the result:
In FanControl:
I don't understand... I'm running on 7800 xt for 2 weeks, no problems. I will look the code again, but I don't know why there's invalid data with some cards. What I see in common on @iDumle and @axel-lebourhis screenshots is the "GPU Memory" temperature added. The only temperature sensors on these cards are "GPU Core" and "GPU Hot Spot", as far as I know.
@axel-lebourhis When you have time, can you try to run and tell me what happens ? I'm trying to isolate some code path.
@epinter I tested the LHM and I have two results for you.
This one I did right after downloading your LHM, and it's clearly broken, the computer had been running for about 2 hours.
I then did a reboot and had LHM boot with window, and I got a different result, ran overwatch and it responded fine.
I then did a third reboot with start with windows disabled and it mirrored the 2nd test and was working fine too (I didn't screenshot it).
I hope this is informative enough, please tell me if you want additional data.
@iDumle
Do you have Valorant anticheat or any other similar anticheat running ? If so try to close/disable them next time LHM presents weird data, and restart LHM.
I do have vanguard from Valorant installed, and game guard I think it's called from Helldivers 2, but I think vanguard is the only one that starts with windows, It's hard to avoid root level anti-cheat in todays gaming.
But I'll keep and eye out for when it acts up again and try out the tests, though it's a little sporadic it seems.
@epinter
Took some time, but now I got the opportunity to test it out.
After a coldboot my fancontrol broke the sensor, so I ran the LHM you gave me, and it's also broken.
FanContol v187 look like this.
I then closed down LHM, Fancontol, and shutdown vanguard, and ran LHM again but the result stayed the same.
As I'm not playing valorant really atm I could try and uninstall it and vanguard completely if you think that could be of any help.
Though ideally they and fancontrol should be able to coexist.
@epinter Took some time, but now I got the opportunity to test it out. After a coldboot my fancontrol broke the sensor, so I ran the LHM you gave me, and it's also broken.
I then closed down LHM, Fancontol, and shutdown vanguard, and ran LHM again but the result stayed the same.
As I'm not playing valorant really atm I could try and uninstall it and vanguard completely if you think that could be of any help. Though ideally they and fancontrol should be able to coexist.
Vanguard is not the only the breaks monitoring tools. Today while testing stable builds of LHM (0.9.2 and 0.9.3), I saw EA FC 2024 breaking all CPU sensors, as soon as the game was closed all sensors worked again. Didn't affect the gpu sensors in this case.
From what I've observed, Vanguard seems to be the only one that actively run at system boot, other root-level anti cheat seems to only become active when the application is running, for example nProtect starts with the launch of Helldivers 2.
But another thing I've noticed is, sometime when Fancontrol has broken it has added these "Phantom" sensors in the menu, as shown by "GPU VR VDDC" a sensor being present in the picture I took today, a sensor not present in the Pmlog from what I can see. 5 days ago it added 4 "Phantom" sensors.
Could it be an issue with how LHM detects sensors? I am just speculating ignorant as I am.
LHM expects amd driver to deliver the sensors data correctly, if something blocks or intercepts that access to the sensor data provided by the driver, LHM can present invalid data, like a sensor that doesn't have data to return something, or a valid sensor returning wrong data. I use LHM sensors all the time, everyday while I work, I keep them open in my second display, I have zero problems with sensors on amd cards. I tested the last builds in 2 different PCs two different amd cards, no issues. I'm not saying a bug is impossible, but the probability of same gpu series have different methods to access sensors is low, like your 6650 and 6750 I tested, or the two 7800 xt.
@epinter
You said something could block or intercept the sensor data, so I spend the morning testing out a dual boot window I have on this PC, it was a system meant to be a work system I just never got around to really setting up, this setup is as clean as it gets on my PC, without me completely reformatting everything.
It's Windows 10, AMD Graphics Driver, Logitech G Hub, and Audacity, this is all that has been installed to it besides windows updates.
I spend some time restarting and opening LHM over and over, while most of the time it was only "Phantom" Sensors popping in and out of the nightly build, the temps was still updating, but on the 5 restart I got a 0 temp sensor.
Here is a screenshot of the getsensor version you gave me.
And this is of the nightly version of LHM
I think this is properly as clean of a test setup I can give of my PC, only thing I can't test is window 10 it self as my system can't run window 11.
i have the same problem with 5700xt, it is very random.. only the hotspot is updating (out of the gpu sensors)
task manager seems to be reporting fine
btw i am running just the amd driver and not the software
(and this is a pretty clean win install since it was very recent, just steam, mouse driver, sharex, powertoys, wingetui and megasync that are running)
@epinter You said something could block or intercept the sensor data, so I spend the morning testing out a dual boot window I have on this PC, it was a system meant to be a work system I just never got around to really setting up, this setup is as clean as it gets on my PC, without me completely reformatting everything. It's Windows 10, AMD Graphics Driver, Logitech G Hub, and Audacity, this is all that has been installed to it besides windows updates.
I spend some time restarting and opening LHM over and over, while most of the time it was only "Phantom" Sensors popping in and out of the nightly build, the temps was still updating, but on the 5 restart I got a 0 temp sensor. Here is a screenshot of the getsensor version you gave me.
And this is of the nightly version of LHM
I think this is properly as clean of a test setup I can give of my PC, only thing I can't test is window 10 it self as my system can't run window 11.
Good tests, thank you. That sensors that doesn't exists can be a missing support check in that nightly build, I implemented a check
for supported sensors in a new commit. The sensor with temp 0 is hard to tell, but could be something that failed to initialize when launching LHM.
A new commit was merged, I think the newer builds of LHM should help with these problems. LHM will try to detect problems with sensor data and try to get using old method if it's the case. You can download it here: https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/8859565890. Get the LibreHardwareMonitor-net472.
@epinter
I just had a cold boot on my normal system and was meet with a broken core sensor on the new LHM build you gave me.
I used the new LHM dll in fancontrol, to more easily spot when the sensor goes crazy, and this is what it looks like.
What I find puzzling is that no matter how many time I close and open the app, it's always the same broken number on the same boot, same goes for if I open the nightly build or the getsonsor version of LHM. You'd think it would try and pull new data when you open the app again, I find it weird that it just breaks/freezes on boot and then never get unstuck unless you restart.
This is weird. In the new commit that was merged, I added a check to verify that the sensor is supported and use old method if not (here), and also added a check to validate that the sensor data that came from the amd library is valid (here). If the structure is corrupted, the old method will be used, but doesn 't seems to be the case. Have you tried to save the report on LHM and see the sensors there ?
@epinter I followed this thread along, and was wondering is PMLog is the way forward for sensors with newer AMD gpus. From the what I can understand in the doc it was developped for Wattman as an Overdrive 8 binding. I believe these were discontinued/phased out? I have been developping this lately which uses ALDX, the newest SDK, used by Adrenaline. Was wondering if that would be a better way forward for LHM.
@epinter I followed this thread along, and was wondering is PMLog is the way forward for sensors with newer AMD gpus. From the what I can understand in the doc it was developped for Wattman as an Overdrive 8 binding. I believe these were discontinued/phased out? I have been developping this lately which uses ALDX, the newest SDK, used by Adrenaline. Was wondering if that would be a better way forward for LHM.
I took a look at ADLX doc recently. I think would be much better to use it for newer gpus, but by the doc, it requires Windows 10, and it's not clear what gpus are supported. I don't know the direction LHM author wants, if a Windows 10 only would be ok... I hoped a conditional PMlog and OD8 would be sufficient, and it was for the tests I made, but this case of @iDumle is weird. All tests I made worked with my amd gpus. I still have my doubts if ADLX inside LHM would work flawless.
@epinter if you are curious, built some c# bindings here and got a test console project to test stuff: https://github.com/Rem0o/ADLX/tree/main/Samples/csharp/ADLXWrapper.TestConsole
@epinter if you are curious, built some c# bindings here and got a test console project to test stuff: https://github.com/Rem0o/ADLX/tree/main/Samples/csharp/ADLXWrapper.TestConsole
I will take a look
I found an interesting problem in LHM. In my case the class that handles the amd gpu sensors was initialized 5 times, LHM was finding and trying to use 4 inactive devices. Not sure if it might be related to this issue.
Doesn't work as a library, I will work on this later.
I'm still working on it, but if you want to test this new build, I'm changing some things in the initialization of sensors...
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/8890213800
V188 seems to have fixed the issue so far
Just updated to v188 and upon update the sensors are working fine, and only the core and hot spot sensors are present in the menu, hopefully this means it's fixed, but I will respond back if something comes up.
Greetings, just here to say I too have been having these issues since v187, im using a 7800xt,
since then I had temporarily switched my primary curve control to the CPU sensor (im only controlling case fans with FanControl).
I just updated to v188 and after a couple reboots the GPU sensors and the app in general seem to be working properly.
EDIT: yep nevermind, v188 isn't working correctly and it's very inconsistent,
as im writing this my GPU sensors look like this:
V188 seems to have fixed the issue so far
nevermind seems to be still broken, my pc did crash though so that might be a factor
@iDumle I know you must be tired of all the tests you made :) , I thank you really, unfortunatelly I don't see other developer working on the amd sensors on LHM, and I'm unable to reproduce... I really want to solve this thing, at least find the real cause. If you have a time, when you see your fans completely crazy try to run LHM and save the report (in the file menu).
New build available:
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/8930980232
@epinter if you are curious, built some c# bindings here and got a test console project to test stuff: https://github.com/Rem0o/ADLX/tree/main/Samples/csharp/ADLXWrapper.TestConsole
@Rem0o
Off topic, but ... Don't you think the swig generated code is too much of a mess ? Looks like your need in fancontrol is only some sensors and fan settings... There are other ways where you implement only the part you will use, maybe it's better than maintain the whole swig generated wrapper. I saw the wrapper, you have to use cpp too. I'm making some tests with ADLX, and I'm able to use it with pure c#, now I just able to get gpu name and VRAM, but the structure of the code seems to work. I was never a fan of generated code like that of swig.
@epinter Well, not really. Actually I find it much easier to manage this way. Most stuff in ADLX uses non-static method, so instance methods on IADLXInterface objects. Without any wrapper, you would have to manage all the ptr handles to all these interface manually, still call acquire/release on them and so on.
Swig allows me to have a class per type of instance automatically, auto-creates all the Extern/DLLImport code, manage all the c++ memory stuff, plus I can join some c++ code of my own to limit the unnecessary managed/unmanged transitions, most notably with IADLXGpuMetrics, where it requires 4 native calls in total to get all the metrics (gpu temp, memory temp, rpm) and I simplified it to only 1 call.
Of course I end up using like 1/8 of the wrapper classes, but it's still 8 or 10 types of native class instance that are auto-generated for me and memory safe from the get go.
The end result is the same, just less boiler plate that is easy to mess up.
@epinter Well, not really. Actually I find it much easier to manage this way. Most stuff in ADLX uses non-static method, so instance methods on IADLXInterface objects. Without any wrapper, you would have to manage all the ptr handles to all these interface manually, still call acquire/release on them and so on.
Swig allows me to have a class per type of instance automatically, auto-creates all the Extern/DLLImport code, manage all the c++ memory stuff, plus I can join some c++ code of my own to limit the unnecessary managed/unmanged transitions, most notably with IADLXGpuMetrics, where it requires 4 native calls in total to get all the metrics (gpu temp, memory temp, rpm) and I simplified it to only 1 call.
Of course I end up using like 1/8 of the wrapper classes, but it's still 8 or 10 types of native class instance that are auto-generated for me and memory safe from the get go.
The end result is the same, just less boiler plate that is easy to mess up.
If you are already using c++, wouldn't be easier to write a small wrapper in c++ to return just what you need through static methods to c# ? A bridge, maybe using cli/c++.
If you are already using c++, wouldn't be easier to write a small wrapper in c++ to return just what you need through static methods to c# ? A bridge, maybe using cli/c++.
That's what I'm doing for some stuff, but not for everything. Still need to get the handles for every type of interface you need, and those are effectively instances, so they are easier to manage as such with the generated swig types.
@iDumle I know you must be tired of all the tests you made :) , I thank you really, unfortunatelly I don't see other developer working on the amd sensors on LHM, and I'm unable to reproduce... I really want to solve this thing, at least find the real cause. If you have a time, when you see your fans completely crazy try to run LHM and save the report (in the file menu).
I don't mind :), I'm enrolled in an IoT education, so doing issues and bug testing of each others projects is something I am familiar with, though I mostly work with python and some C on embedded systems, microcontrollers, SOC and such.
And I'm happy to try and help because I think it's an awesome software, and I do hope we can get the issues squashed so we can keep enjoying this great software.
New build available:
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/8930980232
But to the Issue at hand, I got all kinds of broken sensors in FanControl v188 today, so I ran the new LHM you linked and it's also showing a frozen Core and Hot spot sensor though without as many "phantom" sensors.
Fancontrol looked like this.
And here is what LHM looked like.
And the report is here.
LibreHardwareMonitor04-05-2024.Report.txt
One thing I've noted is that the Max value seems to be updating correctly, It's just the live update that is broken.
Here is a screenshot with me running apex in background.
Don't know if a new report is necessary, but here is one from this screenshot.
LibreHardwareMonitor04-05-2024WithApex.Report.txt
@iDumle I know you must be tired of all the tests you made :) , I thank you really, unfortunatelly I don't see other developer working on the amd sensors on LHM, and I'm unable to reproduce... I really want to solve this thing, at least find the real cause. If you have a time, when you see your fans completely crazy try to run LHM and save the report (in the file menu).
I don't mind :), I'm enrolled in an IoT education, so doing issues and bug testing of each others projects is something I am familiar with, though I mostly work with python and some C on embedded systems, microcontrollers, SOC and such. And I'm happy to try and help because I think it's an awesome software, and I do hope we can get the issues squashed so we can keep enjoying this great software.
New build available:
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/8930980232But to the Issue at hand, I got all kinds of broken sensors in FanControl v188 today, so I ran the new LHM you linked and it's also showing a frozen Core and Hot spot sensor though without as many "phantom" sensors.
Fancontrol looked like this.
And here is what LHM looked like.
And the report is here. LibreHardwareMonitor04-05-2024.Report.txt
One thing I've noted is that the Max value seems to be updating correctly, It's just the live update that is broken. Here is a screenshot with me running apex in background.
Don't know if a new report is necessary, but here is one from this screenshot. LibreHardwareMonitor04-05-2024WithApex.Report.txt
Embedded systems are nice to work with :)
Now, the report explains the issue, and it's weird, very weird:
Part of your report:
Sensor[ADL_PMLOG_CLK_GFXCLK].Value: 192
Sensor[ADL_PMLOG_CLK_GFXCLK].Value: 2
Sensor[ADL_PMLOG_CLK_GFXCLK].Value: 4
Sensor[ADL_PMLOG_CLK_GFXCLK].Value: 16842753
Sensor[ADL_PMLOG_CLK_GFXCLK].Supported: True
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 2178
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 32762
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 3
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 1
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 4
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 7
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 17
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 20
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 21
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 37
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 19
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 12
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 14
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 13
Sensor[ADL_PMLOG_CLK_MEMCLK].Supported: True
My report:
Sensor[ADL_PMLOG_CLK_GFXCLK].Value: 16
Sensor[ADL_PMLOG_CLK_GFXCLK].Supported: True
Sensor[ADL_PMLOG_CLK_MEMCLK].Value: 30
Sensor[ADL_PMLOG_CLK_MEMCLK].Supported: True
I didn't expect that.
net472-20240504-mt.zip
Try this also, please.
EDIT: I prefer if this works, it's a cleaner way.
@epinter
I have good news, both of these seems to work!
I'm still on the same boot session with the broken sensors in the old version and the new ones are working as intended.
Here is screenshot from the first one.
And here is the one you prefer.
Hopefully that mean the issue is resolved :)
Nice! I will update the commit and send you the build again from the LHM github for test, just in case...
Here, this build should work too.
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/8954631686
Here, this build should work too. https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/8954631686
Can confirm this one works too.
@iDumle
Thank you very much for all your help! Now I believe the problem was solved, I think soon the commit will be merged.
@iDumle Thank you very much for all your help! Now I believe the problem was solved, I think soon the commit will be merged.
You're welcome I'm happy to help, I do hope this will be it for this issue, and thank you for doing the work, your contribution enable us amd users to keep enjoying the software.
Latest LHMLib is in V189
Hi sorry to disappoint but V189 is still broken :/
Hi sorry to disappoint but V189 is still broken :/
I think this could be something in LHM yet. If you want to help, I can send you a build of LHM for you to collect the report. I see you have a RX 5700, we didn't test with series 5000 yet, maybe there's some adjust to make.
Sure, send it but I will need instructions :D not as well versed in this as the other guy
Sure, send it but I will need instructions :D not as well versed in this as the other guy
:)
Don't worry, do what you can, it's nothing complex... Unzip, run LibreHardwareMonitor.exe, go to menu File, click Save Report. Then just drag and drop the txt file here.
Latest LHMLib is in V189
WhenItsNOTWorking.Report.txt
WhenItsWorking.Report.txt
so i got 2 reports.. one where it was working and one where fan control failed to find 2 sensors and is reporting bonkers numbers again but looking at the LHM there it is reporting fine
so i got 2 reports.. one where it was working and one where fan control failed to find 2 sensors and is reporting bonkers numbers again but looking at the LHM there it is reporting fine
Great, thanks for the reports. Everything looks ok on both reports, the sensors found are consistent, also the data in each of the sensors. I don't see problem in LHM, let's way @Rem0o update FanControl. I was looking specially two things:
The line "Sensors Supported: 21" in the repeating adapters found, 7 in your case. This line is added to report when PMLog(method added recently to read data) sensor is found, all adapters have the same number of sensors, which is good. And the sensors data, in the build I sent to you I added a text in the report to identify if the sensor data comes from old method or new, and in your case both methods fetch the same data.
FanControl V189 uses the latest commit
of LHM : LibreHardwareMonitor/LibreHardwareMonitor@e624437
FanControl V189 uses the latest commit of LHM : LibreHardwareMonitor/LibreHardwareMonitor@e624437
md5 of V188 and V189 are the same:
md5sum *net_4_8/LibreHardwareMonitorLib.dll *net_8_0/LibreHardwareMonitorLib.dll
0e9ac2177593b17589ec567509d422a3 FanControl_188_net_4_8/LibreHardwareMonitorLib.dll
0e9ac2177593b17589ec567509d422a3 FanControl_189_net_4_8/LibreHardwareMonitorLib.dll
e4ec0737857d4c66935f9033890ae907 FanControl_188_net_8_0/LibreHardwareMonitorLib.dll
e4ec0737857d4c66935f9033890ae907 FanControl_189_net_8_0/LibreHardwareMonitorLib.dll
EDIT: By the file properties, the commit is the LibreHardwareMonitor/LibreHardwareMonitor@331d334. After this commit, I've sent 3 updates.
@Rem0o @epinter
Can confirm that LHM in FanControl is broken, was just about to make a post about it because my FanControl was at 0 temp when I started my computer just now, I then tried to swap the DLL in to LHM to see if it would show the same, and it showed it was broken, where as the last version that epinter send me was working fine.
Here is Fan Control menu.
Here is the LHM that epinter send me last.
And here is the LHM running the DLL from fancontrol
Checked the hashes and I'm confused as to what's going on.
Will figure out what's going on.
EDIT:
Fun times, had 2 local copies of the repo. Build pipeline used one, but the one I was referring to was the other 🤦♂️
V190 lost my GPU sensors. Swapping in LHM files from V189 fixed it.
V190 lost my GPU sensors. Swapping in LHM files from V189 fixed it.
What gpu you have ? Users tested AMD RX series 5000, 6000 and 7000, all of them worked as far as I know.
Test the latest nightly build of LHM: https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/8958653644/artifacts/1474376834
My card is an AMD R9 280x. Adding that latest LHM to Fan Control had the same problem as v190. Got the same could not find expected sensors error again. The ADLX plugin didn't help either.
My card is an AMD R9 280x. Adding that latest LHM to Fan Control had the same problem as v190. Got the same could not find expected sensors error again. The ADLX plugin didn't help either.
Must be the same problem of RX 400 and RX 500 series. Try this build of LHM, tell me if it works. Download links at the end of the page, LibreHardwareMonitor-net472 is full LHM, others are the libraries for other .net versions.
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/9085676231
Must be the same problem of RX 400 and RX 500 series. Try this build of LHM, tell me if it works. Download links at the end of the page, LibreHardwareMonitor-net472 is full LHM, others are the libraries for other .net versions.
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/9085676231
That LHM works again!
Must be the same problem of RX 400 and RX 500 series. Try this build of LHM, tell me if it works. Download links at the end of the page, LibreHardwareMonitor-net472 is full LHM, others are the libraries for other .net versions.
https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/actions/runs/9085676231That LHM works again!
Nice , good to hear that!
As far as I'm considered my issue has been resolved with v190, and if the new ones in this issue have made their own, I will close this.
Thanks for all the work. :)