You are not logged in.
I'm trying to configure a Zenbook 14 UX3405 in such a way that the cpu
fan almost never spins up. In other words, throttle frequencies over
raising temperatures. I'm using the intel_pstate module which is
correct for my chipset. No matter how I configure it, the cores aren't
throttled enough when the system is under load. I have tried
acpi-cpufreq too, but I can't get that one to work either.
Here are some of my /sys configuration settings:
$ cat /sys/devices/system/cpu/intel_pstate/status
active
$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
25
$ cat /sys/devices/system/cpu/intel_pstate/no_turbo
1
$ cat /sys/devices/system/cpu/intel_pstate/hwp_dynamic_boost
0
$ cat /sys/devices/system/cpu/cpu*/power/energy_perf_bias
15
...
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
...
$ cat /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
power
There's
[url=https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html]good
documentation[/url] for how power management works in Linux, but the
number of knobs you can turn is quite overwhelming. Anyway, when I
continuously load all cores for several minutes, this is what happens:
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq | sort -n
1000111
1000111
1000116
1000117
1000128
1000129
1000130
1000135
1099997
1099999
1999987
1999987
1999993
1999993
1999993
1999993
2000000
2000000
2000006
2000006
2000006
2000006
$ sensors -A
coretemp-isa-0000
Package id 0: +68.0°C (high = +110.0°C, crit = +110.0°C)
Core 0: +67.0°C (high = +110.0°C, crit = +110.0°C)
Core 1: +67.0°C (high = +110.0°C, crit = +110.0°C)
Core 2: +67.0°C (high = +110.0°C, crit = +110.0°C)
Core 3: +68.0°C (high = +110.0°C, crit = +110.0°C)
Core 4: +68.0°C (high = +110.0°C, crit = +110.0°C)
Core 5: +67.0°C (high = +110.0°C, crit = +110.0°C)
Core 6: +67.0°C (high = +110.0°C, crit = +110.0°C)
Core 7: +68.0°C (high = +110.0°C, crit = +110.0°C)
Core 8: +69.0°C (high = +110.0°C, crit = +110.0°C)
Core 12: +68.0°C (high = +110.0°C, crit = +110.0°C)
Core 16: +67.0°C (high = +110.0°C, crit = +110.0°C)
Core 20: +66.0°C (high = +110.0°C, crit = +110.0°C)
Core 24: +68.0°C (high = +110.0°C, crit = +110.0°C)
Core 28: +67.0°C (high = +110.0°C, crit = +110.0°C)
Core 32: +67.0°C (high = +110.0°C, crit = +110.0°C)
Core 33: +67.0°C (high = +110.0°C, crit = +110.0°C)
ucsi_source_psy_USBC000:002-isa-0000
in0: 0.00 V (min = +0.00 V, max = +0.00 V)
curr1: 0.00 A (max = +0.00 A)
asus-isa-0000
cpu_fan: 3700 RPM
So about half the cores reaches 2 GHz, while the others stay at around
1 GHz. However, that is not throttled enough since the fan spins up to
3700 rpm which produces a very annoying whining sound. How can I
throttle the cpu more so that the fan doesn't spin up?
Interestingly, the temperature never exceeds 70.0°C which I think is a
much too low limit. TJ for the cpu is 110°C so it could easily operate
in the 80-90 degree range. But afaik, the fan speed can't be manually
controlled.
Offline
$ cat /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
power
Set it to balance_performance or higher. I would also try to install tuned.
Also take look at https://wiki.archlinux.org/title/CPU_fr … cy_scaling
Offline
$ cat /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference power
Set it to balance_performance or higher. I would also try to install tuned.
Also take look at https://wiki.archlinux.org/title/CPU_fr … cy_scaling
Why balance_performance? Wouldn't that increase the fan noise? I've looked at some daemons but afaict they are all interfacing with /sys so I might as well tweak the settings directly myself.
Offline
Sorry, I missed part of your initial post. I think you need to configure fan separately to achieve this, I searched the web, it looks like this laptop's fan control is just not good
Can you check if https://github.com/dominiksalvet/asus-fan-control works for you?
Offline
Sorry, I missed part of your initial post. I think you need to configure fan separately to achieve this, I searched the web, it looks like this laptop's fan control is just not good
Can you check if https://github.com/dominiksalvet/asus-fan-control works for you?
Just tried that and I'm getting the error message:
acpi_call: Cannot get handle: Error: AE_NOT_FOUND
So maybe my mb doesn't have the required acpi stuff for controlling fan speed?
Offline
I would like to see your acpidump, if you don't mind. Install acpica package, run acpidump and feed its output to pastebin e.g.
# acpidump | curl -F 'file=@-' https://0x0.st
Offline
I would like to see your acpidump, if you don't mind. Install acpica package, run acpidump and feed its output to pastebin e.g.
# acpidump | curl -F 'file=@-' https://0x0.st
Sorry, forgot about this. Here is my acpi data: https://0x0.st/8iST.txt
Offline
Try to apply this patch:
diff --git a/src/asus-fan-control b/src/asus-fan-control
index 6dc6dc7..c4904b1 100755
--- a/src/asus-fan-control
+++ b/src/asus-fan-control
@@ -38,8 +38,8 @@ init_constants() {
readonly VERSION=3.15.0
# ACPI related constants
- readonly ACPI_WRITE_COMMAND='\_SB.PCI0.LPCB.EC0.WRAM' # write to ACPI
- readonly ACPI_READ_COMMAND='\_SB.PCI0.LPCB.EC0.RRAM' # read from ACPI
+ readonly ACPI_WRITE_COMMAND='\_SB.PC00.LPCB.EC0.WRAM' # write to ACPI
+ readonly ACPI_READ_COMMAND='\_SB.PC00.LPCB.EC0.RRAM' # read from ACPI
}
# DESCRIPTION:
Edit: typo in patch
Last edited by yataro (2025-01-05 11:39:03)
Offline
Try to apply this patch:
diff --git a/src/asus-fan-control b/src/asus-fan-control index 6dc6dc7..c4904b1 100755 --- a/src/asus-fan-control +++ b/src/asus-fan-control @@ -38,8 +38,8 @@ init_constants() { readonly VERSION=3.15.0 # ACPI related constants - readonly ACPI_WRITE_COMMAND='\_SB.PCI0.LPCB.EC0.WRAM' # write to ACPI - readonly ACPI_READ_COMMAND='\_SB.PCI0.LPCB.EC0.RRAM' # read from ACPI + readonly ACPI_WRITE_COMMAND='\_SB.PC00.LPCB.EC0.WRAM' # write to ACPI + readonly ACPI_READ_COMMAND='\_SB.PC00.LPCB.EC0.RRAM' # read from ACPI } # DESCRIPTION:
Edit: typo in patch
Thanks for the tip. I applied the patch and now I don't get the AE_NOT_FOUND error anymore. It seems asus-fan-control can read the temperature settings, but not write to them:
$ sudo ./asus-fan-control get-temps
55 56 57 58 59 60 61 62
$ sudo ./asus-fan-control set-temps 56 57 58 59 60 61 62 63
$ sudo ./asus-fan-control get-temps
55 56 57 58 59 60 61 62
I've both tried with intel_pstate disabled and enabled.
Offline
AE_NOT_FOUND is gone but I checked and the method requires 3 arguments now. Apply this one too:
diff --git a/src/asus-fan-control b/src/asus-fan-control
index 8708abc..cf73078 100755
--- a/src/asus-fan-control
+++ b/src/asus-fan-control
@@ -407,7 +407,7 @@ check_acpi() (
# $2 - temperature
write_acpi_temp() (
# ACPI write call (invalid arguments may cause the current shell to exit)
- echo "$ACPI_WRITE_COMMAND ${1:?} ${2:?}" > "$ACPI_CALL_PATH" &&
+ echo "$ACPI_WRITE_COMMAND 0x81 ${1:?} ${2:?}" > "$ACPI_CALL_PATH" &&
get_acpi_result > /dev/null # only check whether write was successful
)
Offline
AE_NOT_FOUND is gone but I checked and the method requires 3 arguments now. Apply this one too:
diff --git a/src/asus-fan-control b/src/asus-fan-control index 8708abc..cf73078 100755 --- a/src/asus-fan-control +++ b/src/asus-fan-control @@ -407,7 +407,7 @@ check_acpi() ( # $2 - temperature write_acpi_temp() ( # ACPI write call (invalid arguments may cause the current shell to exit) - echo "$ACPI_WRITE_COMMAND ${1:?} ${2:?}" > "$ACPI_CALL_PATH" && + echo "$ACPI_WRITE_COMMAND 0x81 ${1:?} ${2:?}" > "$ACPI_CALL_PATH" && get_acpi_result > /dev/null # only check whether write was successful )
Hello! I tried you new patch and I can set the temperatures with the script. Reading them however produces the following warning:
ACPI Warning: \_SB.PC00.LPCB.EC0.RRAM: Insufficient arguments - Caller passed 1, method requires 2 (20240827/nsarguments-232)
If I add 0x81 to the code in read_acpi_temp the warning stops, but the values read are always only 129:
sudo ./asus-fan-control get-temps
129 129 129 129 129 129 129 129
Regardless I've tried various settings for set-temps, like very low temperatures (30 31 32 33 34 35 36 37) or very high (70 .. 77), but it has no effect on the fan It always spins up at around the same temperature.
Last edited by bjourne (2025-01-06 22:30:53)
Offline
Read errors can be ignored, I haven't figured out how to call it properly then, unlike the write call, which just doesn't work. Sorry, I don't have a device with similar acpi to test it, so it will be all trial and error Let's give up on this script, can you try these calls?
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.WRAM 0x81 0x0521 0xc5' > /proc/acpi/call && cat /proc/acpi/call" # should set fan to 100%
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RRAM 0x80 0x0521' > /proc/acpi/call && cat /proc/acpi/call" # read it back
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.TACH 0x0' > /proc/acpi/call && cat /proc/acpi/call" # speed of 1st fan
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.TACH 0x1' > /proc/acpi/call && cat /proc/acpi/call" # speed of 2nd fan
Next, try to dump EC with this script: https://gist.github.com/HorstBaerbel/42 … 2cc7363241
Apply the following patch:
--- monitor_ec.py.old 2025-01-07 07:20:31.465817577 +0000
+++ monitor_ec.py.new 2025-01-07 07:22:43.166125001 +0000
@@ -53,7 +53,7 @@
stdout_print('\n')
counter = 0;
for addr in range(startaddr, endaddr+1):
- cmd = '\_SB.PCI0.LPCB.EC0.RRAM {}'.format(hex(addr))
+ cmd = '\_SB.PC00.LPCB.EC0.RRAM 0x80 {}'.format(hex(addr))
result = call_acpi(cmd)
if (counter == 0):
stdout_color(0)
Last edited by yataro (2025-01-07 09:16:21)
Offline
Hello again. Sorry for the late reply.
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.WRAM 0x81 0x0521 0xc5' > /proc/acpi/call && cat /proc/acpi/call" # should set fan to 100% sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RRAM 0x80 0x0521' > /proc/acpi/call && cat /proc/acpi/call" # read it back sudo sh -c "echo '\_SB.PC00.LPCB.EC0.TACH 0x0' > /proc/acpi/call && cat /proc/acpi/call" # speed of 1st fan sudo sh -c "echo '\_SB.PC00.LPCB.EC0.TACH 0x1' > /proc/acpi/call && cat /proc/acpi/call" # speed of 2nd fan
Here is the output of the commands:
$ sudo sh -c "echo '\_SB.PC00.LPCB.EC0.WRAM 0x81 0x0521 0xc5' > /proc/acpi/call && cat /proc/acpi/call"
0x1%
Fan speed is unchanged. 0x1 is an error code, isn't it?
$ sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RRAM 0x80 0x0521' > /proc/acpi/call && cat /proc/acpi/call"
0x0%
And for the last two commands
$ sudo sh -c "echo '\_SB.PC00.LPCB.EC0.TACH 0x0' > /proc/acpi/call && cat /proc/acpi/call"
0xffffffff%
$ sudo sh -c "echo '\_SB.PC00.LPCB.EC0.TACH 0x1' > /proc/acpi/call && cat /proc/acpi/call"
0xffffffff%
Btw, this is with intel_pstate loaded. I fixed the script and used it to dump the EC range 1000 to 2000. The result is here: https://gist.github.com/bjourne/81ea186 … 324f5712b8 The script does something with my hardware. Every other cycle it starts and stops the fan and attaches and detaches the touchpad. Odd, since it is only supposed to read from the embedded memory.
Offline
Fan speed is unchanged. 0x1 is an error code, isn't it?
No, it should always return 0x1
And for the last two commands
That's off, your machine is not following what other ASUS devices (normally) do. 0xffffffff is an error code, if we look at .TACH, it errors only if tachometer reading is zero or when argument (FAN #) is invalid, that's is not the case
Btw, this is with intel_pstate loaded.
It doesn't interfere with ACPI so that's not the problem.
The script does something with my hardware. Every other cycle it starts and stops the fan and attaches and detaches the touchpad.
Could be side effect of locking EC but I don't know for sure
Okay, let's try these:
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RTAH 0x0' > /proc/acpi/call && cat /proc/acpi/call" # try to read fan speed directly
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RRAM 0xCC 0x30' > /proc/acpi/call && cat /proc/acpi/call" # max fan speed?
sudo sh -c "echo '\_SB.ATKD.WMNB 0x0 0x53564544 b130011000100000000000000' > /proc/acpi/call && cat /proc/acpi/call" # max fan ON
sudo sh -c "echo '\_SB.ATKD.WMNB 0x0 0x53564544 b130011000000000000000000' > /proc/acpi/call && cat /proc/acpi/call" # max fan OFF
Offline
Okay, let's try these:
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RTAH 0x0' > /proc/acpi/call && cat /proc/acpi/call" # try to read fan speed directly sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RRAM 0xCC 0x30' > /proc/acpi/call && cat /proc/acpi/call" # max fan speed? sudo sh -c "echo '\_SB.ATKD.WMNB 0x0 0x53564544 b130011000100000000000000' > /proc/acpi/call && cat /proc/acpi/call" # max fan ON sudo sh -c "echo '\_SB.ATKD.WMNB 0x0 0x53564544 b130011000000000000000000' > /proc/acpi/call && cat /proc/acpi/call" # max fan OFF
Here is the output of the commands:
$ sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RTAH 0x0' > /proc/acpi/call && cat /proc/acpi/call"
0x6e4
$ sudo sh -c "echo '\_SB.PC00.LPCB.EC0.RRAM 0xCC 0x30' > /proc/acpi/call && cat /proc/acpi/call"
0x85
$ sudo sh -c "echo '\_SB.ATKD.WMNB 0x0 0x53564544 b130011000100000000000000' > /proc/acpi/call && cat /proc/acpi/call"
0x1
$ sudo sh -c "echo '\_SB.ATKD.WMNB 0x0 0x53564544 b130011000000000000000000' > /proc/acpi/call && cat /proc/acpi/call"
0x1
The third and fourth command turns the fan on and off. But after I've turned the fan off it will automatically turn on again as the core temperatures rise. 0x6e4 matches the fan speed "sensors" reports. Not sure what 0x85 means though.
Offline
0x85 appears to be a bitset with fan (or maybe some other) settings, the 3rd and 4th commands change 7th bit
That's something, I can see the pattern from a similar device. Try these:
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.ST98 127' > /proc/acpi/call && cat /proc/acpi/call" # limit fan to 50%
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.ST98 63' > /proc/acpi/call && cat /proc/acpi/call" # limit fan to 25%
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.ST98 25' > /proc/acpi/call && cat /proc/acpi/call" # limit fan to 10%
sudo sh -c "echo '\_SB.PC00.LPCB.EC0.ST98 255' > /proc/acpi/call && cat /proc/acpi/call" # limit fan to 100%
If it doesn't work, try dump again, https://gist.github.com/HorstBaerbel/42 … 2cc7363241 with these patches, one patch at the time
patch 1:
--- monitor_ec.py.old 2025-01-22 06:11:29.138960482 +0000
+++ monitor_ec.py.new 2025-01-22 06:15:02.649264292 +0000
@@ -53,7 +53,7 @@
stdout_print('\n')
counter = 0;
for addr in range(startaddr, endaddr+1):
- cmd = '\_SB.PCI0.LPCB.EC0.RRAM {}'.format(hex(addr))
+ cmd = '\\_SB.PC00.LPCB.EC0.RRAM 0xCC {}'.format(hex(addr))
result = call_acpi(cmd)
if (counter == 0):
stdout_color(0)
@@ -76,8 +76,8 @@
def main():
parser = argparse.ArgumentParser()
- parser.add_argument('start', type=auto_int, default=0x500, help='Start adress of the range in hex (e.g. 0x500)')
- parser.add_argument('end', type=auto_int, default=0x5ff, help='End adress of the range in hex (e.g. 0x5ff)')
+ parser.add_argument('start', type=auto_int, default=0x0, help='Start adress of the range in hex (e.g. 0x500)')
+ parser.add_argument('end', type=auto_int, default=0x100, help='End adress of the range in hex (e.g. 0x5ff)')
parser.add_argument('-i', '--interval', type=float, default=1.0, help='Update interval in seconds (e.g. 1.5)')
args = parser.parse_args()
try:
patch 2:
--- monitor_ec.py.old 2025-01-22 06:11:29.138960482 +0000
+++ monitor_ec.py.new 2025-01-22 06:16:03.500350629 +0000
@@ -53,7 +53,7 @@
stdout_print('\n')
counter = 0;
for addr in range(startaddr, endaddr+1):
- cmd = '\_SB.PCI0.LPCB.EC0.RRAM {}'.format(hex(addr))
+ cmd = '\\__SB.PC00.LPCB.EC0.RRAM 0xCD {}'.format(hex(addr))
result = call_acpi(cmd)
if (counter == 0):
stdout_color(0)
@@ -76,8 +76,8 @@
def main():
parser = argparse.ArgumentParser()
- parser.add_argument('start', type=auto_int, default=0x500, help='Start adress of the range in hex (e.g. 0x500)')
- parser.add_argument('end', type=auto_int, default=0x5ff, help='End adress of the range in hex (e.g. 0x5ff)')
+ parser.add_argument('start', type=auto_int, default=0x0, help='Start adress of the range in hex (e.g. 0x500)')
+ parser.add_argument('end', type=auto_int, default=0x100, help='End adress of the range in hex (e.g. 0x5ff)')
parser.add_argument('-i', '--interval', type=float, default=1.0, help='Update interval in seconds (e.g. 1.5)')
args = parser.parse_args()
try:
Offline