AMDGPU Fan Control

I am considering a move back to FreeBSD, now that my Linux contracts are nearly over, and I am re-entering retirement. I have an AMD RX-480 which is supported by FreeBSD. However, the latest FOSS AMDGPU drivers have picked up an unpleasant anomaly - they turn off the GPU fans. Earlier versions of AMDGPU left the fans on a low speed - preventing the GPU from overheating. Later ones - actually turn the fans off until the card is ~ 140DegF.

I've read several posts on the subject, and perused the handbook, but do not find any solid and clear examples on how to control the GPU fan on the AMD series GPU's. Lot's of "Maybe this will work..." type scenarios offered to the posters - but no clear and tested path to accomplish.

Does anyone have a tried and true method to control the fan speed on an AMDGPU card?

Or does anyone have knowledge that I clearly don't have, that states: "Under FreeBSD this is not possible...."?

Sincerely and respectfully,


Dave
 
Bumping this thread....I'm ready to pull the trigger, but the latest AMDGPU driver sets the fans to zero until the card gets hot. Heat is the bane of electronics. I am using the same driver version under Artix, that is listed in the ports tree, and in the pkg listing I found online.

So it's going to be a problem under FreeBSD....I really could use some help solving it - other than hacking into my system physically, and rewiring the GPU fans to a physical speed control I can get at Microcenter.

Help and pointers to how-to articles - or "it can't be done under FreeBSD..." is what I am looking for.


Thank you for your assistance.


Dave
 
I don't want to reproduce a truckload of research and references to documentation just before going to bed, but off the top of my head, I can say that amdgpu support under FreeBSD is spotty at best - you can do # kldload amdpgu.ko and be able to run KDE Plasma desktop. If you have devel/ocl-icd (and a few others) installed, you can take a look at what settings your card has (RAM, clock speed, shader register addresses, etc), but you'll get a core dump when the program is done. I tried compiling marazmista's radeon-profile (just google the underlined stuff), and it could not detect my card.

I'm stubborn enough to keep researching the matter, compiling the kernel/world, and learn ZFS snapshotting - all in order to get the Gallium stack working properly on FreeBSD, and have marazmista's radeon-profile working. FWIW, my card is Asus Radeon RX 550 4GB... according to AMD, it's enabled for Gallium, but not officially supported.

This is the kind of knowledge you will need to develop if you want to control GPU fan speed under FreeBSD... Not impossible, but you have to be stubborn enough.

Oh, and as a matter of Internet etiquette:
Help and pointers to how-to articles - or "it can't be done under FreeBSD..." is what I am looking for.


Thank you for your assistance.


Dave

Don't post your real name. Forums are not a replacement for email at work or school.
 
astyle

Thank you for your reply. Sounds like the basic support I would need isn't there - yet. I can't debug something unless I know the underlying layers are solid. And from what I can gather from the dearth of info, and your reply, FreeBSD's foundation isn't solid under an AMD GPU.....That would be silly therefore to try to write a fan control app - if the basic infrastructure isn't there in the OS to do it. And I certainly have no intention of cooking my CPU nor running it hot for no reason.

Regarding being stubborn - I certainly know how to do that! In my 64 years.....that trait has come in handy from time to time. There is a difference between being stubborn - and not your using time wisely. I am willing to be stubborn - but only if the "ground" I am standing on is solid. Sure sounds like it isn't solid - yet.

On my name - yep - I do a lot of emails during the day - and I apologize for using my first name instead of my handle.

But again - I thank you for your post.....


d
 
I have contacted Jason M, who created the python daemon to control the AMDGPU fan at a user specified interval, with several setpoints from which it creates a curve for the fan, and handles the fan in the background.

He seems interested in assisting in this endeavor. So I have picked up a M.2-2280 drive that I am going to install FreeBSD to, and work with him to get his python daemon working if possible. The AMDGPU devs in their documentation - state that the ability to control the fan speed is now in the driver itself....

So If I can get it working - I'll report back here....


D
 
I'd say you're mis-characterizing the issue a bit... When people (myself included) say that 'FreeBSD support for amdgpu is poor' that doesn't mean the underlying system is not solid. It means the amdgpu driver itself is not in the best shape. It takes effort to write the driver in a way that it works well on FreeBSD. FreeBSD works differently than Linux or Windows, and device drivers need to respect that. If they don't, it doesn't matter how solid the underlying the underlying OS is - devices will be still incompatible.

