When you order Pi5 did you also have your DHL parcel on hold by DHL?
Not on hold per say but held up several days by Germany customs due to large volumes they told me when I called the pi people.
DHL was a total nightmare for me. My pi5 spent several days everytime it reached different places.
The latest linux-rpi4/5 kernel packages has been pushed to the unstable branch when the mirrors sync. I am patiently waiting for them to upgrade their 6.7.y tree. There has been no updated since -rc6.
linux-rpi4 6.6.11-1
linux-rpi4-headers 6.6.11-1
linux-rpi5 6.6.11-1
linux-rpi5-headers 6.6.11-1
1 Like
I see an error from the initramfs8 build when upgrading linux-rpi4-mainline, seems able to boot alright though
==> Using configuration file: '/etc/mkinitcpio.conf'
-> -k 6.6.8-1-MANJARO-RPI4 -c /etc/mkinitcpio.conf -g /boot/initramfs8
==> Starting build: '6.6.8-1-MANJARO-RPI4'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [kms]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs8'
==> WARNING: errors were encountered during the build. The image may not be complete.
error: command failed to execute correctly
It has been that way for a couple of months. Maybe they will fix it some day.
Or try this:
This is probably the reason.
The latest linux-rpi4/5 kernels and rpi5-eeprom packages has been pushed to the unstable branch when the mirrors sync.
The rpi5-eeprom package has some preliminary work for network install which we do not use in latest but it is there if some one wants to do a network install of PiOS. Most of us use default so really no big reason to flash the pi5 eeprom.
They finally upgrade 6.7-rc6 to 6.7-rc8 but that is still 2 weeks behind. I decided to not waste my time with it as 6.7.1 could possibly hit at any time upstream.
linux-rpi4 6.6.12-1
linux-rpi4-headers 6.6.12-1
linux-rpi5 6.6.12-1
linux-rpi5-headers 6.6.12-1
rpi5-eeprom 20240116-1
1 Like
@Darksky
v6.7.1 (https://github.com/raspberrypi/linux/blob/rpi-6.7.y/Makefile) is out and v6.6.13 also.
Can I request to enable bcachefs module on the 6.7 kernel?
I have both compiled and tested. 6.6.13 sees to be good. 6.7 has a reboot/shutdown issue. It will lock up toward the end of the boot before the login screen and When I pull the power and pluf power back it goes through fsck then boots ok but the next boot it will go through the same process again. If you want to deal with that I will post 6.7 also with 6.6.13. I never tested it on the pi4 though. It may be different.
@Rip2 I will have to wait for RPi to add it to their gitlab tree. It’s no small job merging their tree with upstream. They have a ton of their own patches and they do a git rebase every week.
The latest linux-rpi4/5 kernels has been pushed to the unstable branch when the mirrors sync.
linux-rpi4 6.6.13-1
linux-rpi4-headers 6.6.13-1
linux-rpi5 6.6.13-1
linux-rpi5-headers 6.6.13-1
1 Like
6.6 config8, CONFIG_UDMABUF is not set ?
DMABUF options
CONFIG_SYNC_FILE=y
CONFIG_SW_SYNC is not set
CONFIG_UDMABUF is not set <— ???
CONFIG_DMABUF_MOVE_NOTIFY is not set
CONFIG_DMABUF_DEBUG is not set
CONFIG_DMABUF_SELFTESTS is not set
CONFIG_DMABUF_HEAPS=y
CONFIG_DMABUF_SYSFS_STATS is not set
CONFIG_DMABUF_HEAPS_SYSTEM=y
CONFIG_DMABUF_HEAPS_CMA=y
end of DMABUF options
Why are you needing it set? Rpi does not set it and looking around arch-arm does not and our linux kernel here does not.
I finally got around to testing the linux-rpi4-mainline 6.7.1-1 kernel package and they seem to be ok unlike the broken linux-rpi5-mainline 6.7.1-1 package. My router quit working yesterday.
@Dulbi the linux-rpi4-mainline 6.7.1-1 kernel has BCACHEFS_FS module enabled if you are wanting it for the pi4.
The eeprom packages has an update in latest regarding image and FAT compatibility which most of us use default so no big reason to flash the eeprom until it makes it to default.
I am going to open an issue with linux-rpi5-mainline 6.7.1-1 today on their github.
These packages pushed to the unstable branch when the mirrors sync.
linux-rpi4-mainline 6.7.1-1
linux-rpi4-mainline-headers 6.7.1-1
rpi4-eeprom 20240122-1
rpi5-eeprom 20240122-1
1 Like
youtube watch form 480p to 1080p, what a surprise.
don’t know which update caused by, kernel or ffmpeg(kynesim-6.0.1-main)?
1 Like
I have built upstream 6.8.0-rc1 here. How can I test this. Also I am on mesa 23.3.4 is that ok?
mesa-23.3.4 didn’t had CPU-jobs patches, 24.0-rc2 does.
@Rip2 rpi I’m in the process of compiling mesa-git 24.0.0_devel. But that still does not answer my question how to test if it is working.
run vulkan demos above link, special those raytracing.
None of the raytracing’s work on my pi4.
Enabled device extension "VK_KHR_acceleration_structure" is not present at device level
Enabled device extension "VK_KHR_ray_tracing_pipeline" is not present at device level
Enabled device extension "VK_KHR_deferred_host_operations" is not present at device level
Enabled device extension "VK_EXT_descriptor_indexing" is not present at device level
Could not create Vulkan device:
ERROR_EXTENSION_NOT_PRESENT
Wonder if something has to be enabled in mesa-git config or are you sure they are supposed to work. Looking up the errors it seems that if it is not mesa then the gpu does not support it.