The Radxas version seems to be an older version than the Jeff’s Repo ones, and I’m have some problems with Jeff’s in early days of testing so I used Radxas one.
Ubuntu 20.02 & Mali Drivers
I don’t know to be honest as a bit confused by it all as not really my thing.
I am not sure where the source is for either or how they come into existence 
Using Jammy server from armbian with JeffyCn’s csffw and icecreams ppa with a sudo apt install ubuntu-desktop.
The background glitch is weird as it only seems to happen on the background and no where else, haven’t used it much but everything else seems to work and new windows don’t have similar glitches.
So I have always just ignored it.
It was purely curiosity to the performance as the mali seems to be only put under approx 40% load by what I presume is the gles driver whilst playing with ml and using openCl that can avg around 75% load on the mali.
I just thought Wayland might be more performant
OpenGL ES GPU pipelining
OpenGL ES exposes a synchronous rendering model to the application developer, despite
the underlying execution being asynchronous, whereas Vulkan exposes this
asynchronous nature directly to the application developer to manage. In either case it is
important that the application keeps the GPU fed with work, avoiding behaviors which
drain the pipeline and starve the GPU of work (unless the desired target frame rate has
been reached, of course).
Keeping the GPU busy not only means that you will get the best rendering performance
from the platform, but also that you avoid hitting performance oscillations caused by the
platform dynamic voltage and frequency scaling (DVFS) logic thinking that the CPU or
GPU is under-utilized.
Do
▪ Do not let the GPU go idle unless the target performance is reached.
▪ Pipeline any use of fences and query objects; don't wait on them too early.
▪ Use GL_MAP_UNSYNCHRONIZED to allow use of glMapBufferRange() to patch a safe
region of a buffer which is still partially referenced by in-flight draw calls.
▪ Pipeline any glReadPixels() calls to read asynchronously into a pixel buffer object.
Don't
▪ Use operations which enforce the synchronous behavior of OpenGL ES:
▪ glFinish()
▪ Synchronous glReadPixels()
▪ glMapBufferRange() without GL_MAP_UNSYNCHRONIZED on buffer still referenced
by a draw call
▪ Use glMapBufferRange() with
either GL_MAP_INVALIDATE_RANGE or GL_MAP_INVALIDATE_BUFFER; due to a
historical specification ambiguity these flags will currently trigger the creation of a
resource ghost.
▪ Use glFlush() because this may force render passes to be split; the driver will flush as
needed.
Impact
▪ Pipeline draining will, at a minimum, result in a loss of performance as the GPU will
be partially idle for the duration of the bubble.
▪ Possible performance instability, depending on the interaction with the platform's
DVFS power management logic.
Debugging
▪ System profilers such as DS-5 Streamline can show both CPU and GPU activity.
Pipeline drains of this nature are normally clearly visible as periods of busy time
oscillating between the CPU and GPU, with neither being fully utilized.
As I thought X11 was forcing all those don’t of synchronous operation as from what @icecream95 said that seems to be the problem with no parallelism with gpu/cpu as one is waiting for the other?
I was purely trying to get a best rough bench so will have to leave it to you 2. Apols
In the DTB it seems to be declared as bifrost which don’t have a CSF so yeah I am totally confused at state of play
gpu@fb000000 {
compatible = "arm,mali-bifrost";
reg = <0x00 0xfb000000 0x00 0x200000>;
interrupts = <0x00 0x5e 0x04 0x00 0x5d 0x04 0x00 0x5c 0x04>;
interrupt-names = "GPU\0MMU\0JOB";
clocks = <0x0e 0x05 0x02 0x115 0x02 0x116 0x02 0x114>;
clock-names = "clk_mali\0clk_gpu_coregroup\0clk_gpu_stacks\0clk_gpu";
assigned-clocks = <0x0e 0x05>;
assigned-clock-rates = <0xbebc200>;
power-domains = <0x4e 0x0c>;
operating-points-v2 = <0x4f>;
#cooling-cells = <0x02>;
dynamic-power-coefficient = <0xba6>;
upthreshold = <0x1e>;
downdifferential = <0x0a>;
status = "okay";
mali-supply = <0x50>;
mem-supply = <0x50>;
phandle = <0x4d>;
};
I’ve been trying to debug that issue for a couple of days, but still don’t know how to fix it…
I don’t want to implement whatever hacks the blob is doing for Wayland, so improving the average GPU load will require some kernel changes. It’s still a while to get to that point, though.
The BSP kernel has three copies of Arm’s Mali kernel driver—one for Utgard (mali400), one for Midgard, and one for Bifrost (which also supports Valhall). Changes to the kernel driver for Valhall support went to the Bifrost source tree, so the GPU is marked compatible with the Bifrost kernel driver.
The Bifrost kernel and Valhall kernel downloads from Arm are identical.
From the kernel’s perspective, (pre-CSF, “Job Manager”) Valhall is more
or less compatible with Bifrost
Was it the 1st/2nd gen Valhall that didn’t have a CSF and that is what is completely missing and this has been a complete confusion to me as its a pretty big change but still keeps the same Architecture name that I guess should be identified as mali-csf ?
There seems less of a change between bifrost & the 1st/2nd gen Valhall that did get a name change then 3rd gen Valhall comes with a substantially different CSF that really is not incremental as other Valhall additions to bifrost have been but does keep a same architecture name ?!?
So yeah I am totally confused and yeah the Bifrost kernel and Valhall kernel prob are identical and why the MaliG610 with no CSF coordination is only achieving 40% load.
Also we are on this BSP kernel of 5.10 that is totally out of wack with Mesa so guess also you are having to heavily backport.
The man in the middle of the CSF between cpu irq and gpu and a queue that isn’t waiting for completion should have a kernel implementation I presume but currently is being hacked into the userspace?
I am going to have to leave it to you @icecream95 but I am not really sure about soloing this as surely the herd of Mesa and alyssa are needed to pool resources?
@stuartiannaylor @icecream95
Just curious, does HW video decoding work in any browser (e.g. FF or Chromium) with that Armbian+Mali driver combo under Wayland? I’m interested to give it a try soon.
The only one that would work probably is the custom chromium provided by rockchip. The one shipped with radxa debian does not support wayland but rockchip said that the wayland patch does exist and some customers are using that, probably Khadas is ?
I am not sure as was purely interested if the Wayland implementation helps with the current problems of balancing the cpu / gpu irq calls in the new command stream as would seem currently the Mali G610 is very underloaded as the parallelism doesn’t seem to exist at all so one is always waiting for the other and process seems serial.
Its @icecream95 who knows a huge amount as is prolific contributor and did much with OpenCL so is in a totally different league to me.
Put simplistically to what my limited brain can handle is the current drivers are a bit like the early Mali-FB-Dev drivers we had that did specific jobs but likely have loads of gotchas as it may not be plumbed into ’ VA-API’ which is how you get Chromium acceleration which I didn’t try. Its video accel really when browsing than 3d.
Because the Mali G610 is such a strong GPU currently for many the results are quite good, but really when looking at load we have a pretty terrible implementation.
I am sort of confused as the CSF & the third gen Valhall would seem a more significant change to its 1st&2nd gen Valhall are to the previous Bifrost they got a name change from.
cat /sys/devices/platform/fb000000.gpu/utilisation so to be honest until we get an optimised driver under the hood I haven’t even bothered testing Chromium.
The Mali is just a 3D Gpu and with video we also have hardware encoders to plumb in and again I am confused there as I thought a lot of work had been done on the state management of video encoder/decoder and the Hantro RKDec shared a lot of similarities but apparently not.
I think there might be considerable work needed on the Mali G610 driver and it could take some time but when using it with OpenCl load gets to 70% which might be near max due to the ArmNN & OpenCl layers using it in the above Wav2Letter example, but even that might even get more optimised.
I am not worthy or any where near the level of Icecream95 and was just curious to state of play and got loads of really great feedback. I am hoping some of the dmesg errors of the NPU get fixed so I can play with the NPU as not expecting anything imminent GPU wise.
I am also thinking this might be the fastest mainline adoption we will see due to the adoption of a large number of rk3588/rk3588s vendors and variations out there as really I would prefer to ditch the Rockchip BSP.
The architecture name changes when the machine code representation used by the shader cores change:
Utgard had separate vertex and fragment shading cores, Midgard was VLIW with three vector units and two scalar units, Bifrost was VLIW with two scalar units, and Valhall uses a simple stream of eight-byte instructions.
So even if the entire rest of the GPU changes, only the shader cores matter for architecture naming.
But even looking at GPU structures, the Valhall GPUs are all very similar to each other, apart from CSF. Bifrost is much closer to Midgard than it is to Valhall in that regard, but the entire fragment processing pipeline from rasterization to blending is almost unchanged for the different Valhall generations.
You know more than me but from past history and reading pretty sure Alyssa has mentioned Utgard->Midgard->Valhall was fairly incremental and that is it the CSF and implementation from what my lowly knowledge might be, seems to think that is less incremental and more of an architecture change than just additions.
Thats why we do have a working driver but still impeded due to no previous csf implmementation.
All CSF does is replace the old Job Manager frontend with the Command Stream Frontend, so rather than having job description structures statically allocated, they are built up by a command stream that is Turing complete. An MCU is added to make this work better.
So previously there was (very simplified, and not how the driver actually does things, and the pointers should be GPU pointers):
struct job {
struct job *next;
};
struct vertex_job {
struct job header;
uint32_t num_vertices;
};
struct vertex_job my_vertex_jobs[] = {
{
.header.next = &my_vertex_jobs[1].header,
.num_vertices = 3,
},
{
.num_vertices = 10,
},
};
and now we have (again, simplified and not how things actually work):
uint64_t commands[] = {
CMD_MOV_32(NUM_VERTICES, 3),
CMD_VERTEX_JOB,
CMD_MOV_32(NUM_VERTICES, 10),
CMD_VERTEX_JOB,
};
That is a big change, yes, and one that affects the driver a lot, but most of the rest of the GPU is unchanged, and I suspect that the old vertex_job struct still exists behind the scenes.
Even from the driver side, I have made CSF mostly look like the old way of doing things, so the same code can often be used for both non-CSF and CSF GPUs.
Apart from one bug that can affect programs drawing a lot of vertices (so far I’ve only hit this in one Xscreensaver demo), most of the current driver shortcomings can be blamed on kbase rather than CSF.
Yeah I don’t know how they will choose to implement it in the kernel and dunno maybe Allsya and Mesa have plans with the next gen Mali’s being the same and already out.
I presume the MCU can act like a very low latency asynchronous co-ordinator and queue and when employed we should see gpu loading of much more than the current 40%.
I presume the emulator and ‘gamers’ would be better on Android for a while as its already implemented but not opensource?
I actually ran Glmark2 on android and it gave a similar result but have no idea if the code base has any simularity as a bench.
1 Like
Thank you very much for your work and detailed explanations about the mali driver.
I have been testing mali driver 23.0~panfork~csf this week and have also encountered crashes. I run lightdm and kodi in h264 video mode, the system spontaneously reboots stably at the video transition and after watching the video for more than 30 minutes.
journalctl:
Nov 20 11:17:22 rock-5b pulseaudio[2161]: module-x11-xsmp may not be loaded twice. Nov 20 11:17:22 rock-5b pulseaudio[2161]: Failed to load module "module-x11-xsmp" (argument: "display=:0.0 xauthority=/home/konstantin/.Xauthority session_manager=local/rock-5b:@/tm> Nov 20 11:17:22 rock-5b NetworkManager[1755]: <info> [1668925042.4153] agent-manager: agent[775a0eb26c9baa47,:1.68/org.freedesktop.nm-applet/1000]: agent registered Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor' unit='gvfs-udisks2-volume-monitor.serv> Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - disk device monitor... Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.UDisks2VolumeMonitor' Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - disk device monitor. Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.MTPVolumeMonitor' unit='gvfs-mtp-volume-monitor.service' req> Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - Media Transfer Protocol monitor... Nov 20 11:17:22 rock-5b CRON[1680]: pam_unix(cron:session): session closed for user root Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.MTPVolumeMonitor' Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - Media Transfer Protocol monitor. Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.GPhoto2VolumeMonitor' unit='gvfs-gphoto2-volume-monitor.serv> Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - digital camera monitor... Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.GPhoto2VolumeMonitor' Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - digital camera monitor. Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.AfcVolumeMonitor' unit='gvfs-afc-volume-monitor.service' req> Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - Apple File Conduit monitor... Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.AfcVolumeMonitor' Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - Apple File Conduit monitor. Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.GoaVolumeMonitor' unit='gvfs-goa-volume-monitor.service' req> Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - GNOME Online Accounts monitor... Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.GoaVolumeMonitor' Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - GNOME Online Accounts monitor. Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.freedesktop.thumbnails.Thumbnailer1' Nov 20 11:17:22 rock-5b systemd[2151]: Started Thumbnailing service. Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.bluez.obex' unit='dbus-org.bluez.obex.service' requested by ':1.31' > Nov 20 11:17:22 rock-5b systemd[2151]: Starting Bluetooth OBEX service... Nov 20 11:17:22 rock-5b obexd[3022]: OBEX daemon 5.65 Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.bluez.obex' Nov 20 11:17:22 rock-5b systemd[2151]: Started Bluetooth OBEX service. Nov 20 11:17:23 rock-5b pulseaudio[2161]: ALSA woke us up to write new data to the device, but there was actually nothing to write. Nov 20 11:17:23 rock-5b pulseaudio[2161]: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers. Nov 20 11:17:23 rock-5b pulseaudio[2161]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Nov 20 11:17:24 rock-5b kernel: Bluetooth: RFCOMM TTY layer initialized Nov 20 11:17:24 rock-5b kernel: Bluetooth: RFCOMM socket layer initialized Nov 20 11:17:24 rock-5b kernel: Bluetooth: RFCOMM ver 1.11 Nov 20 11:17:26 rock-5b pkexec[3088]: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=1000) Nov 20 11:17:26 rock-5b pkexec[3088]: konstantin: Executing command [USER=root] [TTY=unknown] [CWD=/home/konstantin] [COMMAND=/usr/lib/update-notifier/package-system-locked] Nov 20 11:17:26 rock-5b chronyd[1839]: Selected source 213.141.154.170 (1.ubuntu.pool.ntp.org) Nov 20 11:17:26 rock-5b chronyd[1839]: System clock wrong by 26557.828622 seconds
The mali update has just arrived, I will continue to test further:
root@rock-5b:~# dpkg -l| grep -e panfork -e mesa ii libegl-mesa0:arm64 23.0~panfork~csf~git221118.18db031~k arm64 free implementation of the EGL API -- Mesa vendor library ii libgbm1:arm64 23.0~panfork~csf~git221118.18db031~k arm64 generic buffer management API -- runtime ii libgl1-mesa-dri:arm64 23.0~panfork~csf~git221118.18db031~k arm64 free implementation of the OpenGL API -- DRI modules ii libglapi-mesa:arm64 23.0~panfork~csf~git221118.18db031~k arm64 free implementation of the GL API -- shared library ii libglu1-mesa:arm64 9.0.2-1 arm64 Mesa OpenGL utility library (GLU) ii libglx-mesa0:arm64 23.0~panfork~csf~git221118.18db031~k arm64 free implementation of the OpenGL API -- GLX vendor library ii mesa-utils 8.5.0-1 arm64 Miscellaneous Mesa utilities -- symlinks ii mesa-utils-bin:arm64 8.5.0-1 arm64 Miscellaneous Mesa utilities -- native applications
Tell me if there is anything I can do to help you get a good driver for mali G610 faster
1 Like
What do you mean “reboots stably”? Does it start booting again without going through the normal shutdown process?
That can be an indicator of unstable RAM. Updating the bootloader supposedly fixes that, or you can try lowering the maximum frequency as a workaround:
echo 1560000000 | sudo tee /sys/class/devfreq/dmc/max_freq
After the latest mali panfork update and possibly replacing the power supply with 20V ~ 3.25A, for the first time I managed to watch the 2 hour cartoon until the end without freezing and rebooting, thank you very much for your work.
So I already have a second rock 5b board that I’m testing as a working desktop
It’s strange that yesterday I worked for more than 8 hours with two monitors connected via HDMI and several FireFox windows and many tabs. And it seemed quite stable to me.
But today I installed nvme disk
root@rock-5b:~# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 19M 1.6G 2% /run
/dev/mmcblk1p1 14G 9.6G 3.7G 73% /
tmpfs 7.7G 193M 7.5G 3% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.7G 396K 7.7G 1% /tmp
/dev/nvme0n1p1 458G 222M 434G 1% /home
/dev/zram1 47M 12M 32M 27% /var/log
tmpfs 1.6G 128K 1.6G 1% /run/user/1000
root@rock-5b:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mtdblock0 31:0 0 16M 0 disk
mmcblk1 179:0 0 14.5G 0 disk
└─mmcblk1p1 179:1 0 14.3G 0 part /var/log.hdd
/
mmcblk1boot0 179:32 0 4M 1 disk
mmcblk1boot1 179:64 0 4M 1 disk
zram0 254:0 0 7.7G 0 disk [SWAP]
zram1 254:1 0 50M 0 disk /var/log
nvme0n1 259:0 0 465.8G 0 disk
└─nvme0n1p1 259:1 0 465.8G 0 part /home
And today, twice in a row, when trying to open the FireFox browser, the board spontaneously rebooted. After that, I cleared the browser cache and moved it from nvme to /dev/shm. The browser opened, and I continue to work carefully.
Also noticed the messages in the log:
[ 3948.203781] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.219861] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.242599] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.253120] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.268994] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.285729] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3949.540597] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3949.553298] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3949.569564] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 4920.207976] ------------[ cut here ]------------
[ 4920.208007] WARNING: CPU: 1 PID: 12677 at drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2907 vop2_crtc_load_lut+0x50/0x2d8
[ 4920.208011] Modules linked in: bnep xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter
bridge stp llc overlay binfmt_misc zstd fuse ip_tables x_tables ipv6 panfrost gpu_sched pgdrv r8125
[ 4920.208099] CPU: 1 PID: 12677 Comm: kworker/u16:1 Tainted: G W 5.10.72-rockchip-rk3588 #trunk.0102
[ 4920.208102] Hardware name: Radxa ROCK 5B (DT)
[ 4920.208114] Workqueue: events_unbound commit_work
[ 4920.208121] pstate: 40c00009 (nZcv daif +PAN +UAO -TCO BTYPE=--)
[ 4920.208126] pc : vop2_crtc_load_lut+0x50/0x2d8
[ 4920.208131] lr : vop2_crtc_load_lut+0x48/0x2d8
[ 4920.208134] sp : ffffffc01ab13be0
[ 4920.208137] x29: ffffffc01ab13be0 x28: ffffff814ed5fc00
[ 4920.208144] x27: ffffffc0110b9d98 x26: ffffff8150301e80
[ 4920.208151] x25: ffffff816e6cc058 x24: ffffff81052e2080
[ 4920.208158] x23: 0000000000000400 x22: ffffffc0114fd9f8
[ 4920.208164] x21: ffffff81052e0080 x20: ffffff81052e0080
[ 4920.208171] x19: ffffff81052e00f8 x18: 0000000000000000
[ 4920.208179] x17: 0000000000000000 x16: 0000000000000000
[ 4920.208185] x15: 0000000000000010 x14: 0000000034325258
[ 4920.208192] x13: ffffffc01ab13b98 x12: ffffffffffffffff
[ 4920.208199] x11: 0000000000000040 x10: 00000000fffffffe
[ 4920.208205] x9 : ffffffc0107d4b94 x8 : 0000000000000000
[ 4920.208212] x7 : ffffff81011c6080 x6 : 00000000000003ff
[ 4920.208219] x5 : 0000000000000400 x4 : 00000000000003ff
[ 4920.208226] x3 : 000000003fffffff x2 : 00000000000003ff
[ 4920.208232] x1 : ffffffc012c1d000 x0 : 0000000000000000
[ 4920.208241] Call trace:
[ 4920.208247] vop2_crtc_load_lut+0x50/0x2d8
[ 4920.208253] vop2_crtc_atomic_flush+0x948/0xc18
[ 4920.208257] drm_atomic_helper_commit_planes+0x1c0/0x1c8
[ 4920.208264] rockchip_drm_atomic_helper_commit_tail_rpm+0xa4/0x144
[ 4920.208269] commit_tail+0x80/0x108
[ 4920.208272] commit_work+0x1c/0x28
[ 4920.208281] process_one_work+0x1d8/0x290
[ 4920.208286] worker_thread+0x1e0/0x270
[ 4920.208291] kthread+0xf4/0x104
[ 4920.208300] ret_from_fork+0x10/0x30
[ 4920.208305]
PC: 0xffffffc0107d4a9c:
[ 4920.215575] ---[ end trace 2a6242fa207cbbb1 ]---
[ 6400.984118] ------------[ cut here ]------------
[ 6400.984141] WARNING: CPU: 7 PID: 13326 at drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2907 vop2_crtc_load_lut+0x50/0x2d8
[ 6400.984145] Modules linked in: bnep xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter
bridge stp llc overlay binfmt_misc zstd fuse ip_tables x_tables ipv6 panfrost gpu_sched pgdrv r8125
[ 6400.984236] CPU: 7 PID: 13326 Comm: kworker/u16:0 Tainted: G W 5.10.72-rockchip-rk3588 #trunk.0102
[ 6400.984240] Hardware name: Radxa ROCK 5B (DT)
[ 6400.984249] Workqueue: events_unbound commit_work
[ 6400.984259] pstate: 40c00009 (nZcv daif +PAN +UAO -TCO BTYPE=--)
[ 6400.984267] pc : vop2_crtc_load_lut+0x50/0x2d8
[ 6400.984274] lr : vop2_crtc_load_lut+0x48/0x2d8
[ 6400.984278] sp : ffffffc01ada3be0
[ 6400.984282] x29: ffffffc01ada3be0 x28: ffffff814f471000
[ 6400.984291] x27: ffffffc0110b9d98 x26: ffffff814ef37a80
[ 6400.984300] x25: ffffff816e524058 x24: ffffff81052e2080
[ 6400.984308] x23: 0000000000000400 x22: ffffffc0114fd9f8
[ 6400.984317] x21: ffffff81052e0080 x20: ffffff81052e0080
[ 6400.984325] x19: ffffff81052e00f8 x18: 0000000000000000
[ 6400.984335] x17: 0000000000000000 x16: 0000000000000000
[ 6400.984343] x15: 0000000000000010 x14: 0000000034325258
[ 6400.984352] x13: ffffffc01ada3b98 x12: ffffffffffffffff
[ 6400.984360] x11: 0000000000000040 x10: 00000000fffffffe
[ 6400.984369] x9 : ffffffc0107d4b94 x8 : 0000000000000000
[ 6400.984377] x7 : ffffff81011c6080 x6 : 00000000000003ff
[ 6400.984386] x5 : 0000000000000400 x4 : 00000000000003ff
[ 6400.984394] x3 : 000000003fffffff x2 : 00000000000003ff
[ 6400.984402] x1 : ffffffc012c1d000 x0 : 0000000000000000
[ 6400.984411] Call trace:
[ 6400.984419] vop2_crtc_load_lut+0x50/0x2d8
[ 6400.984427] vop2_crtc_atomic_flush+0x948/0xc18
[ 6400.984433] drm_atomic_helper_commit_planes+0x1c0/0x1c8
[ 6400.984442] rockchip_drm_atomic_helper_commit_tail_rpm+0xa4/0x144
[ 6400.984448] commit_tail+0x80/0x108
[ 6400.984453] commit_work+0x1c/0x28
[ 6400.984462] process_one_work+0x1d8/0x290
[ 6400.984470] worker_thread+0x1e0/0x270
[ 6400.984477] kthread+0xf4/0x104
[ 6400.984483] ret_from_fork+0x10/0x30
[ 6400.984488]
PC: 0xffffffc0107d4a9c:
root@rock-5b:~# dmesg | grep -c 'Unsupported format modifier'
1989
dmesg.0 logs after self reboot:
[ 23.236146] kernel: dwhdmi-rockchip fde80000.hdmi: use tmds mode
[ 23.249592] kernel: dwhdmi-rockchip fde80000.hdmi: use tmds mode
[ 23.265794] kernel: dwhdmi-rockchip fde80000.hdmi: use tmds mode
[ 23.323465] kernel: enP4p65s0: 0xffffffc015e60000, 00:e0:4c:68:00:a7, IRQ 152
[ 24.786472] kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[ 24.789336] kernel: Bridge firewalling registered
[ 25.080300] kernel: mali fb000000.gpu: Loading Mali firmware 0x1010000
[ 25.080842] kernel: mali fb000000.gpu: Protected memory allocator not found, Firmware protected mode entry will not be supported
[ 26.166229] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166270] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166286] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166301] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166318] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166639] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166664] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166677] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166691] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166704] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.166996] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167051] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167098] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167143] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167191] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167499] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167563] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167659] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167728] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[ 26.167786] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
root@rock-5b:~# grep -c 'dwhdmi-rockchip fde80000.hdmi: use tmds mode' /var/log/dmesg.0
811
I followed the instructions, ran dist-upgrade, rebooted… blank screen appear after reboot “something get wrong”, probably due to original driver libraries automatic removal
mmm after reboot still blank screen with message “oh no something went wrong”
how can I fix? last apt command, after dist-upgrade, was autoremove with removal of libllvm13; I try to reinstall and reboot, same result
I think that combination of dist-upgrade and autoremove messed something up at the boot level: the system boot, all works except desktop environment
any news about mali drivers in ubuntu env? if you follow the istruction above, whe reboot you take a blank screen with text like “oh noo something goes wrong”
Icecream95 are u still alive? What happened with you? Have u gone to jail or something?
My bet is he just doesnt gaf after how he has been treated and i dont blame him.
1 Like
Yeah… but its strange him, thomas kaiser, nicod, monka, q4s, amazingfate and a few others were very active in this group then… all went probably to pi5 or… x86 pcs…
Very strange that the hype on rk3588 died shortly.