Out in the wild, Windows and Linux seem to get priority when it comes to supporting development efforts to get amdgpu-driven devices working with various OS'es. That's what it means when people say that 'FreeBSD support for amdgpu is poor'.

FWIW, if the basic stuff like devel/clinfodumps core when you try to run it, that's when it's probably time to realize that a python daemon (or any other program, for that matter) will not be able to control fan speed on the GPU. Heck, you'd be lucky to even get any output that shows a detected speed, much less anything accurate.
 
FWIW, Running FreeBSD on a multi-boot system, I get very similar feedback from my Debian 10.9 dmesg output, when compared to what I get from FreeBSD 13.0. Here's a snippet from Debian:
Code:
[    3.032669] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/mullins_sdma.bin
[    3.032674] [drm] Internal thermal controller without fan control
[    3.034207] [drm] radeon: dpm initialized
[    3.034386] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/bonaire_uvd.bin
... and from FreeBSD:
Code:
drmn0: successfully loaded firmware image 'radeon/mullins_sdma.bin'
[drm] Internal thermal controller without fan control               
[drm] radeon: dpm initialized               
drmn0: successfully loaded firmware image 'radeon/bonaire_uvd.bin'
My device ID string from FreeBSD is:
Code:
CPU: AMD A6-6310 APU with AMD Radeon R4 Graphics     (1796.67-MHz K8-class CPU)
... so maybe this isn't strictly a FreeBSD-only problem, right? We know how reluctant/unwilling AMD is, when it comes to sharing their technical specifications with anyone other than M$...
 
Hello All,

And thank you for your responses.

When FreeBSD was my daily driver (until I landed two multi-year Linux contracts)...In 10.* - I could see the fan speed...

So - I have allocated one of my SSD's for FreeBSD and moved what was on that drive to other online storage I have.

I downloaded and cooked a USB memdisc IMG and will install FreeBSD onto this re-purposed SSD. I can do this without interrupting anything at all. I'll just use the BIOS boot screen in my system's post - and just boot to this drive so I can tinker on live hardware - without worry. If I see the card starting to overheat - I'll just reboot to Linux and let the python daemon cool it down, so I can reboot into FreeBSD and continue "tinkering".

RE: AMD not being cooperative......Well.....they are certainly more cooperative than NVidia. I moved to AMD from an NVidia platform years ago because NVidia is very hostile to any FOSS os such as Linux or FreeBSD. Yet AMD is still more cooperative than NVidia. So I have no interest in purchasing an NVidia GPU just to gain access to their fan controller through their proprietary bits, which I may or may not even need for their GPU driver. Not to mention for those of us that game (Skyrim SE and Fallout-4)- both are running better under Linux than they did when I actually had W10 installed. So I am disinclined to break apart my linux rig - until I can work through the issues under FreeBSD. Which I can now do that I've cleared off a drive and dedicated it to FreeBSD.

I'll keep folks in this thread posted on what I find......and roadblocks I may run into......

D
 
I was just thinking what would be my amdgpu fan speed, until i realised i own one with passive cooling :).
It lists the boot message :"Internal thermal controller without fan control"
 
I was just thinking what would be my amdgpu fan speed, until i realised i own one with passive cooling :).
It lists the boot message :"Internal thermal controller without fan control"
I never hear a fan whirring, yet my laptop doesn't seem to ever overheat, not even when running Windows 10. Nice features.
 
Well,

I installed FreeBSD 13 to real hardware.
Using this command: sysctl -a | grep -i temperature.

I can't see any metrics on my RX-480. And if I can't see them, then of course no code can be written to control the GPU fan without a temperature input. I see many other posts regarding this issue, in other BSD forums and such. This is an issue that is not unique to FreeBSD. It's an issue with all of the BSD's.

In my research and readings, it has been alleged that the folks who ported the amdgpu driver to BSD, had to turn off certain things in the driver to make it work with the FreeBSD kernel.

I'm not sure why AMD sets the fan speed to zero in the latest versions of their OSS driver, they didn't used to in older drivers. This is also a common problem in the Linux world among amdgpu users whose posts I also read.

IMHO - AMD is allowing the card to get way too hot before they begin to spool up their own fans based upon their default setting in their onboard GPU BIOS.


So lastly - I will post to AMD directly and see if we get an answer....

Just keeping this thread up to date with my latest research...

D
 
This is temperature when I compile ports, open is Firefox and listening music on mpv. And the fan is running.
 

Attachments

  • temp.jpg
    temp.jpg
    563.5 KB · Views: 137
