[TLP 1.6 Beta] Call for testers

[linrunner]

Hi @all,

as with every upcoming release I need your help to complete the test coverage.

Test Objectives

• General regression testing (check if everything still works for you)
• Processor
  • CPU_DRIVER_OPMODE_ON_AC/BAT: check if scaling driver operation mode (active, guided, passive) works - amd-pstate (kernel 6.3/6.4) or _intelpstate driver required
  • CPU_ENERGY_PERF_POLICY_ON_AC/BAT: check if it works on support AMD Zen 2 or newer CPUs - amd-pstate driver (kernel 6.3+) required
• Battery care - check charge thresholds on:
  • LG Gram laptops using standard sysfs attribute _charge_control_endthreshold (kernel 5.18+)
  • System76 laptops with open source EC firmware (kernel 5.16+)
  • Toshiba/Dynabook laptops (kernel 6.0+)
• Suspend/Resume - test if you have been affected by the following issues:
  • https://github.com/linrunner/TLP/issues/587
  • https://github.com/linrunner/TLP/issues/593
  • https://github.com/linrunner/TLP/issues/606
  • https://github.com/linrunner/TLP/issues/698
  • Please remove the 1.5 workaround AHCI_RUNTIME_PM_ON_BAT=on beforehand
• Testing of other new and changed features that interest you → see release notes and changelog

Beta Packages See the download page.

What do I need from the testers? After installing please start the beta with

sudo tlp start

I'm expecting your unabbreviated outputs of

sudo tlp-stat

on battery and AC (via Gist please).

Bug Reports If something does not work as expected → please open an issue.

Thanks for testing!

[arvl130]

AC and Battery

[linrunner]

@arvl130 I am interested in the complete tlp-stat outputs, not only tlp-stat -b.

[arvl130]

@linrunner Fixed now. Forgot I had it aliased.

[LinuxOnTheDesktop]

tlp-stat for AC and for battery

[LinuxOnTheDesktop]

I think that the following bit of configuration info is new.

CAUTION: USB and IEEE1394 disks may fail to mount or data may get corrupted with APM enabled. Be careful and make sure you have backups of all affected media before removing 'usb' or 'ieee1394' from the denylist! Default: "usb ieee1394"

Can you tell me anything under the conditions under which APM can cause these problems? Are particular models of computer at issue?

EDITED to reduce the space taken up by the quote.

[IDeletedSystem64]

tlp-stat output

[linrunner]

@LinuxOnTheDesktop

I think that the following bit of configuration info is new.

Nothing new here. In fact the feature was introduced with 1.4 and it's disabled by default:

• https://github.com/linrunner/TLP/blob/main/changelog#L147
• https://github.com/linrunner/TLP/commit/d0fc6449260772a5d8d35265595c372be473dcbc

I included the warning as a precaution because of a rather old Ubuntu bug that is linked in the above commit. I have not observed any problems with APM on any of my USB disks. Many disks simply do not support APM. After all, you don't have to remove usb from of the denylist if unsure.

[linrunner]

@IDeletedSystem64 could you add the output on battery power?

[SotchNam]

tlp-stat report

[tisyang]

tlp-stat report

My cpu is amd r7-7840hs, kernel 6.4, use 1.6 beta tlp, if choose CPU_DRIVER_OPMODE_ON_AC/BAT = guided, the cpu is locked 400 ~ 900 Mhz. But choose active, cpu frequency is fine.

choose guided in tlp

 sudo cpupower -c 0-15 frequency-info | grep "current CPU" | grep Hz
  current CPU frequency: 547 MHz (asserted by call to kernel)
  current CPU frequency: 544 MHz (asserted by call to kernel)
  current CPU frequency: 549 MHz (asserted by call to kernel)
  current CPU frequency: 541 MHz (asserted by call to kernel)
  current CPU frequency: 546 MHz (asserted by call to kernel)
  current CPU frequency: 549 MHz (asserted by call to kernel)
  current CPU frequency: 548 MHz (asserted by call to kernel)
  current CPU frequency: 547 MHz (asserted by call to kernel)
  current CPU frequency: 548 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 547 MHz (asserted by call to kernel)
  current CPU frequency: 549 MHz (asserted by call to kernel)
  current CPU frequency: 545 MHz (asserted by call to kernel)
  current CPU frequency: 545 MHz (asserted by call to kernel)
  current CPU frequency: 545 MHz (asserted by call to kernel)

