Repository navigation
Suggestion: Set correct PL1 on Surface Laptop 3 to avoid sudden throttling #1917
Description
Activity
Not sure that can/should be addressed in the kernel itself, or even where it gets the defaults from. Probably something should set them from user-space, if you want to change them.
Apart from that: Did you try switching platform profiles?
Thank you for the feedback. I have tested switching to the performance profile (without
thermald). While it slightly delays the onset of the 200MHz throttle, it does not prevent it.Hi. I have SL3 with i5-1035G7 with Ubuntu 25.10 , my constraint_0_power_limit_uw was set to 20w. Can confirm that lowering it to 15W fixed this throttling issue.
I found that disabling BD PROCHOT also helps with solving this issue, but there might be some risks involved. https://github.com/fralapo/Disable-BD-PROCHOT-on-LINUX
#!/bin/bash modprobe msr rdmsr 0x1FC wrmsr 0x1FC 2c005d modprobe msr rdmsr 0x1FC wrmsr 0x1FC 2c005dFix for surface laptop 3 regarding unstable system clocks and temperatures and the core issue.
Hardware
- Surface Laptop 3 13"
- i7-1065G7
- Kernel: 6.18.7-surface-1
- Linux Mint 22.3 Cinnamon
The problem
The main problem is the ACPI tables giving incorrect power limits as shown below. The VRM's cannot provide 61W, let alone 200W which leads to voltage droop and instability as the CPU tries to pull 200W. Temperatures rise, the firmware panics as there are no valid trip points, ACPI PPC signals to throttle the CPU as the cooling would be inadequate for 200W, which in the end leads to the CPU sitting at 200MHz, with fans on full power until it cools down around 50-55*C.
## Output before fix for power limits cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw 200000000 cat /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw 61000000 cat /sys/class/powercap/intel-rapl:0/constraint_0_max_power_uw 15000000Although the PL1 max power is set to 15W as should be, the actual maximum is 200W and that's what the CPU will try and inevitably fail to pull. These values are pulled from the ACPI firmware.
As discussed, ACPI tables have no valid trip points for each of the 7 thermal zones as shown below, which may also contribute to the instability, but more testing is required to prove or disprove that.## Output - not valid trip points dmesg | grep -i "thermal\|trip" [ 0.181865] CPU0: Thermal monitoring enabled (TM1) [ 0.204087] thermal_sys: Registered thermal governor 'fair_share' [ 0.204087] thermal_sys: Registered thermal governor 'bang_bang' [ 0.204087] thermal_sys: Registered thermal governor 'step_wise' [ 0.204087] thermal_sys: Registered thermal governor 'user_space' [ 0.204087] thermal_sys: Registered thermal governor 'power_allocator' [ 0.604631] ACPI: thermal: [Firmware Bug]: No valid trip points! [ 0.604750] thermal LNXTHERM:00: registered as thermal_zone0 [ 0.604753] ACPI: thermal: Thermal Zone [TZ01] (27 C) [ 0.604882] ACPI: thermal: [Firmware Bug]: No valid trip points! [ 0.604969] thermal LNXTHERM:01: registered as thermal_zone1 [ 0.604971] ACPI: thermal: Thermal Zone [TZ02] (27 C) [ 0.605095] ACPI: thermal: [Firmware Bug]: No valid trip points! [ 0.605178] thermal LNXTHERM:02: registered as thermal_zone2 [ 0.605180] ACPI: thermal: Thermal Zone [TZ05] (27 C) [ 0.605303] ACPI: thermal: [Firmware Bug]: No valid trip points! [ 0.605396] thermal LNXTHERM:03: registered as thermal_zone3 [ 0.605398] ACPI: thermal: Thermal Zone [TZ06] (27 C) [ 0.605523] ACPI: thermal: [Firmware Bug]: No valid trip points! [ 0.605605] thermal LNXTHERM:04: registered as thermal_zone4 [ 0.605607] ACPI: thermal: Thermal Zone [TZ07] (27 C) [ 0.605733] ACPI: thermal: [Firmware Bug]: No valid trip points! [ 0.605815] thermal LNXTHERM:05: registered as thermal_zone5 [ 0.605817] ACPI: thermal: Thermal Zone [TZ08] (27 C) [ 0.605941] ACPI: thermal: [Firmware Bug]: No valid trip points! [ 0.606023] thermal LNXTHERM:06: registered as thermal_zone6 [ 0.606025] ACPI: thermal: Thermal Zone [TZ09] (27 C) [ 2.813226] proc_thermal 0000:00:04.0: enabling device (0000 -> 0002) [ 3.507745] Consider using thermal netlink events interface
The Fix
Step 1 - In grub, prevent ACPI from forcing throttling (PPC ignore)
sudo nano /etc/default/grub
Modify:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"To:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash processor.ignore_ppc=1"And apply:
sudo update-grub
Step 2 - Power limit correction
Create a systemd service to correct power limits on boot:
sudo nano /etc/systemd/system/surface-power-fix.service
In the file add:
[Unit] Description=Fix Intel RAPL Power limits for surface laptop 3 After=sysinit.target [Service] Type=oneshot ExecStart=/bin/bash -c 'while [ ! -f /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw ]; do sleep 1; done; echo 20000000 > /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw' ExecStart=/bin/bash -c 'echo 25000000 > /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw' [Install] WantedBy=multi-user.target
Enable:
sudo systemctl enable surface-power-fix.service sudo systemctl start surface-power-fix.serviceReboot and check if the fix is applied (values should match):
cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw 20000000 cat /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw 25000000
Power limit rationale
20W PL1 is above intel's base for better performance, but may diminish battery life, if performance is not a issue, change fix service script from 20000000 to 15000000.
25W PL2 is below intel's default turbo specification (28W designed) which may help to keep the laptop cooler and quieter, slightly diminishing performance. If higher performance is needed, change fix script at second ExecStart from 25000000 to 28000000.Recommended configuration: 20W for PL1, 25W for PL2 as sweet spot on this model. Mileage may vary based on your chip (silicon lottery), age of thermal paste and overall cooling solution cleanliness, monitor temperatures and adjust if needed.
Windows comparison:
Found reports of identical throttling issues on Windows forums. Microsoft's "fix" is driver-level power management. Confirms this is firmware bug, not Linux issue.Results
Metric Before Fix After Fix Idle temp 50°C 46°C Load temp 100°C (throttling) 75°C (stable) Load frequency 200MHz (throttled) 2.4-3.0GHz Fan behavior 100% constantly Moderate, quiet Usability Severely degraded Normal Battery life Poor Significantly improved Testing methodology:
- Stress test:
stress --cpu 4 --timeout 60s, alongside background video streaming at 1080p60 - Monitoring:
sensorsfor temps,/proc/cpuinfofor frequencies - Load test: Normal workloads (web browsing, video playback, light games)
Proposal: Automatic Kernel Quirk
Current situation:
- Users must manually apply this fix
- Easy to miss or misconfigure
- Risk of thermal damage from 200W power attempts
Suggested solution:
Add an automatic quirk to the linux-surface kernel that:- Detects Surface Laptop 3 via DMI matching
- Applies
processor.ignore_ppcequivalent automatically - Overrides RAPL power limits to safe values (20W/25W)
- Logs a warning about the firmware bug
Benefits:
- Works out-of-box for all SL3 users
- Prevents potential hardware damage
- Improves linux-surface adoption on SL3
Question for maintainers
Is there a plan to add this as an automatic quirk for SL3? Happy to help test patches or provide additional diagnostic data.
Reacted by Ciro Lucio Tecce
On Surface Laptop 3 under Linux, I noticed that the CPU can suddenly drop to very low frequencies (~200 MHz) under sustained load. This appears to be triggered by the CPU hitting its long-term power limit (PL1).
The default PL1 reported by Linux is much higher than the official TDP.
Example on my system: PL1 = 25 W, official TDP = 15 W.
After changing PL1 to match the official TDP (15 W), stress testing runs normally and the CPU temperature stays under control.
I’m not sure whether other Surface models exhibit the same issue, but it might be worth checking on similar devices.