With what setup can you boot and run without Panfrost gpu power-up errors? (I have the gpu power-up errors on three different images/kernels.)
Edit: JFL seems to have a lot of setup combinations that give these errors too. It would be nice to try to narrow down what causes them.
No sound on mainline linux kernel 5.9.9-2 or 5.9.6-1. I even tried using odroid-alsa-1-3-aarch64.pkg.tar.zst from archlinuxdroid repo but unsuccessful on getting sound on mainline linux kernel.
Just an update with the governor=‘schedutil’, no screen flashes/glitches for the past 1hr 35mins.
From my testing of Panfrost with mesa-git, mesa-arm-git and mesa-panfrost-git, Panfrost runs on GT King Pro with linux-kernel 5.9.9-2 quite well, but I feel that it lag a bit but not bad (when you run glmark2-es2 the CPU usage is very low compared to without Panfrost eventhough without Panfrost the score is better). Take note NO Sound on mainline linux kernel as far as I know hopefully someone can find a solution. No sound on video is no fun!
But In Firefox 83 if you turn-on/enable Webrender or layers.acceleration.force.enabled option (using about:config) and play YouTube Video on it, it freeze and dmesg will give Panfrost gpu error.
But according to Spikerguy and TheMojoMan Panfrost is not stable on linux-vim kernels currently.
Yes I can boot and run without problems. Errors were found when video decoding (2D acceleration) and continued until reboot.
.
I managed to get driver up with linux-vim 5.9.0 and mesa-git 20.3 with panfrost powering errors. When upgrading panfrost errors disappeared. From there have random freezes. I will update to latest stable and try cpupower if freezes remain,
Hi Spikerguy,
Does Plasma Wayland works with “dkms-mali-bifrost” drivers from Archlinux: Wayland GPU Acceleration Guide - ODROID?
Earlier post by Spikerguy, did warned that linux kernel 5.9.0-1 do have memory leak and can cause issue on Panfrost. Check the Panfrost for Bifrost GPUs - Big improvements started by TheMojoMan.
Can safely say with governor=‘schedutil’ in Manjaro-ARM, there is NO Screen Flashes/Glitches (2hr 30min no screen glitches at all).
Just found some info on governor=‘schedutil’, from lwn.net " Improvements in CPU frequency management"
"The other important change is to introduce a new CPU frequency-scaling governor, schedutil, that makes decisions based on utilization as measured by the scheduler. The cpufreq_update_util() call that the scheduler makes whenever it updates the load average already carries information about the calculated load on the current CPU, but no governor uses that information. schedutil changes that. It doesn’t change much though.
schedutil still only performs updates at the same rate as the current code, so it doesn’t try to address the interactive responsiveness problem, and doesn’t try to be clever about realtime or deadline threads. All it does is use the load calculated by the scheduler instead of the average load over the last little while, and optionally imposes that frequency change instantly (directly from the scheduler callback) if the driver supports it.
This is far from a complete solution for power-aware scheduling, but looks like an excellent base on which to make cpufreq more responsive to sudden changes in load, and more aware of some of the finer details that the scheduler can, in theory, provide."
We have been using schedutil on all other kernels since long time. Maybe we can use the same for linux-vim
Thanks for testing
No idea never tried. These are mali blobs which we don’t really use.
I just check “/etc/default/cpupower” with the Manjaro-ARM-VIM3 KDE Plasma 20.11 kernel 5.9.0-2 there is not option to set governor=‘schedutil’… Wanted to try whether with governor=‘schedutil’ on this Manjaro-ARM-VIM3 KDE Plasma 20.11 kernel 5.9.0-2 solve the screen flahes/glitches issue.
With your current linux-vim kernel 5.9.0-2 is the “schedutil” option available? From “/etc/default/cpupower” the option of “schedutil” is NOT listed as an option.
Thanks a lot for your explanation, reading it and about panfrost, gave me the opportunity to better understand how manjaro structure works, the state of hardware acceleration (panfrost) and video hardware acceleration.
It is just the (comments in) the package cpupower that is outdated. It works if you set governor=‘schedutil’ in /etc/default/cpupower (I’m running it this way now.) It would be very nice if one and the same governor setting would work across all Manjaro kernels…
Edit: Unfortunately, the graphics glitches came back with governor=schedutil (not so frequent though, it appears). (No freezes so far, which is about one hour.) I will stick (on my Ugoos) with governor=performance for now.
Edit:
Try setting it anyway and see what it does. The cpupower sevice may be dated and does not know about SCHEDUTIL.
As a side note if any one reading this has a pi4 I set the SCHEDUTIL as default in the pi kernels; except the 5.5 kernel as it has not been maximized until a later kernel. So no need for cpupower.
You can set it, as we already have it in linux-vim
A small update on the choice of cpu frequency scaling governor.
It is possible to set cpu min and max frequencies for governor=schedutil. The defaults seem to be the min and max supported by hardware (as specified by the dtb, not the actual hardware limits). If one uses the cpupower package then the min/max frequencies used by the governor can be set conveniently in /etc/default/cpupower. For my Ugoos box I could eliminate the glitches and have stable operation if I use somewhat higher min frequencies than the minimal supported by hardware (100MHz). So, now I have instead explicitly defined
min_freq="1000MHz"
max_freq="1.99GHz"
in /etc/default/cpupower and this seems to work just fine (no glitches, no freezes). (With min_freq="667MHz" I get glitches. The frequencies available for setting can be seen by doing cpupower frequency-info.)
Good tinkering to resolve your Manjaro Screen glitches and understanding what causes the Manjaro screen glitches, eventhough in another distro “ondemand” or even at lower minimum frequency at 499Mhz like in Armbian does not cause screen glitches.
Just received notification that Arm-Stable Update 2020-11-24 is available. This update causes me having to re-burn KDE-Plasma image twice as during the update kernel panic occurred. I wanted to see whether linux-vim 5.9.0-2 is stable enough on GT King Pro to perform a system updates with download size of 481MB (actual after installation is much larger in Giga bytes). The first time just apply all 481MB upgrade at one go causes kernel panic in the middle of the upgrade. Re-burn image.
Second try, selected linux-vim 5.9.8-1 and linux-firmware upgrade first. Successful. Did not reboot and continue to select all the rest of system update (except Firefox upgrade). Kernel panic in the middle of upgrade. This round able to boot up to greeter screen but with warning gtk-greeter not available. Login to black screen eventhough selected session as Plasma (not Plasma Wayland). Re-burn image again.
During the third try, again I split the updates/upgrades to three trenches.
Seems like (only a perception) GT King Pro on linux 5.9.9-2 is more stable than running on linux-vim 5.9.8-1 (hard to tell as kernel panic is known to occur GT King Pro on mainline kernel until Beelink comes out with a solution).
It is hardwork to keep GT King Pro running up to date on mainline kernel.
With cpupower installed, proceed to test whether governor=‘schedutil’ resolved the screen glitches in KDE Plasma with linux-vim 5.9.8-1.
In KDE Plasma linux-vim 5.9.8-1 with cpupower setting governor=‘schedutil’ does NOT resolve screen glitches in Manjaro KDE Plasma. Either cpupower does not have a setting for governor=‘schedutil’ or governor=‘shedutil’ works only if preset in kernel like in linux 5.9.9-2 kernel.
With sudo cpupower frequency-set -g performance, screen glitches stopped.
linux-vim 5.9.8-1 KDE Plasma 5.20.3. Set governor=‘schedutil’
[jfl@MNJROGTKPro ~]$ cpupower frequency-info
analyzing CPU 0:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1
CPUs which need to have their frequency coordinated by software: 0 1
maximum transition latency: 50.0 us
hardware limits: 100.0 MHz - 1.99 GHz
available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz
available cpufreq governors: conservative ondemand userspace powersave per
current policy: frequency should be within 100.0 MHz and 1.99 GHz.
The governor “schedutil” may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 100.0 MHz (asserted by call to kernel)
linux-vim 5.9.8-1 KDE Plasma 5.20.3. Set governor=‘performance’
[jfl@MNJROGTKPro ~]$ cpupower frequency-info
analyzing CPU 0:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1
CPUs which need to have their frequency coordinated by software: 0 1
maximum transition latency: 50.0 us
hardware limits: 100.0 MHz - 1.99 GHz
available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 667 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.90 GHz, 1.99 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 100.0 MHz and 1.99 GHz.
The governor “performance” may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.99 GHz (asserted by call to kernel)
Yes, I also had problems when the lower frequency was 100MHz. On my (Ugoos) box I could fix this by keeping governor=schedutil but by defining (explicitly) the min and max frequencies in /etc/default/cpupower (well, I had to raise the min freq. all the way up to 1GHz, but still).
I thought you had done something similar, no?
I am now on Manjaro-ARM-VIM3-Xfce-linux 5.9.9-2 (not linux-vim). The governor is preset in kernel as ‘schedutil’. No Screen glitches so far.
[jfl@GTKPro ~]$ cpu-temp-speed the output varies between 100Mhz/45C to 250Mhz, 500Mhz, 667Mhz.1000Mhz. No screen glitches.
Are you current running on Xfce or the new KDE Plasma image by Spikerguy? What kernel are on? If you are running Xfce minimum freq of >667Mhz to have No screen glitches then cpu freq alone is not the only cause for screen glitches if the above cpu-temp-speed output is to be trusted.