choose guided in tlp

sudo cpupower -c 0-15 frequency-info | grep "current CPU" | grep Hz
  current CPU frequency: 1.31 GHz (asserted by call to kernel)
  current CPU frequency: 1.27 GHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 3.20 GHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 1.29 GHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 1.30 GHz (asserted by call to kernel)
  current CPU frequency: 1.54 GHz (asserted by call to kernel)
  current CPU frequency: 1.30 GHz (asserted by call to kernel)
  current CPU frequency: 3.21 GHz (asserted by call to kernel)
  current CPU frequency: 2.80 GHz (asserted by call to kernel)

If set kernel parameter amd_pstate=guided, CPU frequency is fine too.

[linrunner]

@tisyang seems the kernel driver doesn't like switching at runtime. TLP cannot do anything about it.

ps. you may try configuring the frequencies

CPU_SCALING_MIN_FREQ_ON_AC=400000
CPU_SCALING_MAX_FREQ_ON_AC=5293000
CPU_SCALING_MIN_FREQ_ON_BAT=400000
CPU_SCALING_MAX_FREQ_ON_BAT=5293000

ps2. on my machine switching to guided works, frequencies are not locked.

[tisyang]

@tisyang seems the kernel driver doesn't like switching at runtime. TLP cannot do anything about it.

ps. you may try configuring the frequencies

CPU_SCALING_MIN_FREQ_ON_AC=400000
CPU_SCALING_MAX_FREQ_ON_AC=5293000
CPU_SCALING_MIN_FREQ_ON_BAT=400000
CPU_SCALING_MAX_FREQ_ON_BAT=5293000

ps2. on my machine switching to guided works, frequencies are not locked.

configuring frequencies does not work for guided mode, cpu frequency is still locked, it maybe a kernel or bios bug. Anyway, I will use active mode.

[siddhpant]

On AMD Ryzen 5500U with kernel 6.3 and amd-pstate=active (tlp-stat report), when I set CPU_SCALING_GOVERNOR_ON_* to performance, the EPP preference is set to performance regardless of CPU_ENERGY_PERF_POLICY_ON_* setting. This does not happen when the governor is powersave.

Manually setting the EPP preference results in the error bash: line 1: echo: write error: Device or resource busy. This does not happen when the governor is powersave.

[linrunner]

@siddhpant same on my machine (with 6.4.4). However, I think it is "works as designed" of the driver. I have read about this behavior elsewhere, I mean with _intelpstate.

Full throttle and brake at the same time doesn't seem to be provided. Makes sense, doesn't it?

ps. answer added to the FAQ.

[siddhpant]

@siddhpant same on my machine (with 6.4.4). However, I think it is "works as designed" of the driver. I have read about this behavior elsewhere, I mean with _intelpstate.

Full throttle and brake at the same time doesn't seem to be provided. Makes sense, doesn't it?

Yeah, that makes sense, thanks.

Just googled for confirmation, seems like it is the case on laptops [1], but on other hardware like EPYC, balance_performance is available [2] (but is probably none of our concern, and probably will work anyways).

Thanks for the release!

---

[1] https://www.phoronix.com/review/amd-pstate-epp-ryzen-mobile

[2] https://www.phoronix.com/review/linux-63-amd-epyc-epp

[linrunner]

@siddhpant

[1] https://www.phoronix.com/review/amd-pstate-epp-ryzen-mobile the powersave mode with ACPI CPUFreq and passive AMD P-State was very slow.

I can only shake my head. If you make strange comparisons, you get strange results.

It has always been known that acpi-cpufreq/powersave slows down the system to a crawl instead of saving power. That's why ondemand has been recommended for ages, and schedutil nowadays. acpi-cpufreq/powersave is no valid candidate for comparisons with *_pstate/powersave.

[siddhpant]

@linrunner Yes, I agree. It is an apples to oranges comparison. The only reason to do it is for completeness' sake (which is probably why I land up there when I search for p-state).

[linrunner]

@ALL thanks for your contributions so far.

[tisyang]

@linrunner

I found out, if

