I have a brand new MSI AMD Radeon R9 270 2G GAMING. When the computer starts (during POST and grub screen and system boot), its fan is clearly audible - at 40% by my estimate. As soon as I hit a login screen, either in Windows or in Linux with catalyst driver, the fan becomes _very_ silent (at 18% by my estimate). But with radeonsi driver, the slowdown never happens - it's spinning at the original speed of 40% all the time (I guess it would just go up if I were able to utilize the card to its full potential). This happens regardless of radeon.dpm=1 presence on the kernel boot command line. I also checked that the card runs in the lowest power level. In Windows I use MSI Afterburner software to measure fan speed. It's running at 18% in idle. I can use this software to define my own fan speed profile (a function of temperature and fan speed) which starts at 40% by default in idle. I used Catalyst Control Center to manually adjust fan speed to 40% and it sounds pretty equal to what I hear during PC boot. So, my theory is that there are two default fan speeds - 40% defined by MSI (used during computer startup) and 18% defined by catalyst driver (used during graphics mode initialization). It's probably not 18% hardcoded, but it's computed from current GPU temperature. MSI has an excellent big fan, therefore the speed is very low. My problem with radeonsi is that my computer is quite loud compared to a system with catalyst (Windows or Linux). Can radeonsi behave the same as catalyst in this regard - set a reasonable (low) fan speed in idle, instead of keeping some preset speed used during PC init? I don't know what Catalyst does differently, but the difference is clearly in the driver. If I replace radeonsi for catalyst, my computer is suddenly super-silent. Fedora 20 xorg-x11-drv-ati-7.2.0-3.20131101git3b38701.fc20.x86_64 mesa-dri-drivers-9.2.5-1.20131220.fc20.x86_64 kernel-3.12.6-300.fc20.x86_64 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R9 270] [1002:6811]
Created attachment 91567 [details] dmesg.fglrx
Created attachment 91568 [details] dmesg.radeonsi
Created attachment 91569 [details] radeon_pm_info.radeonsi
Created attachment 91570 [details] rpm-qa
The open source driver currently relies on the vbios fan profile. There is no support yet for driver defined or user defined profiles. Marking as an enhancement request.
Same problem here on an MSI R7970 Lightning, tested with the latest Mesa version. Enabling dpm change nothing. For the record, here is the sensors output when the system is idle: radeon-pci-0100 Adapter: PCI adapter temp1: +33.0°C So this indeed seems to just be a fan control issue.
I can confirm this bug. I am currently using an MSI Radeon R9 270X, and fan speeds are indeed at around 40% with no ability to make adjustments.
I can confirm this too, using ATI Sapphire 7850 2GB OC, with fglrx drivers the fan is absolutely silent after the OS boots up and automatically speeds up in heavy load. With these drivers, the fan speed is always constant, no matter what load. Would be great if it would also change accordingly. Not sure how to help to fix this, I can provide any information needed.
I have the same issue, but with MSI HD7770. It would be great to fix this.
Is there any progress in this issue? I think it's more kernel issue than Xorg drivers. Can I somehow help resolving this? It is still present using 3.14.4 kernel.
Yes the issue is still active with 3.14.4. I tested the open driver up to 3.15rc4 and there were no changes yet. Neither in performance nor fan noise. (on the R9 270 from MSI)
AMD Gigabyte 280X user here (Windforce3 model) Fans at 40% speed for me, is very very loud. Using the 3.15 kernel in Fedora 20 with the radeonSI drivers, and the noise almost forces me to use the closed source drivers. When I was back in Ubuntu and with fglrx, the fanspeed was working correctly, it was very low (don't know how much, but maybe 10%). When you install Windows for example and are using the WDDM drivers or default ones, the fan speed stays around the same level (40%), which makes me believe this is somewhat at driver level, and not Kernel. Is there any way to reduce the speed manually, and increase it when the load increases? (The fans ramp up with DPM already in 3.15)
Although Alex already indicated the reason why this happens, I thought I'd chime in to add myself to the list of those affected. I have a Visiontek Radeon R7 260X, and the fan spins at 40% when the system starts up, until Catalyst kicks in and drops it to 20%. As others have reported, radeonsi fails to do this. It seems that just in this thread we now have MSI, VisionTek, Sapphire, and Gigabyte users so that's quite a few manufacturers who put a relatively high default fan speed (I'm sort of glad that I'm not alone!). I wonder if this is the same with Nvidia cards? Does nouveau have the ability to do fan control?
(In reply to comment #13) > I wonder if this is the same with Nvidia cards? Does nouveau have the ability > to do fan control? Yes, we do have support for fan control in Nouveau. Manufacturers do not really fiddle with temperature management anymore, so we do not have this problem. We have had one person complaining about a similar bug as this, although not as dramatic (35% instead of 30%, which is the minimum fan speed on most cards and is barely hearable).
(In reply to comment #13) > ... > It seems that just in this thread we now have MSI, VisionTek, Sapphire, and > Gigabyte users so that's quite a few manufacturers who put a relatively high > default fan speed (I'm sort of glad that I'm not alone!). I wonder if this > is the same with Nvidia cards? Does nouveau have the ability to do fan > control? You can add ASUS to the list. I own an Radeon HD 7950 Direct CU II which fan speed is by default around 40% which results in unbearable noise. fglrx dims the speed when xorg starts. Would be nice to have this fixed.
Any further news? Gigabyte HD7870 same issues as above. I have to use catalyst because of the fan noise.
I'm not sure of the standard etiquette here - is a +1 useful to get a sense of the number of people the bug is affecting, or just noise? Either way, +1 for Radeon HD7970 and apologies if it's NOT useful :)
(In reply to comment #17) > I'm not sure of the standard etiquette here - is a +1 useful to get a sense > of the number of people the bug is affecting, or just noise? At the least, it's good etiquette to read the discussion before replying. As stated in comment #5, developers already know about this. It's not a bug, but a missing feature. Please stop with the +1s.
So I'm starting to implement fan speed control, at least partially. Since I haven't found any related docs, this work is basically reverse-engineering. Here's my mmiotrace for BONAIRE R7 260X on 3.17-rc2 so far MARK 560.042950 R 4 580.364585 2 0xf0808010 0x3028 0x0 0 // read GRBM STATUS R 4 580.364590 2 0xf080d034 0x76ceed57 0x0 0 // read SDMA0_STATUS_REG R 4 580.364593 2 0xf080d834 0x46cee557 0x0 0 // read R_00D834_DMA_STATUS_REG R 4 580.364629 2 0xf0808010 0x3028 0x0 0 // read GRBM STATUS R 4 580.364632 2 0xf080d034 0x76ceed57 0x0 0 // read SDMA0_STATUS_REG R 4 580.364634 2 0xf080d834 0x46cee557 0x0 0 // read R_00D834_DMA_STATUS_REG W 4 580.364639 2 0xf0800200 0x80000004 0x0 0 // write to SMC_IND_INDEX_0 a 0x80000004 R 4 580.364641 2 0xf0800204 0x1000000 0x0 0 // read from SMC_IND_DATA_0 W 4 580.364643 2 0xf0800200 0x80000370 0x0 0 // write to SMC_IND_INDEX_0 R 4 580.364645 2 0xf0800204 0x23730 0x0 0 // read from SMC_IND_DATA_0 W 4 580.364646 2 0xf0800250 0x5c 0x0 0 // write to SMC_MESSAGE_0 (!) R 4 580.364649 2 0xf0800254 0x0 0x0 0 // wait for SMC_RESP R 4 580.364652 2 0xf0800254 0x0 0x0 0 // ... R 4 580.364655 2 0xf0800254 0x0 0x0 0 // ... R 4 580.364659 2 0xf0800254 0x1 0x0 0 // got it! R 4 580.364661 2 0xf0800254 0x1 0x0 0 W 4 580.364662 2 0xf0800200 0xc0300068 0x0 0 // write to SMC_IND_INDEX_0 R 4 580.364665 2 0xf0800204 0x40252f87 0x0 0 // read from SMC_IND_DATA_0 W 4 580.364666 2 0xf0800200 0xc0300064 0x0 0 // write to SMC_IND_INDEX_0 R 4 580.364668 2 0xf0800204 0x181431b 0x0 0 // read from SMC_IND_DATA_0 W 4 580.364670 2 0xf0800200 0xc0300064 0x0 0 // write to SMC_IND_INDEX_0 W 4 580.364671 2 0xf0800204 0x1814351 0x0 0 // read from SMC_IND_DATA_0 - this is the speed! W 4 580.364672 2 0xf0800200 0xc030006c 0x0 0 // write to SMC_IND_INDEX_0 R 4 580.364674 2 0xf0800204 0x50cb0c00 0x0 0 // read from SMC_IND_DATA_0 W 4 580.364676 2 0xf0800200 0xc030006c 0x0 0 // write to SMC_IND_INDEX_0 W 4 580.364677 2 0xf0800204 0x50cb0c00 0x0 0 // read from SMC_IND_DATA_0 W 4 580.364678 2 0xf0800200 0xc030006c 0x0 0 // write to SMC_IND_INDEX_0 R 4 580.364681 2 0xf0800204 0x50cb0c00 0x0 0 // read from SMC_IND_DATA_0 W 4 580.364682 2 0xf0800200 0xc030006c 0x0 0 // write to SMC_IND_INDEX_0 W 4 580.364683 2 0xf0800204 0x50cb0c00 0x0 0 // read from SMC_IND_DATA_0 I've almost clearly understand the register keys here but I don't understand some values that are written and read in the process.
Oleg, thanks a lot! Alex (or anyone else, particularly if you're from AMD): would it be possible to point Oleg to the relevant documentation if it exists, or at least find out whether it can be published in the near future (if it doesn't exist publicly yet), so that it doesn't have to reverse-engineered from scratch? Many thanks for any helpful info.
(In reply to comment #20) > Oleg, thanks a lot! > > Alex (or anyone else, particularly if you're from AMD): would it be possible > to point Oleg to the relevant documentation if it exists, or at least find > out whether it can be published in the near future (if it doesn't exist > publicly yet), so that it doesn't have to reverse-engineered from scratch? > Many thanks for any helpful info. Actually I already come to some conclusions. First SMC writes and reads (before SMC_MESSAGE) is just the "ci_check_smc_running" function (seems its analogue presents in proprietary driver as well). 0x5c value should be some sort of command, so it can be defined with already known ones in headers. About other values things are not so clear. I suppose to get real fan speed we need to somehow mask and shift data at smc index 0xc0300064. I'll try to make other traces with different parameters to compare percentages and values to the register reads and writes. P.S. yep, some docs would be helpful, thanks
Among other querstions - is this legal? I mean, taking traces from proprietary driver and trying to reverse-engineer it. I live in Russia if that's important
I have a similar problem with Radeon7870HD https://bugs.freedesktop.org/show_bug.cgi?id=83453 But there are some differences in the windows ... Catalyst says that the cooler is spinning at a rate of 40% - it is quiet, but Linuxs on hearing much more ...
Created attachment 105853 [details] [review] experimental patch for CI (BONAIRE etc.) for enabling fan control So I've come up with patch that enables manual fan override for CI family at least. I've tested it on my BONAIRE card, Radeon R7 260X. INSTALLATION: After compile and reboot there will be new debugfs file, /sys/class/drm/card0/device/power_fan_control READ: cat /sys/class/drm/card0/device/power_fan_control correct values are 0 to 100 on first reads it'll probably show some incorrect percentage value due to manual control not yet enabled WRITE: echo 40 > /sys/class/drm/card0/device/power_fan_control correct values are 0 to 100
(In reply to comment #24) > Created attachment 105853 [details] [review] [review] > experimental patch for CI (BONAIRE etc.) for enabling fan control > > So I've come up with patch that enables manual fan override for CI family at > least. I've tested it on my BONAIRE card, Radeon R7 260X. > > INSTALLATION: > After compile and reboot there will be new debugfs file, > /sys/class/drm/card0/device/power_fan_control Hey, I am the Nouveau developer who added fan management support. I would really advice you follow the hwmon recommendations and name this file pwm1. More information about this: https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface
(In reply to comment #25) > I am the Nouveau developer who added fan management support. I would really > advice you follow the hwmon recommendations and name this file pwm1. Sorry, I'm novice, didn't know about these. Though it's not a hw interface really, the exchange is done through io-mapped SMC registers... Ok, I'll make necessary changes. I assume it will allow lm-sensors to pick it up automatically, is it correct?
(In reply to comment #26) > (In reply to comment #25) > > > I am the Nouveau developer who added fan management support. I would really > > advice you follow the hwmon recommendations and name this file pwm1. > > Sorry, I'm novice, didn't know about these. Don't feel bad, you cannot know possibly know everything ;) > Though it's not a hw interface > really, the exchange is done through io-mapped SMC registers... Not sure how more hw-oriented the interface could get :D That is still irrelevant to the discussion though. HWMON is software interface for the userspace. > > Ok, I'll make necessary changes. I assume it will allow lm-sensors to pick > it up automatically, is it correct? Yes, it will! Just to make sure we understood each others: - pwm1 (RW) exposes the current pwm value (what you called power) - pwm1_min(RW) min exposes the mininimum power that should be used by the fan - pwm1_max(RW) min exposes the maximum power that should be used by the fan - pwm1_enable (RW) exposes the current fan mode. 0 = DISABLED, 1 = MANUAL (the user writes the fan power he/she wants to pwm1), 2 = AUTOMATIC (linear fan management?). Here is Nouveau's documentation on fan management: http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal I know it is a lot of changes I am asking you to do, but consistency across drivers is great feature!
(In reply to comment #27) I think I got your point. So I'll read through documentation you provided and expose these values as hwmon interface. > I know it is a lot of changes I am asking you to do, but consistency across drivers is great feature! Agreed, and thanks for the hint. P.S. You should remember that my implementation is highly experimental and naive (it's even tested only on my card). I can't expose some particular values or allow to write them. E.g. I don't know how to enable automatic fan management again after I've disabled it for now. What should I return in such case?
(In reply to comment #28) > (In reply to comment #27) > > P.S. You should remember that my implementation is highly experimental and > naive (it's even tested only on my card). I can't expose some particular > values or allow to write them. E.g. I don't know how to enable automatic fan > management again after I've disabled it for now. What should I return in > such case? No need to hurry, finish entirely your REing before proposing an implementation for your hardware (all the cards radeon GPUs you have). Please then ask others with different cards to check if your implementation works on their card too. When you got sufficient testing, propose this patch for inclusion. Have fun!
*** Bug 83453 has been marked as a duplicate of this bug. ***
A quick update - I was finally able to retrieve all needed data from fglrx (via some ADL SDK overdrive6 tinkering). It seems there is a lot of work (e.g. there is a feature for setting series of pairs temperature<->fanspeed), but at least I figured out the purpose of used registers and data values (I hope). So I'll try to come up with basic functionality and hwmon interface this week.
(In reply to comment #31) > A quick update - I was finally able to retrieve all needed data from fglrx > (via some ADL SDK overdrive6 tinkering). It seems there is a lot of work > (e.g. there is a feature for setting series of pairs > temperature<->fanspeed), but at least I figured out the purpose of used > registers and data values (I hope). > > So I'll try to come up with basic functionality and hwmon interface this > week. Hi, Oleg. Do you require dumps for PITCAIRN chips
(In reply to comment #32) > Hi, Oleg. Do you require dumps for PITCAIRN chips Yes, I need as much dumps as possible. I hope overdrive v6 works for all SI chips, so I've made simple example program for testing >SI asics, it lays here https://github.com/Adonai/radeon-fancontrol. You can check if it works while in X session with fglrx driver. So you should do the following: 1) install fglrx and configure it 2) switch to text console and stop any X being used 3) rmmod fglrx 4) now start mmiotrace (kernel has pretty nice doc here https://www.kernel.org/doc/Documentation/trace/mmiotrace.txt) 5) modprobe fglrx 6) start X && export DISPLAY=:0 7) now begin to collect data from mmiotrace (via cat trace_pipe &), you can put some marks here 8) start above mentioned program. There should be some noize from GPU fan for 6 seconds, it's normal 9) after it exits (in 10 seconds) collect its output and piped mmiotrace logs and post the results here Thanks!
Created attachment 106260 [details] mmiotrace dump for radeon 7850 Here is mmiotrace dump for my radeon 7850, in single-CPU mode.
(In reply to comment #31) > A quick update - I was finally able to retrieve all needed data from fglrx > (via some ADL SDK overdrive6 tinkering). It seems there is a lot of work > (e.g. there is a feature for setting series of pairs > temperature<->fanspeed), but at least I figured out the purpose of used > registers and data values (I hope). Those are called trip points ;) Well done! > > So I'll try to come up with basic functionality and hwmon interface this > week. Have fun ;)
(In reply to comment #34) > Created attachment 106260 [details] > mmiotrace dump for radeon 7850 > > Here is mmiotrace dump for my radeon 7850, in single-CPU mode. Seems you have X loading in the background while performing test... It poisons output with unneeded info :(
Created attachment 106588 [details] [review] experimental patch for CI (BONAIRE tested) for enabling fan control with hwmon interface (In reply to comment #35) > Have fun ;) So here's the final version of what I've done. I found existing radeon hwmon interface and added pwm1* sysfs files to it, so it exposes needed values (some like pwm1_max are RO though). I need someone aware of radeon driver workflow to review this patch (maybe Alex) and to point in a right direction. When all is good, I'll request some help from public (reddit maybe, or local LUG) to test it extensively.
(In reply to comment #37) > Created attachment 106588 [details] [review] [review] > experimental patch for CI (BONAIRE tested) for enabling fan control with > hwmon interface Good, I left some comments on the patch :) > > (In reply to comment #35) > > Have fun ;) > > So here's the final version of what I've done. I found existing radeon hwmon > interface and added pwm1* sysfs files to it, so it exposes needed values > (some like pwm1_max are RO though). > > I need someone aware of radeon driver workflow to review this patch (maybe > Alex) and to point in a right direction. Posting the patch on radeon's ML (if there is none, then use dri-devel) and CC Alex or any other radeon dev working on PM. > > When all is good, I'll request some help from public (reddit maybe, or local > LUG) to test it extensively. When the radeon devs will think the patch is in good-enough shape, they will likely commit it. Make sure your patch does not change the default behavior and that should be fine. Users willing to have manual fan management will be the testers ;)
(In reply to comment #38) > Good, I left some comments on the patch :) > Where? Could you post a link to it, seems I can't find it... > > When the radeon devs will think the patch is in good-enough shape, they will > likely commit it. Make sure your patch does not change the default behavior > and that should be fine. > > Users willing to have manual fan management will be the testers ;) Hmm, good point. But I'll need dumps for other cards to implement similar behaviour, how can I achieve this goal?
I found some time over the last couple of weekends to write up some preliminary patches that should point you in the right direction; I just need to run them by the IP team to make sure they are ok to release. I'd like to avoid including reverse engineered stuff in the driver as it's a lot harder for us to maintain.
(In reply to comment #40) > I found some time over the last couple of weekends to write up some > preliminary patches that should point you in the right direction; I just > need to run them by the IP team to make sure they are ok to release. I'd > like to avoid including reverse engineered stuff in the driver as it's a lot > harder for us to maintain. I agree about RE stuff. Ok, I'll be waiting for your turn. Reading source code of already implemented things and so on. Though I'll have a lot of questions about where should I place things in the driver and whether some locking required or not. And thanks for helping hand, Alex. Really appreciate it.
I have just reviewed the patch, but I'm unsure, whether I've fully understood it or not. If I got it right, you're giving an option to manually set fan-speed. However, the driver is still lacking an auto-mode, which needs to work out-of-the-box. Fan profiles are usually saved in VBIOS (they are also seperately available in UEFI VBIOS); there is a Windows-only tool called VBE7, which can extract, modify and save such profiles directly to VBIOS (http://www.techpowerup.com/forums/threads/vbe7-vbios-editor-for-radeon-hd-7000-series-cards.189089/). Wouldn't it be possible to implement such behaviour in the drm drivers? I mean like: reading fan profile (like 40°C -> 20%, 60°C -> 25%, 80°C -> 45% etc. and assuming linear scaling between those values), reading temperatures and setting fan-speed accordingly? I have absolutely no idea, how the Windows driver is handling this, but the fan-profile saved in VBIOS doesn't seem to have any value for the open source Radeon drivers, at least for my reference HD7970 card. The card is running in BIOS-level 40% fan-speed, no matter what. I'd prefer an automatic method over setting fan-profiles via user-land tools or manually. Thanks for the great work so far!
(In reply to comment #42) >If I got it right, you're giving an option to manually set fan-speed. Yes, you understood it right. For now it's only the option to manually set fan speed. > > Wouldn't it be possible to implement such behaviour in the drm drivers? I > mean like: reading fan profile (like 40°C -> 20%, 60°C -> 25%, 80°C -> 45% > etc. and assuming linear scaling between those values), reading temperatures > and setting fan-speed accordingly? > That's not impossible, and there's an API called Overdrive6 that's both accessible to Windows and Linux (only closed source driver though). Mmiotracing those calls (yeah, actually that thing you mentioned - setting temperature<-->speed pairs) can lead to implementing this behaviour in open-sorce driver. Alex said he can provide some patches for me to start with, let's see if it will cover these demands.
(In reply to Alex Deucher from comment #40) > I found some time over the last couple of weekends to write up some > preliminary patches that should point you in the right direction; I just > need to run them by the IP team to make sure they are ok to release. I'd > like to avoid including reverse engineered stuff in the driver as it's a lot > harder for us to maintain. Alex, just reminding you of this bug, did the patch you mentioned passed the review? I'm inly waiting :)
I pinged the IP review teams again this week. Sorry for the delay.
Is there any progress on this?
Sorry for the delay, my initial patches are here: http://people.freedesktop.org/~agd5f/fan_cntl/
Alex, will these patches correct fan speed for PITCAIRN cards?
(In reply to Anton L. from comment #48) > Alex, will these patches correct fan speed for PITCAIRN cards? Yes, once they are working properly.
(In reply to Alex Deucher from comment #49) > (In reply to Anton L. from comment #48) > > Alex, will these patches correct fan speed for PITCAIRN cards? > > Yes, once they are working properly. Oh, thanks, Alex, I'll try to figure out what needs to be done on weekend
Updated patches in my 3.19-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip
FWIW, all boards support percent based fan control, but only boards with the ucTachometerPulsesPerRevolution field set in the vbios support rpm based fan control.
Alex, what's the point of calling si_thermal_start_smc_fan_control (and then eventually si_fan_ctrl_start_smc_fan_control) from si_thermal_start_thermal_controller? From my experience they're doing it only on overdrive request from userspace, am I correct?
Never mind last comment, I was taking PPSMC codes in reverese meaning...
I'm digging deeper... > #define FDO_PWM_MODE_MASK (3 << 11) aaaand.... > #define FDO_PWM_MODE_STATIC 1 > #define FDO_PWM_MODE_STATIC_RPM 5 and in ci_fan_ctrl_set_static_mode we're taking one of these modes as argument and shifting it, I assume? But how can 5 (0b101) match into mask 3 (0b11)?
And another one: >#define CG_FDO_CTRL0 0xC0300064 >#define FDO_STATIC_DUTY(x) ((x) << 0) >#define FDO_STATIC_DUTY_MASK 0x0000000F >#define FDO_STATIC_DUTY_SHIFT 0 >#define CG_FDO_CTRL1 0xC0300068 >#define FMAX_DUTY100(x) ((x) << 0) >#define FMAX_DUTY100_MASK 0x0000000F >#define FMAX_DUTY100_SHIFT 0 I see the values like this on my BONAIRE: >W 4 587.343959 2 0xf0800200 0xc0300068 0x0 0 // it's CG_FDO_CTRL1 >R 4 587.343962 2 0xf0800204 0x40252f87 0x0 0 >W 4 580.364670 2 0xf0800200 0xc0300064 0x0 0 // CG_FDO_CTRL0 >W 4 580.364671 2 0xf0800204 0x1814351 0x0 0 // I'm setting speed 50% >W 4 594.360662 2 0xf0800200 0xc0300064 0x0 0 // CG_FDO_CTRL0 again >W 4 594.360663 2 0xf0800204 0x1814387 0x0 0 // I'm setting speed 100% Are you sure the FDO_STATIC_DUTY_MASK and FMAX_DUTY100_MASK is 0xF and not 0xFF?
You're right about the masks. Fixed in my 3.19-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip
Another observation: I've uncommented ci_fan_ctrl_set_fan_speed_percent and tried to bind it to hwmon interface. So, if I try to set static value to the fan, then I see 0x50CB1435 in CG_FDO_CTRL2 and the fan runs 100% percent always, regardless of values I'm echoing But if I push 0x50CB0C00 to the CG_FDO_CTRL2 instead of trusting ci_fan_ctrl_set_static_mode, it begins to react on values I echoed. Can you elaborate on what each bit of this control register means? Maybe I just can't into abbreviations :)
(In reply to Chernovsky Oleg from comment #58) > Can you elaborate on what each bit of this control register means? Maybe I > just can't into abbreviations :) TMIN - temp at which the fan would be turned on FDO_PWM_MODE - which PWM mode to use: 0 - static PWM based on fuse value 1 - static PWM based on CG_FDO_CTRL0.FDO_STATIC_DUTY value 2 - dynamic PWM 5 - static PWM based on RPM CG_TACH_CTRL.TARGET_PERIOD value TACH_PWM_RESP_RATE - amount to adjust PWM in tach mode As far as I know, only values 1 and 5 are used for FDO_PWM_MODE in the driver for manual control. I'm not sure what dynamic PWM (2) means or how it works. It might be used by the smc for fan control. I also noticed a minor error in the RPM control setup, and I've pushed a patch to my 3.19-wip branch.
(In reply to Alex Deucher from comment #59) > I also noticed a minor error in the RPM control setup, and I've pushed a > patch to my 3.19-wip branch. I (think I) found another typo, that was tricky one to notice :D > tmp = RREG32_SMC(CG_FDO_CTRL2) & FDO_PWM_MODE_MASK; > tmp |= FDO_PWM_MODE(mode); > WREG32_SMC(CG_FDO_CTRL2, tmp); bitwise not (~) is missing from the first line
Good catch. Fix pushed to my 3.19-wip branch.
With the latest bugs noticed by Oleg fixed, smc fan control seems to work well on CI parts so I've enabled it by default. smc fan control on SI is still not working yet, but it's probably something small. You can test it on my 3.19-wip branch.
Created attachment 110476 [details] [review] hwmon interface for manual fan control on CI cards Hi Alex, I've made rough patch implementing hwmon interface for the code you've provided. Please take a look (comments inside). Patch is done on top of your 3.19-wip branch.
(In reply to Chernovsky Oleg from comment #63) > Created attachment 110476 [details] [review] [review] > hwmon interface for manual fan control on CI cards > > Hi Alex, I've made rough patch implementing hwmon interface for the code > you've provided. Please take a look (comments inside). > > Patch is done on top of your 3.19-wip branch. Looks good. Please split into 3 patches: 1. add the new dpm asic callbacks 2. add the common hwmon fan code. Make sure it's only enabled on asics which support manual fan control 3. wire up the CI specific code As far as percent vs. rpm, I'm not sure which would be preferred. I think the hwmon subsystem generally prefers rpm. Maybe add callbacks for both percent and rpm and then check rdev->pm.fan_pulses_per_revolution. If it's 0, expose it as a percent. if not, expose as rpm. Thoughts? Might be worth asking on the hwmon mailing lists. Also, we should only expose these on asics which support fan control.
> 1. add the new dpm asic callbacks > 2. add the common hwmon fan code. Make sure it's only enabled on asics > which support manual fan control > 3. wire up the CI specific code Ok, makes sense > > As far as percent vs. rpm, I'm not sure which would be preferred. I think > the hwmon subsystem generally prefers rpm. Maybe add callbacks for both > percent and rpm and then check rdev->pm.fan_pulses_per_revolution. If it's > 0, expose it as a percent. if not, expose as rpm. Thoughts? Might be > worth asking on the hwmon mailing lists. Good idea, I'll try to test rpm behaviour today > Also, we should only expose these on asics which support fan control. No problem, some tinkering with `hwmon_attributes_visible` should make it. I'll refresh & update patches on weekend.
(In reply to Alex Deucher from comment #64) > > As far as percent vs. rpm, I'm not sure which would be preferred. I think > the hwmon subsystem generally prefers rpm. Maybe add callbacks for both > percent and rpm and then check rdev->pm.fan_pulses_per_revolution. If it's > 0, expose it as a percent. if not, expose as rpm. Thoughts? Might be > worth asking on the hwmon mailing lists. No need to guess, everything is written here ;) https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface pwm1 should expose the duty cycle and nothing else. If you also have a tachometer, expose it with fan1_input :) If you want to set the fan speed with RPM instead of the duty cycle, you'll need to use fan1_target. You may wonder what should happen if you set both pwm1 and fan1_target. Well, I would think that the latest you set should take precedence. Please try to stick to the document I provided, for the sake of having a common behaviour. I hope I helped a little on this ;)
Alex, more comments, now on SI impl >#define CG_FDO_CTRL0 0x754 >#define CG_FDO_CTRL1 0x758 >#define CG_FDO_CTRL2 0x75C Are you sure they're 0x75* and not 0x76*?
(In reply to Martin Peres from comment #66) Martin, there're things I think I didn't get correctly: - What should I return if pwm1_enable is 0 and I'm trying to push 50 into pwm1? - Can pwm1_enabled value be 2 after I push 0 to it? Radeon default fan value comes from fuse and it's not 100%
(In reply to Chernovsky Oleg from comment #67) > Alex, more comments, now on SI impl > > >#define CG_FDO_CTRL0 0x754 > >#define CG_FDO_CTRL1 0x758 > >#define CG_FDO_CTRL2 0x75C > > Are you sure they're 0x75* and not 0x76*? Yes they are at 0x75*, I just double checked the register database.
(In reply to Alex Deucher from comment #69) > Yes they are at 0x75*, I just double checked the register database. Hmm ok... strange though, for CI the offset from CG_MULT_THERMAL_STATUS to CG_FDO_CTRL0 is 0x50, and from CG_FDO_CTRL0 to CG_TACH_CTRL is 0xC, but for SI they's 0x40 and (again!) 0xC accordingly...
Never mind last comment, just thought about additional registers in the middle of range. I'll have a SI part at the end of December, hope I'll be able to perform some tests on it.
Hey Oleg, (In reply to Chernovsky Oleg from comment #68) > (In reply to Martin Peres from comment #66) > > Martin, there're things I think I didn't get correctly: > - What should I return if pwm1_enable is 0 and I'm trying to push 50 into > pwm1? I made Nouveau return -EINVAL. > - Can pwm1_enabled value be 2 after I push 0 to it? Radeon default fan value > comes from fuse and it's not 100% So, you mean that the boot default for the fan mode is the automatic mode, right? That's perfectly fine. The only thing you need to make sure of is that when the user writes 0 to pwm1_enable, you should disable auto fan management and set the fan speed to 100%. To be honest, I find the mode 0 to be useless, but the spec is the spec :s
(In reply to Chernovsky Oleg from comment #24) > Created attachment 105853 [details] [review] [review] > experimental patch for CI (BONAIRE etc.) for enabling fan control > > So I've come up with patch that enables manual fan override for CI family at > least. I've tested it on my BONAIRE card, Radeon R7 260X. > > INSTALLATION: > After compile and reboot there will be new debugfs file, > /sys/class/drm/card0/device/power_fan_control > > READ: > cat /sys/class/drm/card0/device/power_fan_control > correct values are 0 to 100 > on first reads it'll probably show some incorrect percentage value due to > manual control not yet enabled > > WRITE: > echo 40 > /sys/class/drm/card0/device/power_fan_control > correct values are 0 to 100 Is there an easy way to get something similar working with the latest kernel (3.19 rc2)? Obviously there is disabled code (#if 0) but simply enabling it won't change anything i suppose. Also, I need it for SI (R9 280).
Created attachment 111927 [details] [review] !evil's venture for manual fan speed control I tried to adjust Chernovsky Oleg's code such that it uses the disabled functions in 3.19 rc3. But it didn't work out for me. On my system the 'power_fan_speed' file (which should be named pwm..) is not created. Maybe my setup is broken and the code never gets executed. dmesg does however state: dpm initialized. Anyways, if this would work, I would come up with some dummy automatic fan speed regulator, most probably written in python.
Pushed a 3.20 wip branch with Oleg's patches plus some minor fixes and support for SI. http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.20-wip
Created attachment 111981 [details] mmiotrace dump for HD6750 (JUNIPER Pro) Dump from HD6750 JUNIPER. All as you describe, but fan don't change its RPM (based on percent): INF: Nr. of Adapters: 3 INF: Adapter index: 0, active, ID:-1973430928, AMD Radeon HD 6700 Series INF: Adapter index: 1, inact., ID:-1973430928, AMD Radeon HD 6700 Series INF: Adapter index: 2, inact., ID:-1973430928, AMD Radeon HD 6700 Series Getting caps info... Capabilities Info: ExtMask 0x0 ExtValue 32767 Capabilities 0x7 Number of performance levels 3 FanSpeedType 1 Getting fanspeed info... Fanspeed Info: ExtMask 0xdfecaef0 ExtValue 0 FanSpeedPercent 40 FanSpeedRPM 0 FanSpeedType 0x1 Setting fanspeed info as 100%... Getting fanspeed info... Fanspeed Info: ExtMask 0x1 ExtValue 0 FanSpeedPercent 40 FanSpeedRPM 1 FanSpeedType 0x1 Setting fanspeed info as 100%... Getting fanspeed info... Fanspeed Info: ExtMask 0x1 ExtValue 0 FanSpeedPercent 40 FanSpeedRPM 1 FanSpeedType 0x1 Setting fanspeed info as 100%... Getting fanspeed info... Fanspeed Info: ExtMask 0x2 ExtValue 0 FanSpeedPercent 40 FanSpeedRPM 2 FanSpeedType 0x1
(In reply to Slava F. from comment #76) > Created attachment 111981 [details] > mmiotrace dump for HD6750 (JUNIPER Pro) > > Dump from HD6750 JUNIPER. > All as you describe, but fan don't change its RPM (based on percent): Yup, sorry, the HD6xxx parts are not supported by this software. They don't have Overdrive6 capabilities required for it to work. All changes mentioned in this bug discussion are about Southern Islands and Sea Islands parts (see Radeon Matrix [1]), sorry again. Alex, are there any patches for older generations? [1] http://xorg.freedesktop.org/wiki/RadeonFeature/
(In reply to Chernovsky Oleg from comment #77) > Yup, sorry, the HD6xxx parts are not supported by this software. They don't > have Overdrive6 capabilities required for it to work. > > All changes mentioned in this bug discussion are about Southern Islands and > Sea Islands parts (see Radeon Matrix [1]), sorry again. > > Alex, are there any patches for older generations? Older parts didn't have smc fan control so the default fan profile set up by the vbios is pretty good. However manual fan control is possible. I'll try and provide patches as I have time.
can it that be able to disable GPU fan completly? Just like `echo 0 > pwm1`
I'm testing commits "add common fan control asic callbacks" "bind fan control on SI cards to hwmon interface" "bind fan control on CI cards to hwmon interface (v2)" "bind fan control on CI cards to hwmon interface (v2)" "enable smc fan control on SI" from the repo agd5f on top of 3.19-rc6 with the fancontrol script from lm_sensors. I had to edit the script somewhat, since it expects a write of 1 to pwm1_enable and a write of 255 to pwm1 to not fail (the write to pwm1 fail since the script expects pwm1_max to be 255). The driver should probably follow the behaviour userspace expects.
I just tried kernel v4.0rc1 and my R9 280 is quiet :) Thank you !!
Everything is upstream now in kernel 4.0.
Hi, maybe this question is a bit silly, but how do I enable fan control? I just compiled and installed 4.0.0-rc1, but my fan is still spinning rather loudly. I'm using a Sapphire 7850 OC. Is the following the correct path for fan manipulations? /sys/class/drm/card0/device/hwmon/hwmon2 Below, I find the following pwm1/temp1 nodes: pwm1, pwm1_enable, pwm1_max, pwm1_min and temp1_input. cat pwm1_enable crashes my system. cat pwm1 -> 86 cat pwm1_max -> 255 cat pwm1_min -> 0 cat temp1_input -> 27000 Same result with 3.19 with patches applied mentioned in Comment #80 Do I have to set special kernel features or did I set special features I should not? Many thanks for your help. Raimund
... and I should add echo "50" > pwm1 also makes my computer hang.
I just tested this with kernel 4.0 (some pre version), and I just want to say big thank you to everyone involved. My system is now finally quiet, and everything seems to be working properly. Great work, folks.
Hello, I am using Lubuntu 14.04 with 2 Apple Monitors using 2 mini Display ports on my Gigabyte Radeon R7 250X OC and have the same issue: fan running fast while temperature is low. I never used this forum before and browsed the net for hours to find solutions. Can somebody explain to me what exactly to do to fix this? Best regards, Ben
Hi Ben, this is not a forum, it's a bug reporting tool. You'll need to wait until your distribution ships linux kernel 4.0 (I assume that would be Lubuntu 15.04 or 15.10). Then it should "just work". If it doesn't, you can create a new ticket here, report the issue, and attach all relevant information to it (ask for help at #radeon channel on freenode irc in that case).
(In reply to r.andersen from comment #84) > ... and I should add > > echo "50" > pwm1 > > also makes my computer hang. Exactly the same on my HD7850 (see [1]) on kernel v4.0. Are there maybe hints how to debug this ? [1] --- Linux gamix64 4.0.0-owi1+ #1 SMP Sat May 9 10:17:17 CEST 2015 x86_64 GNU/Linux --- 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 7850 2GB GDDR5 DVI-I/DVI-D/HDMI/DP Flags: bus master, fast devsel, latency 0, IRQ 36 Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at f5000000 (64-bit, non-prefetchable) [size=256K] I/O ports at a000 [size=256] [virtual] Expansion ROM at f4000000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150] Advanced Error Reporting Capabilities: [270] #19 Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] #13 Capabilities: [2d0] #1b Kernel driver in use: radeon ---
(In reply to Oliver Winker from comment #88) > (In reply to r.andersen from comment #84) > > ... and I should add > > > > echo "50" > pwm1 > > > > also makes my computer hang. > > Exactly the same on my HD7850 (see [1]) on kernel v4.0. > > Are there maybe hints how to debug this ? <snip> Sorry, I have no debug hints. For what it's worth, I have a nearly identical card and the same kernel version (see below), and both manual and automatic modes works flawlessly. $ uname -a Linux wallace 4.0.0-1-pelle #1 SMP PREEMPT Thu Apr 23 20:32:42 CEST 2015 x86_64 GNU/Linux $ sudo lspci -v 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850] (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device 2553 Flags: bus master, fast devsel, latency 0, IRQ 33 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at fe780000 (64-bit, non-prefetchable) [size=256K] I/O ports at b000 [size=256] Expansion ROM at fe7c0000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150] Advanced Error Reporting Capabilities: [270] #19 Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] #13 Capabilities: [2d0] #1b Kernel driver in use: radeon Kernel modules: radeon
In fact it seems that controlling the fans on my card using the ADL Overdrive6 api doesn't work. But it works using Overdrive5. When I modify Olegs test-program to use ADL_Overdrive5_FanSpeed[Get|Set|ToDefault_Set]() api indeed my fans react. So the next thing I guess would be to check the mmio-traces. In fact for me personally already the equivalent of ADL_Overdrive5_FanSpeedToDefault_Set() would be sufficient, since it seems to put the fan automagically to a good minimum.
Ufff - a complicated way to recognize that one day I actually put the mod-param radeon dpm=0 :-P ... while in the meanwhile dpm=1 actually works ;). Anyway, what a nice discovery: The fans are silent now! Great :)) !!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.