On my real hardware - with the amdgpu kldload'ed - and in reviewing every single entry in sysctl -a, there are no temperatures for the RX-480 GPU.

AMD pointed the finger @ the FreeBSD devs, and finger-pointing is not helpful for anyone. I am not about to get into that scenario. So it's over. It can't be done under FreeBSD.

As far as I am concerned - it is now a dead issue. The amdgpu driver under FreeBSD cannot monitor GPU temps, not natively, not via sysctl, not via acpi. CPU's? No problem! GPU's? for AMD anyway - it is a no go.

I am not going to slowly cook my GPU because the AMD devs decided to spool the fans down to zero in their latest driver at initialization.

I want to thank everyone who responded. I am grateful for the support, but this issue is now a dead issue.


D
 
There can always be a marketing reason. For instance that the temperature is reality much higher than a vendor wants to admit. In that case the vendor says we don't know the temperature ...
 
On my real hardware - with the amdgpu kldload'ed - and in reviewing every single entry in sysctl -a, there are no temperatures for the RX-480 GPU.

AMD pointed the finger @ the FreeBSD devs, and finger-pointing is not helpful for anyone. I am not about to get into that scenario. So it's over. It can't be done under FreeBSD.

As far as I am concerned - it is now a dead issue. The amdgpu driver under FreeBSD cannot monitor GPU temps, not natively, not via sysctl, not via acpi. CPU's? No problem! GPU's? for AMD anyway - it is a no go.

I am not going to slowly cook my GPU because the AMD devs decided to spool the fans down to zero in their latest driver at initialization.

I want to thank everyone who responded. I am grateful for the support, but this issue is now a dead issue.


D
Please forgive my ignorance but I'm no expert in this area. Does this mean you'll be getting a different board? Going back to Windows? Or, something else? I don't understand.

It was my surmise-- and only a surmise-- and only after realizing that my earlier guesswork was wrong-- that Alain De Vos and I were probably in okay-shape, because our boards don't have fans anyway, and use passive cooling. Is that wrong?

I have other hardware that FreeBSD doesn't support. It's no big deal to me since I can always get supported hardware.

Finally, are some people coming to the conclusion here, that these same problems don't exist for Linux, but only for FreeBSD? Because I don't get where that's coming from either. When I compared the drm/dmesg output for Debian with the output from FreeBSD, earlier in this thread, it seemed to me that, since their message output was so similar, that they must have been using the same driver software. Or, as an old friend of mine likes to say, we all seem to be pissing out of the same quill. Am I wrong?
 
There can always be a marketing reason. For instance that the temperature is reality much higher than a vendor wants to admit. In that case the vendor says we don't know the temperature ...
Well....

Except for Windows and Linux - where the temperatures are indeed exposed - as is the PWM control for the fan.

When AMD updated their driver - and my GPU temp shot-up - I though one of my fans had failed, or somehow the fans had become lint-balled - even though I clean things out regularly.

When I was still working - I used a industrial non-contact infrared thermometer. It was one of my personal tools in HVAC/BAS.

After I opened my case and found no issues - except the fans weren't spinning up until 140DegF...I "shot it" with the infrared thermometer thinking the sensor was out of whack. The two temps (displayed and physical measurement) were within 5 degF of each other. Then on the forums I haunt - others start having the same issue - and the python daemon was born (by others)....

I can only speak for my rig, not others....


Thanks for the reply!


D
 
Please forgive my ignorance but I'm no expert in this area. Does this mean you'll be getting a different board? Going back to Windows? Or, something else? I don't understand.

It was my surmise-- and only a surmise-- and only after realizing that my earlier guesswork was wrong-- that Alain De Vos and I were probably in okay-shape, because our boards don't have fans anyway, and use passive cooling. Is that wrong?

I have other hardware that FreeBSD doesn't support. It's no big deal to me since I can always get supported hardware.

Finally, are some people coming to the conclusion here, that these same problems don't exist for Linux, but only for FreeBSD? Because I don't get where that's coming from either. When I compared the drm/dmesg output for Debian with the output from FreeBSD, earlier in this thread, it seemed to me that, since their message output was so similar, that they must have been using the same driver software. Or, as an old friend of mine likes to say, we all seem to be pissing out of the same quill. Am I wrong?
Vull,


Thank you for the reply. I'll respond to each point where I have knowledge.....

