Yes, it doesn’t seem to be reported by any sensors that are exposed to the OS on Linux as far as I can tell (might just be my set up).
But you can use your ear sensors 
If reported CPU temp is high, especially >= 90C, and the fan is barely audible, or not at all, then there’s a problem with the configured fan behaviour.
I have the 7840U variant, which has a Tjmax of 100°C.
By use of my ear sensors, fans kicked in at CPU 96C and ramped up slowly. Kicking the temps down 10C.
Over sustained load, fan seems to ramp up and down randomly, almost sounds like the ocean. Guessing it’s reacting to temp changes in different parts of the system.
Now sitting at CPU 84C GPU (integrated) 70C with fans sounding low.
Completely normal.
Interesting. Glad to hear a normal result. I’m also with the 7840U.
Still…
amd_pstate do you have set? You can check this with cat /sys/devices/system/cpu/amd_pstate/statusFor the example I gave above I used stress -c 16 to spawn 16 threads of CPU compute load. CPU should shoot up almost immediately to 98-100C (which is expected) and the fan should, ideally, start to ramp up immediately, and reaching peak audible level not long after. 1m20s in my earlier post is too slow. I would expect peak audible RPM within 10 seconds.
I rarely see the GPU go above 70-75, which is fine.
I just re-ran my earlier experiment, first run started from CPU temp at 33C idle, ambient temperature 17C. The CPU stayed at 99C for good 40-50 sec before the fan became audible and again reached its loudest at 1m25s.
I run with latency-performance profile via thermald. AMD Pstate is listed as active.
I ran stress -c 16 to stress the system.
My fan is working as it should, seems like your fan profile is screwed up.
Thank you, tripplehelix. This is useful.
I just tried it with Fedora 39 and fan behaviour is exactly the same which rules out my Gentoo set up as the main culprit. It does appear to be a fan curve issue, the question is where does the fan curve come from other than the BIOS. I have no specific software (not even thermald) that could be interfering with the stock curve. I don’t remember having the same behaviour on 3.03.
There’s at least three of us in this thread that have observed this sluggish fan behaviour. Maybe @Matt_Hartley or @Kieran_Levin could shed some light on this? Or at least what the ‘intended’ fan response time(s) should be as a baseline comparison.
[Or, if there’s a process to follow to roll back to 3.03 I’d be happy to compare and see if this is a regression]
This is controlled by the EC. I agree the fan speed is smoothed out over way too long a period; it seemed sluggish to me way back in December too: Any reason NOT to buy the most-souped-up 13 AMD? Upside of lower tiers? - #15 by pierce
I find that it still takes 15-ish seconds to start spinning up, and over 30 seconds to reach the appropriate level for high load. As you say, maybe a minute to reach max, but perhaps reasonable after 30-40 seconds. Seems similar to 3.03.
You can use ectool to check fan speed, force a specific fan %, or switch back to auto fan speed. Check towards the end of this thread for how to get ectool: Exploring the Embedded Controller
Once you’ve got a working ectool:
$ sudo ectool pwmgetfanrpm all
Fan 0 RPM: 3916
$ sudo ectool fanduty 50
Fan duty cycle set for all fans.
$ sudo ectool autofanctrl 0
Automatic fan control is now on for fan 0
So anyway … yeah, would be nice if the fan responded faster, and if it was easier to adjust the auto-fan-ctrl. There may be a way, but I suspect you can’t make it respond faster: [RESPONDED] Changing the fan temperture points with ectool
Hello Steve-Tech, when you find some time could you expand on this a little more:
I originally used trial and error, e.g removed everything until the errors stopped. But
lsusb -vdoes report the PCI address via theiSerialdescriptor, so I mapped them out
After some more experimenting, using the charger, expansion cards, and a usbc thumb drive, I noticed that the following ports dont work:
working || not working
not working || working
I did try echo "on" to all of the usb hub hardware addresses printed by lsusb -v however they still do not react to devices being plugged in.
I think knowing more about which address is assigned to each port can help me determine if the issue is any one of the following:
Looking at the output from lsusb -v I find these entries:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 [unknown]
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 6.08
iManufacturer 3 Linux 6.8.5-301.fc40.x86_64 xhci-hcd
iProduct 2 xHCI Host Controller
iSerial 1 0000:c1:00.3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
But also
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.10
bDeviceClass 9 Hub
bDeviceSubClass 0 [unknown]
bDeviceProtocol 3
bMaxPacketSize0 9
idVendor 0x1d6b Linux Foundation
idProduct 0x0003 3.0 root hub
bcdDevice 6.08
iManufacturer 3 Linux 6.8.5-301.fc40.x86_64 xhci-hcd
iProduct 2 xHCI Host Controller
iSerial 1 0000:c1:00.3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x001f
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
bMaxBurst 0
I was hoping the number prior to the address would signify this however both have the same iSerial but different guids.
Bus 001 Device 001: ID 1d6b:0002
iSerial 1 0000:c1:00.3
Bus 002 Device 001: ID 1d6b:0003
iSerial 1 0000:c1:00.3Hi mikeymop,
After a weeks worth of use I haven’t seen this issue appear myself, but if it’s related to the USB controller not going into low power mode, maybe it isn’t coming out of low power mode either (although there should be dmesg warnings about this too).
This command will print the controller’s power state: cat /sys/bus/pci/devices/0000\:c1\:00.3/power_state
This command will disable the controller going into low power by itself: echo 0 > /sys/bus/pci/devices/0000\:c1\:00.3/d3cold_allowed
For reference (IIRC):
Basically still trial and error, I plugged something in, and recorded the Bus’ iSerial, it appears under.
USB controllers always have separate USB 2.0 and USB 3.0 busses, so the first one is 2.0 and the second one is 3.0.
Indeed, it was rhetorical They are separate, but tend to bundle them under the “BIOS” umbrella as they usually tend get updated at the same time.
Interesting, happy to hear these as it now seems unlikely to be isolated issue. It might be similar to 3.03, as I did notice a slower than ideal ramp up when I first got the FW13, but I still don’t remember it being so slow to respond. I regularly run heavy multi-core loads, to the extent that I need, as I do most demanding things on a desktop, and like to think I would have noticed.
Thanks for the link to the ectool guide link, I did actually come across it earlier while scouring the forums. I’m generally hesitant to make changes that aren’t exposed by the BIOS, but I might have a go at it and see if I can improve the situation.
It’s a shame that it might not be possible to change the response time. It’s not surprising though, as it’s rarely a setting on laptops.
Slight tangent: I did, in fact, have one a laptop from ca 2016 whose BIOS allowed very coarse control of the ‘fan curve’. Always linear, but allowed to specify “Δfan% duty cycle per Δt C” once t was above tfan-off. Response and transition time was probably on the msec level. Getting the values wrong would usually only result in more or less gradual ramp up and, if set too aggressive, it could lead to the annoyance of the fan constantly ramping up and down. But there was definitely a sweet spot.
I’ll throw my experience here. On powersaver, performance is what you would expect. Hits about 74C before the fans kick in and bring it down to 68ish, starting at 3.2 GHz but dropping to 2.8 GHz. On performance, I get to about 90 before the fans start kicking in hard (but not max). They’re able to keep the temp from going over 90 (one one test they did make it to 92). CPU was at 3.6 the entire time.
Installation worked fine with Fedora 39 LVFS for me. Can recommend.
I read your post before I updated to 3.05, so I was paying attention to the fan behavior while running Cinebench R23 (multi core). The benchmark with BIOS 3.03 and 3.05 runs the same, with the same score (about 13800 pts), and with both BIOS versions, the fan takes quite a while to start spinning (maybe 30 seconds?), when the CPU Tctl/Tdie temperature is around 85-90°C. It seems quite late, but it does not impact the benchmark. By the way, if you look at the notebookcheck.net review, you will see that they scored 13981 pts in Cinebench R23 (multi core) back in October 2023, so I’d say nothing negatively changed since then?
Thanks for the insight as well!
Yes, performance is as expected, this never changed for me. It’s exactly what I would expect from this form factor so no issues here. And once the fan kicks in in full, temperatures do settle 92-95C, as was always the case (which is fine).
I’m just surprised at how sluggish the fan is to ramp up. Maybe it was the same in 3.03, as with your experience. I’m not sure. But without downgrading to 3.03 I can’t really confirm. I always thought the fan was a bit slow to respond but seemed ‘okay’. Maybe I’m actively looking into it too much as a result of it being mentioned earlier?
In any case, I still don’t think that 30-40 seconds at roasting 100C is “healthy”, even if the CPU itself will throttle down. If this is has been the ‘expected behaviour’ up until now, perhaps something for the FW to look into in the future.
I’m having the same issue on debian sid.
What i find worrying is that the fans won’t ramp up at single core loads at all.
Here’s a graph of temp and fanrpm on my 3.05 bios 7840u for discussion.
I started cpu stressing at around 20 seconds. (where temp starts rising)
Installation happened mostly automatically with Fedora Silverblue 40 Beta using Gnome Software (LVFS) for me, just was kinda slow (a black screen for about 10-20 seconds, which were slightly concerning and then a very slow progress bar).
This Happened to me too, laptop shut down, stayed on black screen for ~3h. first time till i force restarted and said decompress failed. second time it shutdown because it ran out of battery, upgrade started on 100%.
My FW 13 Ryzen came with 3.03, so I’ve never done a bios update before. I see the simplest approach is this:
fwupdmgr --force refresh
I’m on Ubuntu 22.04.3; do I need to follow the instructions here:
to switch to the snap of fwupd first?
The longer description of how to do the update using a USB key seems more complicated; when would you need to do that? Is that for distros that don’t have the latest fwupd available?
All help appreciated,
Martin
@Martin_David_Holmes Yes, please follow the instructions in the article you’ve linked. I have scripted those instructions as follows (to make it a one-shot update):
#!/usr/bin/env bash
set -xe
fwupdmgr refresh --force
fwupdmgr get-updates
fwupdmgr update
Since you’re on Ubuntu 22.04, you’d also need to update fwupd before updating firmware:
sudo apt remove fwupd
snap install fwupd
Thank you!