Still patching for the SSD issue or did they revert?
Iâm still patching. This has been a long process with this issue; been going on for 2 weeks. They have narrowed down my patch some to address the issue but they still are not done anything yet on their side. Their last post said âA revert is likely, unless we find a fix first.â
It is beyond me why they release all of their kernels that is broke. I refuse to do it. If a fix is not possible then I will freeze the kernels until they do get a fix.
I purposely waited around since I knew they would have the issue also and drug arch-arm in since RPi had stalled with the issue and was going no where. Over the week end this got RPiâs attention again. Now arch-arm is now patching as of yesterday.
https://github.com/graysky2/linux/commit/fcd5dced618c4e0931544e98a02bfe4a3814194b
I had hopes that the patches for the v3d in the upstream would be resubmitted for 5.18 but that has not occurred. Sadly, it would seem this attempt has died on the vine.
The latest kernels and raspberrypi-bootloader packages has been pushed to the unstable branch when the mirrors sync.
linux-rpi4 5.15.32-1
linux-rpi4-headers 5.15.32-1
linux-rpi4-mainline 5.17.1-1
linux-rpi4-mainline-headers 5.17.1-1
raspberrypi-bootloader 20220330-1
raspberrypi-bootloader-x 20220330-1
@0n0w1c You might want to look at this issue and maybe add to it.
You were up late⌠or early. ![]()
I did see that, I expect his issue is trying to boot with a 32 bit kernel, pretty sure the uefi is 64bit only.
It did not take long for RPi to shut the door.
âWe do not support GRUB/UEFI bootâ
I pushed the latest RPi changes made in the last couple of days to the present 5.15.32/5.17.1 kernels to the unstable branch.
One change I made was involving a conversation here RPi Contributors with the possibility of compressing kernel modules with CONFIG_MODULE_COMPRESS_XZ=y. I decided to go ahead and implement this with these kernels so I am asking for feed back using it:
https://github.com/raspberrypi/linux/issues/4966
There has been a couple of members here reporting wifi issues so maybe these new kernels will fix it:
https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/217
The last change is a VC4 improvement:
https://github.com/raspberrypi/linux/commit/ddd39a7758e71196f1ab1682d29ee17806f20019
linux-rpi4 5.15.32-2
linux-rpi4-headers 5.15.32-2
linux-rpi4-mainline 5.17.1-2
linux-rpi4-mainline-headers 5.17.1-2
Unfortunately, I will not be able to test until tomorrow at the earliest.
I managed to get out of the office for a couple of hours before I must return. I updated and rebooted using mainline + kms and everything seems good, no issues noticed with my limited testing.
Thanks for this new feature ! I was able to boot and didinât see any drawbacks.
My questions are:
-
What can we test besides the fact that the machine boots well ? (and how ? I did systemd-analyse blame and didnât see anything suspicions)
-
Why did you choose ZX instead of, for example, ZSTD? (I donât know what arch/manjaro implemented but I thought that ZSTD was in vogue (cf. package compression change. I donât know also if it would be more efficient)
Other than the tests mentioned in the issue thread posted above just observe and note if their are any noticeable changes. I see none here.
The purpose of the issue created was to get a smaller file size with the modules to save some space. Although you can get various compression ratioâs with zstd when we switched over to .zst from .xz when building our packages here the file size actually got bigger because it uses the default compression level. The tighter you compress the more time it takes to do it and more cpu resources are used. I would imagine the kernel is also set to use the default zstd compression level when compressing the modules.
RPi added 5.18-rc1 to their repo today. They have hobbled it so it would compile but using KMS/FKMS gives a kernel stack trace. Right now it only will work using llvmpipe. So waiting for them to get V3D going before I release. Other than that everything else seems to be working.
They have introduce new random number generator:
which modifies drivers/char/random.c:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=478f74a3d8085076dfcb481aa9361b808a6aae94
Do you see any improvements on the entropy level ?
I did not test it. You can if you want. Click the Download button here and unpack artifacts.zip and install the kernel files with pacman -U.
Make sure you disable FKM and KMS in config.txt to avoid the kernel trace or you will have issues rebooting although it will still load llvmpipe.
Also make sure you have xf86-video-fbdev installed before you reboot in to the new kernel or it will not boot in to the Desktop.
Link removed. I am compiling with a fix that is supposed to fix the issue.
https://github.com/raspberrypi/linux/issues/4982
Additional 4-10-2022:
They have done a hack to get V3D working but they say it still is not right. The author anholt says he gets an OOM at @hour on his board. I have been running the webgl aquarium page and glxgears for about an hour and so far I have one instance of v3d fec00000.v3d: MMU error from client L2T (0) at 0x78a1000, pte invalid he mentioned in his commit on my pi4 8G ram board but it has not affected any performance or caused any other issues so far. I believe I will let the webgl page run for another hour and if no issues pop up I will push the kernel 5.18-rc1 to the unstable repo.
https://github.com/raspberrypi/linux/commit/70388f2326a06d9eef3fe525561d8a03f4206f66
Well I got off on another project and forgot about the 5.18-rc1 kernel running the webgl test page so it has now been several hours and I still see no real issues with it so I have pushed the kernel to the unstable branch for others to test also when the mirrors sync.
Please report back with your experiencesâŚ
linux-rpi4-rc 5.18.rc1-1
linux-rpi4-rc-headers 5.18.rc1-1
My setup also threw the error but it went unnoticed from a desktop perspective:
[ 186.974835] v3d fec00000.v3d: MMU error from client CLE (4) at 0xe621000, pte invalid
23 fps???
My setup only manages get 10 fps.
It does that in firefox. Did you try chromium?
With chromium I get 20+ fps, I feel better now. ![]()