CPU_DRIVER_OPMODE_ON_AC=guided

CPU_SCALING_GOVERNOR_ON_AC=performance

The mode will be guided and CPU frequency is fine.

But

CPU_DRIVER_OPMODE_ON_AC=guided

CPU_SCALING_GOVERNOR_ON_AC=powersave

The mode will be guided, but CPU frequency will locked in 400~1000Mhz. This maybe not TLP's bug.

tlp-stat report

My cpu is amd r7-7840hs, kernel 6.4, use 1.6 beta tlp, if choose CPU_DRIVER_OPMODE_ON_AC/BAT = guided, the cpu is locked 400 ~ 900 Mhz. But choose active, cpu frequency is fine.

choose guided in tlp

 sudo cpupower -c 0-15 frequency-info | grep "current CPU" | grep Hz
  current CPU frequency: 547 MHz (asserted by call to kernel)
  current CPU frequency: 544 MHz (asserted by call to kernel)
  current CPU frequency: 549 MHz (asserted by call to kernel)
  current CPU frequency: 541 MHz (asserted by call to kernel)
  current CPU frequency: 546 MHz (asserted by call to kernel)
  current CPU frequency: 549 MHz (asserted by call to kernel)
  current CPU frequency: 548 MHz (asserted by call to kernel)
  current CPU frequency: 547 MHz (asserted by call to kernel)
  current CPU frequency: 548 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 547 MHz (asserted by call to kernel)
  current CPU frequency: 549 MHz (asserted by call to kernel)
  current CPU frequency: 545 MHz (asserted by call to kernel)
  current CPU frequency: 545 MHz (asserted by call to kernel)
  current CPU frequency: 545 MHz (asserted by call to kernel)

choose guided in tlp

sudo cpupower -c 0-15 frequency-info | grep "current CPU" | grep Hz
  current CPU frequency: 1.31 GHz (asserted by call to kernel)
  current CPU frequency: 1.27 GHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 3.20 GHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 1.29 GHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 400 MHz (asserted by call to kernel)
  current CPU frequency: 1.30 GHz (asserted by call to kernel)
  current CPU frequency: 1.54 GHz (asserted by call to kernel)
  current CPU frequency: 1.30 GHz (asserted by call to kernel)
  current CPU frequency: 3.21 GHz (asserted by call to kernel)
  current CPU frequency: 2.80 GHz (asserted by call to kernel)

If set kernel parameter amd_pstate=guided, CPU frequency is fine too.

[linrunner]

@tisyang

This maybe not TLP's bug.

Right. It's a driver issue. I would prefer to discuss this over in https://github.com/linrunner/TLP/issues/630#issuecomment-1651541950. I copied your post and have written my reply there.

[siddhpant]

Debian testing finally got 6.4 today, so I am now able to test guided mode, and switching between modes.

Relevant TLP Settings:

CPU_DRIVER_OPMODE_ON_AC=active
CPU_DRIVER_OPMODE_ON_BAT=guided

CPU_SCALING_GOVERNOR_ON_AC=performance
CPU_SCALING_GOVERNOR_ON_BAT=conservative

CPU_SCALING_MIN_FREQ_ON_BAT=400000
CPU_SCALING_MAX_FREQ_ON_BAT=1800000

The mode changes from active to guided and vice-versa successfully upon switching off/on the AC connection.

[lectrode]

Regarding https://github.com/linrunner/TLP/issues/587 , the original issue (USB ports stop working) still affects TLP 1.6 (installed tlp-git from AUR on Manjaro). That issue also effects integrated webcam and bluetooth (on internal USB hub).

The AHCI_RUNTIME_PM_ON_BAT=on workaround still works in 1.6.

Without the workaround, bluetooth stops working after a maximum of ~15 minutes. With the workaround, bluetooth stayed on for the 1.5 hours or so i tested it (on laptop battery the whole time).

tlp stat gist

[linrunner]

@self Relnotes: #587 only partly solved

[linrunner]

Thanks to all testers so far.

Is there anything else to report - positive or negative - from ongoing operation?

[linrunner]

@lectrode #587 has been removed from the changelog and FAQ adapted.

[linrunner]

Beta test is completed and TLP 1.6.0 is out. Have fun!

Sincere thanks to all testers! :+1: