Bug 203733

Have the Asus fx505dy (basically the 15 inch version) can confirm the problem. My current Kernel Version in usage: 5.1.7-1-default (OpenSuSE LEAP).

With 5.1.10-1-default also the same bug.  

And I meant OpenSuSE Tumbleweed, mixed them up each time.  

And also tried it with using the decicated GPU as well as the integrated, happens with both.

I had it 1 time. 
The speed of FAN CPU can be change (on Windows only-now... patch is work-in-progress for linux...) 
 There is 3 FAN mode: silence/normal/boost

look like silence mode is not enought for full load. In that mode CPU temp will go up tu 85°C living CPU to passe in protected mode (???) => 400MHz.

may be related to 
https://bugzilla.kernel.org/show_bug.cgi?id=204579

FAN speed patch for ASUS Notebook...
https://patchwork.kernel.org/patch/10943639/

But note 100% Working for Asus FX505DY I have...
https://github.com/hackbnw/faustus/issues/3

(In reply to djip.perois from comment #4)
> FAN speed patch for ASUS Notebook...
> https://patchwork.kernel.org/patch/10943639/
> 
> But note 100% Working for Asus FX505DY I have...
> https://github.com/hackbnw/faustus/issues/3

I have no Linux in asus fx505dy right now, I have returned the older because it has flickering screen. Now is working good, but with Linux the battery drains so much.. until a fix for the battery I will run windows( i am sad.. but the mobility is mandatory) for now

Not sure but may be good news:

https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-PSR-Patches-Ready

(In reply to djip.perois from comment #6)
> Not sure but may be good news:
> 
> https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-PSR-Patches-
> Ready

I think it is not related

(In reply to djip.perois from comment #4)
> But note 100% Working for Asus FX505DY I have...
> https://github.com/hackbnw/faustus/issues/3

Djip are you working on a kernel patch?
I made a patch that adds support for Fan Boost Mode on FX705DY, should I try to post it on ml?

My patch: https://pastebin.com/4bn7mmyr

I can confirm that LeonMaxx's patch also corrects this issue on my Asus FX505DY which is the 15" version of the device in this bug.  Hopefully his patch or something similar can be upstreamed to remove the need to recompile a custom kernel every upgrade.

hello, the people who have this patch in the build.. when the fan is in normal mode will it stop sometimes or is it running 100 percent of time?
with the official kernel and any change the fan stop sometimes it is the same as normal?

The fan throttles up and down as normal.  With basically no load my fan is silent and CPU temp is at 36c. I am unsure if the fan stops on a non-patched kernel, I didn't check that prior to patching my kernel.

You can control fan boost mode by pressing Fn+F5 or by writing mode number to /sys/devices/platform/asus_nb_wmi/fan_boost_mode:
0 - Normal
1 - Overboost
2 - Silent

(In reply to Gerdoch from comment #11)
> The fan throttles up and down as normal.  With basically no load my fan is
> silent and CPU temp is at 36c. I am unsure if the fan stops on a non-patched
> kernel, I didn't check that prior to patching my kernel.

(In reply to LeonMaxx from comment #12)
> You can control fan boost mode by pressing Fn+F5 or by writing mode number
> to /sys/devices/platform/asus_nb_wmi/fan_boost_mode:
> 0 - Normal
> 1 - Overboost
> 2 - Silent

yes, yes, I know that, the question is :
In normal mode the fan stop sometimes for use less power and be more silence when is possible or is it only in silent mode?

Yes, in normal mode the fan is silent when then system is idle.

Okey. Anda.. if the normal mode power off the fan like the silent does .. what are the differenc between them

(In reply to Gerdoch from comment #14)
> Yes, in normal mode the fan is silent when then system is idle.

For you, sorry for not mentioning before

So a fix was submitted to LKML at https://lkml.org/lkml/2019/11/24/51 but looked like it needed some revision due to stuff like a missing colon(?) - has there been any progress on this getting merged into the kernel itself?  Searching LKML hasn't found anything since that, so far as I can tell.

Just to be clear, the patch I linked works just fine if the kernel is manually patched and built, so I'm hoping that there's some progress getting them merged so these laptops will be usable without having to compile a new kernel every time there's a distro update.  Thanks!

Phoronix has reported about this fix https://www.phoronix.com/scan.php?page=news_item&px=ASUS-TUF-Ryzen-Thermal-Fix
and the commits are in git master:
https://github.com/torvalds/linux/commit/a28215844d8db87aadb9bcce040e7897691ff6ba
https://github.com/torvalds/linux/commit/2daa86e78c494d06d0aac231e4533f3dc50fa432


My laptop is the ASUS TUF FX505DY-BQ001T with R5-3550H + RX 560X.

I built linux git and indeed, on AC power it seems the laptop does not throttle anymore, so this seems fixed.

But it looks like there is indeed another issue:
On battery power the CPU is throttled to 400 MHz after running unigine heaven for 4 seconds on the dedicated GPU. The throttling stops when quitting unigine heaven, and it returns to normal frequencies. The throttling is not happening when running unigine heaven on the igpu.

Does this sound like a related issue or is it something completely different?

This sounds more like a power management issue.
If it is you can try set dGPU to power saving mode, TLP daemon can do this when running on battery. Options to set:

RADEON_POWER_PROFILE_*
RADEON_DPM_STATE_*

If it doesn't helps you can try my asus_fanmode daemon: https://github.com/leonmaxx/asus_fanmode

This may work if acpi switches mode to silent when running on battery.

ROG Zephyrus G14 with AMD Ryzen 4800HS & Nvidia 2060 maxq came across a similar problem. OS: Ubuntu 20.04 LTS with kernel 5.8.12

when push dGPU with 4 threads of TensorRT Neural Network Inferencing for like 10 seconds, the utilization of dGPU will drop from 99% to under 50% and the whole system and GNOME will be lagging very much.  It seems like 4800HS is throttling and not feding dGPU enough data. No matter how you cool down the system, it will not come back to normal performance until a system reboot.