Fedora - changes in pp_table don't persist after restart

[email protected]

Yes but you misunderstand the issue here. It's not about whether LACT or CoreCTRL is better. They only allow you to work within the default limits. For example max power limit is 312W on my card. By editing pp_table I can increase it to whatever I want. What I'm doing by editing pp_table is going beyond those limits and whether I use one application or another it does not matter. Also I switched from CoreCtrl to LACT because CoreCtrl on GNOME can't be minimized into tray so it was just annoying.

[email protected]

It will never be not funny

? Offline

Use triple backticks for blocks of code-type stuff

```

like so

```

::: spoiler example, wrapped in a spoiler tag.

upp -p /sys/class/drm/card1/device/pp_table dump
header:
  structuresize: 2470
  format_revision: 15
  content_revision: 0
table_revision: 2
table_size: 802
golden_pp_id: 2466
golden_revision: 16307
format_id: 128
platform_caps: 24
thermal_controller_type: 28
small_power_limit1: 0
small_power_limit2: 0
boost_power_limit: 0
software_shutdown_temp: 118
reserve:
  reserve 0: 0
  reserve 1: 0
  reserve 2: 0
  reserve 3: 0
  reserve 4: 0
  reserve 5: 0
  reserve 6: 1
  reserve 7: 0
power_saving_clock:
  revision: 1
  reserve:
... and so on ...

:::

? Offline

I'm not familiar with Radeon PowerPlay, so I don't know if there is a proper way to solve this, but you should be able to make a systemd system service to run the upp command on boot.

To do so, I think you can use the following:

[Unit]
Description=Run my_user_script
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target


[Service]
Type=oneshot
ExecStart=upp -p /sys/class/drm/card1/device/pp_table set --write smc_pptable/SocketPowerLimitAc/0=312 smc_pptable/SocketPowerLimitDc/0=293 smc_pptable/TdcLimit/0=300 smc_pptable/FreqTableSocclk/1=1350 smc_pptable/FreqTableFclk/1=2000 smc_pptable/FclkBoostFreq=2000

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

To configure this service:

Save the text (using sudo/root) to a new .service file in /etc/systemd/service. (e.g. /etc/systemd/system/my_update_pp.service)
run sudo systemctl daemon-reload to tell systemd to re-read the service files
run sudo systemctl restart my_update_pp.service to manually run the service
run sudo systemctl enable my_update_pp.service to tell systemd to run your service automatically on boot/wake (WantedBy tells systemd when it should include the unit/service, After, Wants, Requires, and Before help systemd decide the order to run all the units/services)

Notes

Usually for simple systemd services, you can omit After and set WantedBy to just WantedBy=multi-user.target, but if you also need to run upp after sleep or hibernate, then you probably need something more complex. I copied the After and WantedBy from a stackexchange answer, but I haven't tried using those targets before. You might have to add multi-user.target to the WantedBy list.
I don't actually know if you need to run upp after sleep/hibernate. Running on boot might be sufficient.
I think you can skip the chmod if you run upp as sudo/root. Systemd system services run as root by default.
I don't know how safe it is to mess with PowerPlay during boot. My gut says it's probably fine, but it also seems like something that could cause graphics to not work. Tread carefully.

References:

[email protected]

Thanks a lot. I will look into this.

Reason why I use chmod is because I cant for the life of me figure out why I can't just use sudo. Even when I set environment variable for the upp.py it refuses to run it. Even when I directly want to run it via sudo it refuses, I can only run it without sudo for whatever reason... but to overwrite pp_table I need sudo privileges and I've been only able to get around with chmod.

Also I've tried to make a script that I will just run and will execute the commands... but I get immediately hard lock and black screen and I need to do hard reset. Same when I try to copy and overwrite the pp_table with sudo priviledges with a pre-modified pp_table.

So I'm kinda hesitant to now run the commands on runtime, it's possible it will hardlock during boot. I will give it more though tommorrow.

[email protected]

I'm on gnome, no issues with corectrl minimising to tray

[email protected]

I also said pp out aloud and chuckled like a little boy.

[email protected]

My knowledge here is limited so I apologise if I'm not being helpful, but at least in case of Arch there's a special kernel flag (amdgpu.performancemask iirc) to allow OC of your graphics card, are you passing one in your setup?

[email protected]

Yes I do otherwise I wouldn't be able to OC.

I have to enable it after every Kernel update.

[email protected]

I'm sorry but I don't believe you. Maybe you just misunderstand what I've meant.

If you minimize it and press Super key, is it shown or it's completely gone?

[email protected]

Completely gone, only exists as an icon on my top bar

I can click show, get a window, and click hide and it goes away fully

I have it start on boot so my profiles auto apply when I start various apps

Would a screenshot be more convincing?

[email protected]

I also had it start on boot but I never could minimize it to be non-intrusive and from what I've researched it's apparently very known issue in GNOME.

I don't have this issue with LACT.

? Offline

Udev is the best way to add persistent values for pretty much everything in the sysfs. That being said, it can be a bit obtuse when first learning about it. Here are some tips

udevadm test /sys/path/to/device will tell you if your rule is running and what the state is at each step. You'll want to look at this before you start so you can see when your rule should run

udevadm info /sys/path/to/device will tell you what the PROPERTIES of a device are. These are usually set by hwdb files to inform userspace programs about the details of a device.

udevadm info /sys/path/to/device --attribute-walk will tell you about the ATTRIBUTES of a device and all it's parent devices. These correspond to the character file endpoints you are setting currently. You'll want to use these to write your match rules and set the values.

udevadm monitor can be used to watch for udev events to let you know if you should match on add, change, and/or remove.

Udev rules work as a cascading match system and they run in numerical and directory order. E.g. /usr/lib/udev/rules/60-keyboard.rules| will run before /etc/udev/rules.d/62-keyboard.rulesbut after/etc/udev/rules.d/60-keyboard.rules`

For user defined rules you will want to put them in /etc/udev/rules.d/ and keep in mind any state that needs to be set before or after your rule.

Matching happens with == or !=, setting attributes is done with =, +=, -=, or :=. := is really cool because you can use that to block changes from downstream rules. E.g. MODE:="666" will make the matched attribute r/w from unprivileged users, even if a later rule tries to set 400.

Udev rules will run in order in a file, but each rule must be a single line. Each attribute will also be set in order of the rule if setting multiple attributes in a rule. Multiple rules can be useful if you need to set attributes on multiple levels of a device, or in sibling directories.

For a complete breakdown of everything, see the udev manual: https://man.archlinux.org/man/udev.7

I also have a guide on one of my (currently out of tree) drivers that has some examples. https://github.com/ShadowBlip/ayn-platform?tab=readme-ov-file#changing-startup-defaults

Let me know if you have questions.

? Offline

You need to have this extension or similar to be able to minimize to tray on gnome: https://extensions.gnome.org/extension/615/appindicator-support/

[email protected]

Grow up (enough) and adjusting your pp becomes a chore.

[email protected]

That'd do it, standard inclusion with my distro

agnos.is Forums

Fedora - changes in pp_table don't persist after restart