Recently upgraded numactl 2.0.16-1 —> 2.0.17-1?
Yep, but i lost 2.0.16 backup.
There may not have been a 2.0.16. The last one archived is 2.0.15.
http://tardis.tiny-vps.com/aarm/packages/n/numactl/numactl-2.0.15-1-aarch64.pkg.tar.xz
I went ahead and built the linux-rpi5-rc kernel packages for the pi5 and changed the schedutil governor to ondemand as default in the kernel and it seems to be scaling just fine. I also can not see any fault with the kernel so far either.
I have also been testing the upstream -rc kernel and found that schedutil is broke there also so the issue is not with Rpi’s kernel tree.
This kernel also has bcache_fs enabled. I noticed they have done some more improvement with it in this kernel by adding another module for it.
If you want to test it along with me here is the kernel packages. Let me know here what you think of the ondemand governor:
https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-rpi5-rc/-/jobs/13625/artifacts/download
v6.7.4 is out and also v6.8.0-rc3.
These latest kernel packages has been pushed to the unstable branch when the mirrors sync.
They have been working on the 6.8-rc kernel for days to get it right with fixups and changes. One change I saw was to use upstream’s v4l2_mem2mem. They were still working working on the kernel today. It still has not passed all of their compile checks. I would like to wait on it a little longer.
linux-rpi4 6.6.16-1
linux-rpi4-headers 6.6.16-1
linux-rpi4-mainline 6.7.4-1
linux-rpi4-mainline-headers 6.7.4-1
linux-rpi5 6.6.16-1
linux-rpi5-headers 6.6.16-1
linux-rpi5-mainline 6.7.4-1
linux-rpi5-mainline-headers 6.7.4-1
ADDED:
The 6.8-rc kernels has been pushed to unstable when the mirrors sync.
linux-rpi4-rc 6.8.rc3-1
linux-rpi4-rc-headers 6.8.rc3-1
linux-rpi5-rc-6.8 rc3-1
linux-rpi5-rc-headers 6.8.rc3-1
ADDED 02-09-2024:
The rpi-overlays and raspberrypi-bootloader packages are now being built off the 6.6.y branch.
raspberrypi-bootloader 20240208-1
raspberrypi-bootloader-x 20240208-1
rpi-overlays 20240208-1
1 Like
anyone try bcachefs or can we buildimg on it?
6.8-rc4 is out.
All 3 Upstream raspberrypi/linux branches updated see:
rpi-6.6.y → all Tests passed
rpi-6.7.y → all Tests passed
rpi-6.8.y → KUnit Tests / VC4 Unit Tests failed
Only 6.6.y tree has so far but they just added another commit and started the tests over again. The other 2 are a week old. Hopefully the other 2 will be next.
1 Like
I messed with it some today. I would suggest using the 6.8-rc4 kernel when it is available as it is supposed to have some bcachefs bug fixes. I compiled the upstream -rc4 for today’s testing.
I went with a single drive to keep it simple. Right off the bat it will not let me partition the drive with a fat32 partition. It wants to use the whole drive. With a fat32 and bcachefs partition you get this when you try to mount the bcachefs so looks like one would have to boot initially off a sdcard then boot the bcachefs drive with root= in cmdline.txt.
[ray@kde ~]$ sudo mount -t bcachefs /dev/sda /mnt/bcache
ERROR - bcachefs_rust::cmd_mount: Fatal error: “invalid_sb_layout”
bcachefs (/dev/sda): error reading default superblock: Not a bcachefs superblock (got magic 00000000-000
0-0000-0000-000000000000)
bcachefs (/dev/sda): error reading superblock: Not a bcachefs superblock layout
Mounts when whole drive is formated to bcachfs
[ray@kde ~]$ sudo bcachefs format --label=ROOT_MNJRO /dev/sda
/dev/sda contains a bcachefs filesystem
Proceed anyway? (y,n) y
External UUID: c375df1e-400b-40bc-91d3-1d94eb5cf8a3
Internal UUID: f3e481c5-c9a1-4704-b0d2-ddbb266f4728
Magic number: c68573f6-66ce-90a9-d96a-60cf803df7ef
Device index: 0
Label:
Version: 1.4: member_seq
Version upgrade complete: 0.0: (unknown version)
Oldest version on disk: 1.4: member_seq
Created: Mon Feb 12 10:49:45 2024
Sequence number: 0
Time of last write: Wed Dec 31 18:00:00 1969
Superblock size: 1016
Clean: 0
Devices: 1
Sections: members_v1,disk_groups,members_v2
Features: new_siphash,new_extent_overwrite,btree_ptr_v2,extents_above_btree_updates,btree_updates_journalled,new_varint,journal_no_flush,alloc_v2,extents_across_btree_nodes
Compat features:
Options:
block_size: 512 B
btree_node_size: 256 KiB
errors: continue [ro] panic
metadata_replicas: 1
data_replicas: 1
metadata_replicas_required: 1
data_replicas_required: 1
encoded_extent_max: 64.0 KiB
metadata_checksum: none [crc32c] crc64 xxhash
data_checksum: none [crc32c] crc64 xxhash
compression: none
background_compression: none
str_hash: crc32c crc64 [siphash]
metadata_target: none
foreground_target: none
background_target: none
promote_target: none
erasure_code: 0
inodes_32bit: 1
shard_inode_numbers: 1
inodes_use_key_cache: 1
gc_reserve_percent: 8
gc_reserve_bytes: 0 B
root_reserve_percent: 0
wide_macs: 0
acl: 1
usrquota: 0
grpquota: 0
prjquota: 0
journal_flush_delay: 1000
journal_flush_disabled: 0
journal_reclaim_delay: 100
journal_transaction_names: 1
version_upgrade: [compatible] incompatible none
nocow: 0
members_v2 (size 144):
Device: 0
Label: ROOT_MNJRO (0)
UUID: b516bdd2-4b96-4d69-bd69-1a7c15242c14
Size: 57.3 GiB
read errors: 0
write errors: 0
checksum errors: 0
seqread iops: 0
seqwrite iops: 0
randread iops: 0
randwrite iops: 0
Bucket size: 256 KiB
First bucket: 0
Buckets: 234696
Last mount: (never)
Last superblock write: 0
State: rw
Data allowed: journal,btree,user
Has data: (none)
Durability: 1
Discard: 0
Freespace initialized: 0
mounting version 1.4: member_seq
initializing new filesystem
going read-write
initializing freespace
[ray@kde ~]$
[ray@kde ~]$ sudo mount -t bcachefs /dev/sda /mnt/bcache
[ray@kde ~]$
[ray@kde ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 93.3M 1 loop /var/lib/snapd/snap/core/16204
loop1 7:1 0 93M 1 loop /var/lib/snapd/snap/core/16578
loop2 7:2 0 74.1M 1 loop /var/lib/snapd/snap/vkquake/28
sda 8:0 1 57.3G 0 disk /mnt/bcache
└─sda1 8:1 1 57.3G 0 part
mmcblk1 179:0 0 29.7G 0 disk
├─mmcblk1p1 179:1 0 457.8M 0 part /boot
└─mmcblk1p2 179:2 0 29.3G 0 part /
zram0 253:0 0 11.4G 0 disk [SWAP]
I have run out of time today to add a filesystem to it and see if it will boot. Today is my grocery day.
I wonder what is up with the 2 external/internal UUIDS above.
[ray@kde ~]$ sudo blkid /dev/sda
[sudo] password for ray:
/dev/sda: UUID=“c375df1e-400b-40bc-91d3-1d94eb5cf8a3” BLOCK_SIZE=“512” LABEL_SUB=“ROOT_MNJRO” UUID_SUB=“b516bdd2-4b96-4d69-bd69-1a7c15242c14” TYPE=“bcachefs”
This mourning I populated my blank usb stick formatted with bcachefs with Manjaro’s filesystem and it booted just fine.
I initially booted off my sdcard’s boot partition then had cmndline.txt boot the root bcachefs on my usb stick with my pi4.
Keep in mind I am booting upstream’s kernel here. Things will be different with the RPi kernel.
cmdline.txt:
root=/dev/sda rootfstype=bcachefs rw rootwait console=ttyS1,115200 console=tty0 audit=0 snd_bcm2835.enable_headphones=1 usbhid.mousepoll=8
config.txt:
kernel=Image
arm_freq=2150device_tree=dtbs/broadcom/bcm2711-rpi-4-b.dtb
arm_64bit=1
disable_overscan=1#enable sound
dtparam=audio=onhdmi_drive=2
max_framebuffers=2
disable_splash=1
[ray@kde ~]$ uname -a
Linux kde 6.8.0-rc4-1-MANJARO-ARM-RC #1 SMP PREEMPT Mon Feb 12 13:08:33 UTC 2024 aarch64 GNU/Linux
[ray@kde ~]$ sudo blkid -o list
[sudo] password for ray:
device fs_type label mount point UUID
---------------------------------------------------------------------------------------------
/dev/sda bcachefs / c375df1e-400b-40bc-91d3-1d94eb5cf8a3
/dev/loop1 squashfs /var/lib/snapd/snap/core/16578
/dev/loop2 squashfs /var/lib/snapd/snap/vkquake/28
/dev/loop0 squashfs /var/lib/snapd/snap/core/16204
/dev/mmcblk1p1 vfat BOOT_MNJRO /boot 4DC6-ABED
/dev/mmcblk1p2 ext4 ROOT (not mounted) c187f0ba-b822-488a-8181-5d813ea913d5
/dev/zram0 swap zram0 [SWAP] 9acef65e-88b5-4fb3-9dce-81cdf24dd630
want to play bcachefs, but did not have 6.7 or 6.8 installed.
does buildimg profile bcachefs supported?
No and unsure at the moment if it will in the future.
Added 02-19-2024:
Pushed to the unstable branch when the mirrors sync:
rpi4-post-install 20240219-1
Updated 02-23-2024:
Pushed to the unstable branch when the mirrors sync:
linux-rpi4 6.6.18-1
linux-rpi4-headers 6.6.18-1
linux-rpi4-mainline 6.7.6-1
linux-rpi4-mainline-headers 6.7.6-1
linux-rpi5 6.6.18-1
linux-rpi5-headers 6.6.18-1
linux-rpi5-mainline 6.7.6-1
linux-rpi5-mainline-headers 6.7.6-1
rpi4-eeprom 20240221-1
rpi5-eeprom 20240221-1
rpi-overlays 20240221-1
1 Like
Hi, any word on mesa 24?
I built 24.0.0 and had to uninstall it because of some firefox issues. I built 24.0.1 and have been using it with no issues and see that arch-arm has been using it and see no one posting an issue on their forums. I am currently testing the latest 24.0.2 that was just released and it seems to be ok also. I want to test some more before I push it.
Since I can only test on the rpi it would be nice for others with different devices test it also and let me know if there are any issues. Rpi owners are welcome to test also. Just install the mesa package names you currently have installed for your device. For me here I have mesa and the vulkan packages for the rpi installed.
mesa
vulkan-broadcom
vulkan-mesa-layers
vulkan-swrast
New packages pushed to the unstable branch.
do you build include zink option, and how to test zink?
-D gallium-drivers=swrast,kmsro,v3d,vc4,zink
Yes
case "${CARCH}" in
armv7h) GALLIUM=",etnaviv,kmsro,lima,panfrost,tegra,v3d,vc4" ;;
aarch64) GALLIUM=",etnaviv,kmsro,lima,panfrost,svga,v3d,vc4" ;;
esac
-D gallium-drivers=r300,r600,radeonsi,freedreno,nouveau,swrast,virgl,zink,d3d12${GALLIUM}
No clue or what it does
I pushed an updated mesa 24.0.2 to the unstable branch.
@Rip2 Evidently zink was not working right. There is a temporary patch (fix) applied to the mesa 24.0.2 I pushed to the unstable branch.