Seems like upstream has thrown a monkey wrench into the mix lately on several fronts that interferes with their patches…
There is hope for kms + wayland… maybe. If you check the last post by mripard.
Edit: And I just noticed this concerning a kwin drm code update in version 5.23. The actual merge request mentions things like pageflip.
With the 5.12.17-2 kernel I get this dump on boot:
[ 0.255695] simple-framebuffer 3e2fe000.framebuffer: framebuffer at 0x3e2fe000, 0x7e9000 bytes, mapped to 0x(____ptrval____)
[ 0.255736] simple-framebuffer 3e2fe000.framebuffer: format=a8r8g8b8, mode=1920x1080x32, linelength=7680
[ 0.267918] Console: switching to colour frame buffer device 240x67
[ 0.278979] simple-framebuffer 3e2fe000.framebuffer: fb0: simplefb registered!
[ 0.279810] sysfs: cannot create duplicate filename '/devices/platform/3e2fe000.framebuffer'
[ 0.279912] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.12.17-2-MANJARO-ARM #1
[ 0.279999] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 0.280067] Call trace:
[ 0.280100] dump_backtrace+0x0/0x1ac
[ 0.280170] show_stack+0x24/0x30
[ 0.280223] dump_stack+0xec/0x154
[ 0.280275] sysfs_warn_dup+0x70/0x90
[ 0.280335] sysfs_create_dir_ns+0xec/0x104
[ 0.280394] kobject_add_internal+0x9c/0x2bc
[ 0.280455] kobject_add+0x94/0x100
[ 0.280504] device_add+0xe8/0x790
[ 0.280558] of_device_add+0x60/0x70
[ 0.280610] of_platform_device_create_pdata+0xc8/0x120
[ 0.280675] of_platform_device_create+0x24/0x30
[ 0.280733] simplefb_init+0x80/0xac
[ 0.280786] do_one_initcall+0x54/0x2c0
[ 0.280838] kernel_init_freeable+0x260/0x2e4
[ 0.280900] kernel_init+0x20/0x130
[ 0.280949] ret_from_fork+0x10/0x3c
[ 0.281002] kobject_add_internal failed for 3e2fe000.framebuffer with -EEXIST, don't try to register things with the same name in the same directory.
I have a functioning system, only noticed it by looking in dmesg.
kms + x11 + plasma
Looks like those might already be commited. They have done quite a few changes lately and I believe it has had some adverse effects in other places. I am starting to see video issues on the internet that keeps popping up lately. Just a few I found with a short search.
https://github.com/raspberrypi/linux/issues/4446
All very weird, I was going comment how well 5.10.50-2 is working for me, and I switch between kms, fkms and no VC4. The best behaving kernel in a while, for me.
Edit: But I do most of my work with no VC4 kernel module loaded, bypassing all of the kms/fkms drama. The VC4 is not very strong, the CPUs and llvmpipe with plasma on x11 and no compositor is my favorite setup… I don’t care much for desktop effects. I favor smooth and pain-free operation for daily use… I make my own pain often enough.
Does this look familiar. Opened a few days ago.
No, I have not experienced that particular crash. The RPi4 is really interesting, in how different they behave with slightly different setups.
See if increasing the video memory in config.txt helps.
#gpu_mem=whatever # comment out
dtoverlay=vc4-kms-v3d,cma-512
don’t work, even firefox updated, halt.
I think wayland is a different issue altogether.
I pushed new raspberrypi-bootloader packages to the unstable branch when the mirrors sync. I do not know if it will help with the kms freezing some are having or not.
I have spent a couple of days trying to trace back where people were having issues I have seen on the internet and it appears to me a common link is these series of kernel / raspberripi-bootloader patches when folks started having video issues:
https://github.com/raspberrypi/linux/pull/4441
raspberrypi-bootloader-20210719-1
raspberrypi-bootloader-x-20210719-1No help with kms, freeze after 42s of youtube with 5.12. cma-512 already enabled for kodi. Not tested with 5.10.
I want to turn back the clock back to before the RPi folks decided to make a ton of commits to convert their vc4 to upstream’s a while back. I would like people to test them that had issues here lately. This tarball has the linux-rpi4 5.10.46 kernel and also the 2 raspberrypi-bootloader packages that was current at that time.
Please let me know how it turns out…
md5sum:
f3c3d95fa06baa11869618175d6fddb2 kernel-test.tar
https://drive.google.com/file/d/1rcwD6sKN5E7MqWLH6fAOK2GQQGRPJuuL/view?usp=sharing
I took a look at Tumbleweed, since they are on upstream. Currently they using the 5.13.0 kernel and they enable vc4-kms-v3d-pi4, but they disable v3d and do not appear to compile the kernel module, so you end up running llvmpipe. They do not use fbturbo.
They have two simple yet effective overlays that I am working to incorporate, disable-vc4 and disable-v3d. If you copy the disable-v3d overlay to Manjaro, you can switch between hardware and software rendering by the use, or not, of the overlay.
Edit: And since vc4 is loaded in both instances, hdmi sound works asn well as the headphones. At least with 5.12.17-2.
As of yet with 5.13 and 5.14 RPi kernels I am unable to get both fkms and kms with V3D to completely boot and work; only one of them. And yesterday they bumped to 5.10.52 and with their upstream pull only kms with V3D rendering will now work. Those mega patches of them trying to convert their vc4 to what upstream has is starting to frustrate me. It appears they have a way to go with them.
I have booted upstream’s kernel 5.13 and 5.14 with no issues here testing them but upstream does not have V3D rendering.
I just re-tried 5.13.1-1, it did not work for me.
I thought v3d was mainlined in the 5.10 kernel?
Nope. It used to be in older upstream kernels just right before the pi4 first came out. At that time V3D would not even work on the pi4 though. All of a sudden a couple of years ago they just dropped v3d with a kernel change for some reason.
a little test, kms/firefox/youtube/sway/wayland work.
Thanks for testing.
I am trying vanilla 5.14-rc2 with your 5.12.17-2 config and this applied, to compile with CONFIG_DRM_V3D=m.
Edit: Well, that did not lead to a bootable kernel. I will try again, but with the suse kernel config.