Maybe mesa fixed a bug and added pi5 support.
but with mesa-23.3-git lost vulkan device.
Using video driver wayland
Vulkan device: V3D 4.2.14
Vulkan device type: integrated gpu
Vulkan version: 1.2.267 (api) 23.99.99 (driver)
Max. texture size: 4096
Max. uniform buffer range: 1073741824
Min. uniform buffer offset alignment: 32
Resolution: 1280 x 720
v3dv_drm_handle_device: drmGetMagic failedKernel 6.1.58-2 just doesn’t boot on my Raspberry Pi 4.
Complains about some bluetooth HW issue, then spits errors that a CPU is stuck. Plus SD access LED stays steady lit, then nothing.
Too early in the boot process to take screenshot or copy / paste, but well, it doesn’t boot.
Reverting to 6.1.54-1 brings my pi 4 back to life.
What branch are you on?
Stable is on 6.1.54-1 according to https://gitlab.manjaro.org/-/snippets/930/raw
And on my unstable I just updated to linux-rpi4-6.1.58-5 and it rebooted just fine. (I am running headless though, if you have some desktop that is creating trouble for you)
I’m on testing…
[ARM Testing Update] 2023-10-21 - Kernels, PipeWire, KDE Gear & Frameworks, Thunderbird is probably a better thread, or even start a new maybe.
But no matter what you decide, provide more info (logs etc) than “I can not boot”, we have no wizards on this forum that magically can gather the information needed… 
Using what little info you gave we used to have to load the bluetooth firmware manually with attach-bluetooth.service at boot. Over a year ago the RPi kernel started loading the firmware. Disabling attach-bluetooth.service should have been done at that time. If you have attach-bluetooth.service running you need to disable it and also comment out dtparam=krnbt=on in /boot/config.txt if it exists as it is not needed any more.
Trying to load firmware manually might be causing an issue with this newer kernel.
Thank you, I will try this (tomorrow).
I looked at the latest README in /boot/config.txt and it does read differently now.
Name: cma
Info: Set custom CMA sizes, only use if you know what you are doing, might
> clash with other overlays like vc4-fkms-v3d and vc4-kms-v3d.
Load: dtoverlay=cma,=
Params: cma-512 CMA is 512MB (needs 1GB)
cma-448 CMA is 448MB (needs 1GB)
cma-384 CMA is 384MB (needs 1GB)
cma-320 CMA is 320MB (needs 1GB)
cma-256 CMA is 256MB (needs 1GB)
cma-192 CMA is 192MB (needs 1GB)
cma-128 CMA is 128MB
cma-96 CMA is 96MB
cma-64 CMA is 64MB
cma-size CMA size in bytes, 4MB aligned
cma-default Use upstream’s default value
I remember in one of your post’s above seeing the error Failed to allocate cma and this got me thinking that within the last month I was having issues playing hevc 3840x2160 59.940fps video and I had to enable hdmi_enable_4kp60=1 in config.txt to get it play right. Something changed in the kernel. I wonder if by doing that it might provide some extra needed video parameters needed even though you do not have a UHD monitor like me but are are playing a UHD video. I had never had to do that before. I also leave disable_fw_kms_setup=1 enabled because sometimes I switch over to kodi-rpi to a TTY with CTRL+SHFT+F2. It never seemed to hurt anything. Here is my config.txt in that section:
#enable vc4
#dtoverlay=vc4-fkms-v3d
dtoverlay=vc4-kms-v3d,cma-512
#max_framebuffers=2
#dtoverlay=rpivid-v4l2
disable_fw_kms_setup=1
hdmi_enable_4kp60=1
This option changes nothing. I think that “vc4-drm gpu: swiotlb buffer is full” is a different problem than
in a tty :
vc4-drm gpu: [drm] ERROR Failed to allocate DLIST entry: -28
or in journalctl
Page flip failed: drmModeAtomicCommit: No space available on the device
who make the freezes.
For the moment no more problems with pull/5684. I will continue to report.
I passed along your info to RPi.
Hello,
I tried per your recommendations.
1/ I have no attach-bluetooth.service at all.
2/ I had dtparam=krnbt=on in /boot/config.txt and removed it.
Still, 6.1.58-2 crashes at boot.
Sorry for providing no “logs”, but the crash happens early and the pi 4 didn’t had a chance to log anything to disk.
Most of the times the crash happens just after console resolution change, so black screen, nothing to see. SD card access LED steady lit.
Rebooting several times I eventually got a chance to perform an “old fashioned” screenshot, that’s ugly but pretty readable.
It still complains about bluetooth, but the kernel actually crashes on aes_arm64 decryption, which is rather interesting.
That’s about all the info I can provide…
Since you have some old configs. If you have:
gpu_mem=64
dtoverlay=vc4-fkms-v3d
Also make these changes to:
#gpu_mem=64
dtoverlay=vc4-fkms-v3d
#Or if you need more gpu memory
dtoverlay=vc4-fkms-v3d,cma-512
I believe FKMS is broken right now and the consider it dreciated and not a priority to fix.
1 Like
Hello,
I followed your suggestion, but at the same time received a whole lot of new “testing” updates, among which kernel 6.1.58-5-MANJARO-RPI4.
And then it boots !
So I don’t know if it’s the settings change or the newer kernel, but well, looks like it’s fixed 
Thank you for your help !
1 Like
I imagine it was the config changes. I had no issue with the older kernel and do not remember anyone else having issues. Yep there was another testing snap done just now.
downgrade from 6.6, it against rpi-overlays package?
Not sure what you are asking but the rpi-overlays package should be good for all kernels in testing/unstable branches as well as the raspberrypi-bootloader packages.
can you try 6.6 → 6.5 or 6.1, then will know.
I just went from 6.6 → 6.1 with no issues. I still am not seeing what you are getting at. Seems like we went over this before. The overlays are maintained in their raspberrypi-firmware git and that git is based on what they call their stable branch which is always the latest upstream LTS kernel which right now is 6.1. In the future it will most likely be kernel 6.6. It is good for all kernels. They do not maintain a separate firmware git for each kernel. You can download and use the latest overlays on any present kernel they have. As well as any file in this directory except the kernels as our’s are custom compiled.
https://github.com/raspberrypi/firmware/tree/master/boot
They mostly do all of the development on what they consider their stable tree at the time and from there migrate what is needed to the other branches for conformity.
RPi is asking if you have an update. They are beginning to believe that some of those errors are the result of programs being closed or buggy. They specifically quoted this quote and asked if that means it is fixed.