Got some goodies for you with only a few days until F39 final!
If you’re curious about F39 we’ve been building those images for weeks now so if you’re not affected by an F39 blocker you can switch to it and give it a shot. I’ve personally been switching back and forth just to keep track of development. Not having to reinstall to try a new version of something is a great feature!
We’ve landed some new wallpapers in the images with both light and dark variants.
I’ve been running Silverblue F39 beta on my AMD Framework, and it works incredibly well. So well that I have been scared to rebase to ublue, even though I know in theory it should be safe, but I am just getting used to immutable OS for the first time. Will hopefully try it when F39 lands!
It seems that currently the kernel parameter amdgpu.sg_display=0 is at least somewhat helpful in mitigating graphical corruption issues that occur with AMD. Not sure if that is possible to add.
Be careful with this; the default feature mask upstream is intentional.
amd_pstate=active
This is controlled by a Kconfig option. Unless it’s been changed in your kernel config it’s unnecessary.
amdgpu.sg_display=0
If you’re affected by an issue that needs this, can you please try turning off PSR (amdgpu.dcdebugmask=0x10) and see if that helps it instead? If so; that’s a much better workaround until the underlying issue is fixed.
should also be in there for decreased power draw. And yeah one of the fixups to make sure power is set for the energy performance profile (hopefully cpupower gets support for setting this natively soon).
And yeah the amdgpu mask exposure hasn’t seemed to break things for me at all (i get little to no difference with or without it through multiple different kernels)
I believe I read somewhere amd is working on a better way of handling gpu power features than what the current system allows for anyway, so at some point hopefully it isn’t needed. At the moment it’s primarily useful on desktop GPU’s - corectl seems to expose the same bits on the phoenix apu with or without it.
My issues seemed to be preceded by related to a iommu/VI extension errors ; and resulted in graphical lockups during power state changes (resume/sleep) where I would get a whited out screen. I’ll try with the debug mask you suggested and see how It goes. But if you could elucidate on that flag a bit, would be super appreciative.
These can be a bit too aggressive. I would watch out for PCIe instability or decreased NVME or Wifi performance. If they are stable, it’s best for Framework to adjust the default policies in the BIOS rather than the “big hammer” in Linux like that.
I understand scatter gather disabling vaguely.
This forces all memory allocations to go into VRAM instead of GTT. Turning up the VRAM values in BIOS has a similar effect because more allocations can go into VRAM.
It disables the panel self refresh feature in the Display Core (DC) part of the driver. You can find some high level descriptions in DisplayPort - Wikipedia along with some better links that are more in depth.
In the public AMD bug tracker there are a number of issues open and reported about PSR that are still under investigation, but none of them have been reported on Framework (IIRC) so I’d like to understand if this folds into those issues or is something completely separate.
Yeah - I haven’t noticed anything ‘so far’ with the aspm options set. I got major issues withe the nvme_noacpi option that was suggested in the tlp thread. Including hard lockups and btrfs corruption… so yeah. Will see.
@Mario_Limonciello ; Ok so the Whited-out screen on resume has returned with the amdgpu.dcdebugmask=0x10 suggestion in lieu of amdgpu.sg_display=0
reverting to Scatter Gather disabling for the moment.
Interesting new error that I am seeing in addition to the IOMMU ones previously posted is the attached. I believe there is something about atomic operations changing in drm layer at the moment and this is likely as i’m running 6.7 which has a bunch of amdgpu related patches and mesa 24.
I wanted to share that I have been running my own custom Kinoite image for the Framework 13 AMD. It’s still a work in progress, but it is at a pretty decent state thus far. This is not meant to be an official distribution per se, but thought I would share what I did with the group in case it’s helpful. It is based off of the awesome work that the universal blue team has done creating the Kinoite-main image. Huge thanks to Jorge for this project.
Add PCIE and USB power saving configurations to /etc/udev/rules.d/
Add wifi power saving configuration to /etc/sysctl.d/
Add wifi power saving configuration for intel wifi to /etc/udev/modprobe.d/
Add AMD s2idle and psr debugging scripts to /usr/share/ublue-os/scripts
Add udev rules to change AMD EPP Hints on AC Power / Battery
Add sysctl.d rules for vm.dirty_writeback_centisecs and kernel.nmi_watchdog parameters for power saving
Make scripts / kernel parameters available via just script
just fw13-amd to update default kernel parameters (cpufreq.default_governor=powersave, pcie_aspm.policy=powersupersave)
just check_sleep to run amd_s2idle.py debug script
just check_psr to run psr.py debug script
just epp_power to set AMD EPP Hints to Power Saving
just epp_balance_power to set AMD EPP Hints to Balance Power
just epp_balance_performance to set AMD EPP Hints to Balance Performance
just epp_performance to set AMD EPP Hints to Performance
Install powertop, kernel-tools, fprintd, fwupd, tailscale, 1password and other apps by default
Install AMDGPU_TOP by default
Make some commonly installed Flatpaks available to install on first boot, these are completely optional
After first install be sure to run just fw13-amd to set the kernel parameters. If you want the ideal power saving mode run just epp_power to set the power saving mode. If you want to switch back to balanced use just epp_balance_power. This is needed because power-profiles-daemon does not set these properly which significantly contributes to poor battery life on linux by default.
I didn’t run any of the other kernel params (disable scatter gather / iommu, etc) since I didn’t see a need for it myself yet.
Running this image on power saving mode, I can get ~3.5-4 watts at idle, ~6.3 watts during offline video playback. And ~5-8 watts web browsing. The main goals of the image were to create optimized defaults. A lot of the power saving tweaks are what tlp would have done, and are also taken from Archwiki.
The Github repo has the instructions to switch to this image. You can always switch back or to another, which is the beauty of ostree systems. Happy to accept any tweaks or best practices I have missed as I am still new to this. Obviously it’s also forkable / modifiable if you want to use it as a reference for your own image.