I will NOT be getting a different board. An AMD gpu is as mainstream as an NVIdia one. And NVidia has historically been obstructionistic and antagonistic towards anything OSS. They provide their proprietary driver instead of cooperating with OSS devs. My amdgpu works just fine under Windows and Linux. Although - Windows hasn't been on my system for ~ 1 year now. I run my Steam games under Linux - and they actually run better than in W10 natively. Not to mention a W10 update hosed my wife's system (she's a professor) and smoked 20+ years of her university work. Boy - was she ever pissed! I recovered it all with Linux, and we both ported to Linux to get away from MS's forced updates and other shenanigans that they pull on the average consumer.

If your GPU has passive cooling - then you are not in danger at all. My RX-480 will run hot if I run steam games...But when I use my python fan daemon - the highest temp I see instead of 180degF, is 130degF. It will also run hot under the new amdgpu driver just doing a desktop workload - as it initializes my fans to 0, instead of 900rpm like the older driver used to.

Be careful with the "supported" comment above. amdgpu is indeed supported under FreeBSD - that's how I was running Mate and Xfce on my new FreeBSD 13 install on my spare SSD. Although mate was unusuably glitchy, xfce was smooth, smooth indeed. So FreeBSD supports amdgpu, but the version of the driver needed to operate under FreeBSD has a subset of the feature-set under Linux - obviously, or we would have a GPU temp and a PWM setting.

You are correct - my issue does not exist in Linux. I use this python daemon and it's all taken care of for me: https://github.com/mcgillij/amdfan
And for clarification - it does not exist either for when I used to be on an NVidia GPU, but that was back in the 10.* days. Can't speak to NVidia now.

I am not about to call you wrong....no way....I have learned in my virtual travels the last few days, is that the amdgpu driver for FreeBSD - for it to work with the FreeBSD kernel, had to have some stuff "turned off". That is what I have read. So take that with a certain grain of salt as none of that came from a FreeBSD dev (that I am aware of), and that info does NOT come from personal knowledge - just a "he said" scenario.

However you have a good point. The technical driver version under Artix Linux (my current daily driver), and the version in FreeBSD - are indeed identical. But that does NOT mean their internals are identical. The amdgpu driver had to be ported from Linux to FreeBSD. And the FreeBSD kernel and the Linux kernel - are two entirely different things, with different API's and such.....So I can imagine that the temp and fan info was turned off just to make the driver work under FreeBSD - with absolutely no malice intended whatsoever by the BSD dev's.

It's like this scenario when I was still working: When I was integrating a Carrier front end, with Carrier VAV boxes, yet with Trane RTU's via a JACE panel (Wind River Linux Based), I could not write to variables via the JACE panel that the Trane Rooftop Units didn't have, nor could I pass certain information to the Trane RTU's from the Carrier VAV's, that the Carrier VAV's wouldn't expose through public variables. I had to go with common denominators. While HVAC and BAS do not have much to do with FreeBSD nor Linux....It was a decision I had to make to integrate components from different manufacturers. I am pretty certain this type of thing is exactly what the FreeBSD dev's are up against......

So - please don't blame anyone. Not AMD, not FreeBSD, not Linux, not Windows...It's just the way circumstances fell due to no fault on anyone's part.

I am confident that if I went to Microcenter, and laid down a few hundred dollars for an appropriately powered NVidia card, then used the NVidia proprietary drivers - none of this conversation would have actually been started. And GPU prices today with the chip shortage - are outrageous - so I am not going to waste money tearing out my perfectly functioning (and powerful enough) GPU in exchange for another brand - just to be able to run FreeBSD in a safe manner where I am not worried about slowly cooking my GPU. That would be ludicrous and a waste of resources IMHO.


So now you have some answers, and some more backstory to your post - and THANK YOU for your responses...


D
 
Thanks dcbdbis. I still have one cheap HP notebook which I don't use with FreeBSD because of its unsupported wireless, but this older but better Lenovo laptop has been doing great.
 
Just finished a 5-hour compilation of AMD-related stuff on top of a recompiled 13.0-RELEASE kernel and today's 4pm PST snapshot of ports. devel/clinfo did output info exactly as described on FreeBSD's OpenCL page before dumping 109-MB core. I also managed to run benchmarks/clpeak, and got some numbers from my card (Asus Radeon RX 550 4GB), but I will not reproduce the numbers here. benchmarks/clpeak dumped 2.1 GB core. Both of these point to the idea that whoever ported these utilities to FreeBSD probably needs to add some code to make sure the programs close gracefully. I'm glad the port even exists, but there's more work to be done before AMD cards can be benchmarked under FreeBSD.
 
Back
Top