FreeBSD Developers Tackle AMD Zen/Ryzen Temperature Monitoring Before Linux

[phoronix]

Phoronix: FreeBSD Developers Tackle AMD Zen/Ryzen Temperature Monitoring Before Linux

While Linux users of AMD's new Zen-based Ryzen/Threadripper/Epyc processors are still waiting for thermal driver support to hit the mainline Linux kernel, FreeBSD developers have already managed to produce the Zen "Family 17h" CPU thermal monitoring support on their own...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-FreeBSD-Temps

[caligula]

Correct me if I'm wrong, but doesn't AGESA 1.0.0.6a expose a new thermal sensor (cpu die?) to the OS? At least my 'lm-sensors' application displays that as one of the SMBUS devices. It's not visible in < 1.0.0.6a. OTOH that sensor reading is totally useless, it has huge spikes, can rise 20 to 30 degrees when you start compilation.

[juergbi]

Patch for Linux is available as well: https://lkml.org/lkml/2017/9/6/684

[duby229]

See. That's what taking too long releasing documentation or code does, it derails your plans. AMD wanted Zen to have a new thermal driver, probably for good reasons, but they took too long and the BSD devs figured it out without them. A similar scenario unfolded with Radv in waiting for AMD's Vulkan implementation. I don't know if AMD realizes this, but they've already hired some of the most competent open source driver developers in the world. And they are obliged to AMD's agenda whether they realize it or not. If some of those same devs had obligations elsewhere, i'd be willing to bet they'd have been working on this thermal driver support or on Radv.

I understand that AMD has elegant intentions..... But taking too long scares intentions into ugly unrecognition.

[jrch2k8]

See. That's what taking too long releasing documentation or code does, it derails your plans. AMD wanted Zen to have a new thermal driver, probably for good reasons, but they took too long and the BSD devs figured it out without them. A similar scenario unfolded with Radv in waiting for AMD's Vulkan implementation. I don't know if AMD realizes this, but they've already hired some of the most competent open source driver developers in the world. And they are obliged to AMD's agenda whether they realize it or not. If some of those same devs had obligations elsewhere, i'd be willing to bet they'd have been working on this thermal driver support or on Radv.

I understand that AMD has elegant intentions..... But taking too long scares intentions into ugly unrecognition.

I agree but I think for now is not that bad, I mean AMD right now seems to be uberly focused on optimize the feces out of OpenGL(which is the most used API on Linux for now) and bring AMDGPU(Rocm and HSA) kernel driver(s) upstream up to snuff so they can bring OpenCL to the stack as well while other FOSS developers decided to tackle Vulkan in the meantime(which is turning out to be great), etc.

So I think once those points are reached AMD will have enough time to support other features faster but I guess their problem right now is too many eggs about to hatch on the basket, so lets cut them some slack for a while, so they can get their house in order first

[schmidtbag]

I feel like this is one of those situations where BSD users want to stick up their nose saying "yeah well we got Ryzen thermal sensors before you so HA!" meanwhile Linux users are like "and we got it a couple months later. Not like it matters anyway, since the motherboard sensor has been good enough".

See. That's what taking too long releasing documentation or code does, it derails your plans. AMD wanted Zen to have a new thermal driver, probably for good reasons, but they took too long and the BSD devs figured it out without them. A similar scenario unfolded with Radv in waiting for AMD's Vulkan implementation. I don't know if AMD realizes this, but they've already hired some of the most competent open source driver developers in the world. And they are obliged to AMD's agenda whether they realize it or not. If some of those same devs had obligations elsewhere, i'd be willing to bet they'd have been working on this thermal driver support or on Radv.

I understand that AMD has elegant intentions..... But taking too long scares intentions into ugly unrecognition.

I see your point, but the problem ultimately comes down to legal issues. I'm sure many of their own developers are sitting there twiddling their thumbs, and I'm very sure AMD is not fond of paying employees who aren't doing anything. As you're probably aware, legal issues are never resolved quickly (a "speedy trial" can still take months or years to resolve). But the fact of the matter is, open-sourcing this kind of stuff just isn't a high priority to them. AMD isn't likely going to profit as a result of open sourcing their products, so it takes a back seat. To me, it's better to have something eventually rather than never.

Personally, what I think AMD should do is have developers work on the open source drivers as the legal issues are being resolved. That way, they should both be done being worked on at roughly the same time.

[Ropid]

Correct me if I'm wrong, but doesn't AGESA 1.0.0.6a expose a new thermal sensor (cpu die?) to the OS? At least my 'lm-sensors' application displays that as one of the SMBUS devices. It's not visible in < 1.0.0.6a. OTOH that sensor reading is totally useless, it has huge spikes, can rise 20 to 30 degrees when you start compilation.

Intel's stuff has similar spikes so that might be completely correct. For Intel, those readings are exactly what's used by the CPU when it decides by itself to throttle at 100°C or 105°C, and shut down at 120°C or 125°C, so despite those 30° spikes it's still what you will want to look at to know that everything's okay. Those sensors are probably located somewhere inside the cores in a tiny area where those crazy temperature swings are real. The temperature limits for the whole CPU are around 70°C for Intel, so the rest of the CPU is a lot colder than wherever those sensors are with their up-to-100°C readings.

For controlling fans with those readings as input, directly changing fan speeds is really annoying as the fans will ramp up and down whenever there's a spike. I use a script that keeps a record of the readings over the last two minutes, then uses the average temperature of those two minutes to set fan speeds. That makes it ignore short spikes completely, and when there's real load the fans will ramp up slowly and gradually.

[andreano]

This is quicker than they did for AMD Llano (anno 2012) anyway … after 5 years, lm-sensors still doesn't know my CPU temperature and fan speed.

[duby229]

I feel like this is one of those situations where BSD users want to stick up their nose saying "yeah well we got Ryzen thermal sensors before you so HA!" meanwhile Linux users are like "and we got it a couple months later. Not like it matters anyway, since the motherboard sensor has been good enough".


I see your point, but the problem ultimately comes down to legal issues. I'm sure many of their own developers are sitting there twiddling their thumbs, and I'm very sure AMD is not fond of paying employees who aren't doing anything. As you're probably aware, legal issues are never resolved quickly (a "speedy trial" can still take months or years to resolve). But the fact of the matter is, open-sourcing this kind of stuff just isn't a high priority to them. AMD isn't likely going to profit as a result of open sourcing their products, so it takes a back seat. To me, it's better to have something eventually rather than never.

Personally, what I think AMD should do is have developers work on the open source drivers as the legal issues are being resolved. That way, they should both be done being worked on at roughly the same time.

But in my opinion, for AMD that's a problem, they have a policy of not talking about future plans. You can find marketing slides that AMD released in years past chalked full of information that never happened. I mean for the most part most slides are good informative articles, but some of them describe things that never happened. Short of that AMD really sucks at press releases, they prefer to say nothing as if "mums the word". In the end what happens is we get some slides with misinformation in them and then nothing at all for years. That philosophy just doesn't work for AMD.

I like what they did in 2007. Renew that philosophy.

[caligula]

For controlling fans with those readings as input, directly changing fan speeds is really annoying as the fans will ramp up and down whenever there's a spike. I use a script that keeps a record of the readings over the last two minutes, then uses the average temperature of those two minutes to set fan speeds. That makes it ignore short spikes completely, and when there's real load the fans will ramp up slowly and gradually.

Hm interesting, so you have your own fan PWM not provided by the mobo?