New Raspberry Pi Kernels & Related Packages

ARM
141

Ok, so I try using iostat. Now, is iostat reading below the fs level? I am not sure about this. If the f2fs is handed 100 bytes to write, does iostat see the 100 bytes or the bytes actually written to disk? iostat generates stats at the block device level and the filesystem works at the block device level. Does iostat gather the stats of the original data or the f2fs compressed data?

I ran iostat for both filesystems before and after the copy and the differences were:

KB read 815744 from the uncompressed
KB written 999900 to the compressed

Compression working? Who knows.

$ du -s /home
750922	/home

$ du -s /mnt/home
749086	/mnt/home

Hmm.

Note: There is another difference between the two filesystems. The compressed was also formatted with sb_checksum and inode_checksum enabled. I stumbled upon a recent patch submitted for fsck.f2fs and these checksums play a roll. Does this add to bytes written? Dunno.

142

These new kernels/headers and pasberrypi-bootloader packages have been pushed to the unstable branch when the mirrors sync.

Do not install the 2 raspberrypi-bootloader packages if you are booting on a usb drive with the pi4 8G board and the linux-rpi4-rc 5.10.rc3-1 kernel.

linux-rpi4-mainline 5.9.6-1
linux-rpi4-mainline-headers 5.9.6-1
linux-rpi4-rc 5.10.rc3-1
linux-rpi4-rc-headers 5.10.rc3-1
raspberrypi-bootloader 20201109-1
raspberrypi-bootloader-x 20201109-1
1 Like
143

The revert of the USB patch did not make it in rc3? Or it did, and the issue still exists?

144

5.9.6 and the new bootloaders work with my RPi4 4Gb and my RPi4 8Gb.

145

I guess you missed my post above after I looked at your link you posted. That was a fix for an issue I opened for the 5.8 kernel a long time ago. They fixed it at the time and looks like it got left out in a rebase and the fixed it again and yes I checked with the 5.10 kernel and the fix is still there and yes the current issue with the 5.10 kernel is still there.

Yes the issue is if you are booting on a usb drive with the pi4 8G board and the linux-rpi4-rc 5.10.rc3-1 kernel only.

Also there is no issue with the pi4 8G board and the linux-rpi4-rc 5.10.rc3-1 kernel booting from a sdcard. It does just fine and it does ok with the pi4 4G board and the linux-rpi4-rc 5.10.rc3-1 kernel booting from sdcard or usb drive.

146

Have the issue with 20201104 and rc2.

So do I roll back to 20201029 to run rc3? Or is 20201104 ok with rc3?

147

raspberrypi-bootloader / raspberrypi-bootloader-x 20201016-1 in the stable branch

148

Another way to make it work is use the bcm2711 .dtb from the linux-rpi4-mainline (kernel 5.9) package and then use the latest raspberrypi-bootloader / raspberrypi-bootloader-x packages in the unstable branch.

149

Of all of my options, including continuing to use a 4GB Pi, that one I think, sounds most appealing.

150

I lately been keeping the kernel 5.9 .dtb in /boot and putting -sav extension on it so all I have to do is copy it over after installing the 5.10 kernel.

1 Like
151

they fixed usb issue, rc3 need rebuild.

152

Using the stable version of the device tree is working on my 8GB.

153

It looks lke they did. I will compile it tomorrow.

From looking at the commit it is concerning that they did not pay any attention to me when I opened an issue 2 weeks ago and wanted me to close it. I even in my last post told them where the issue was. They only did something when some one in their forum mentioned it.

Scroll down to the last post to see where I told them where the issue was:

Anyway we will see tomorrow what the new compile will do.

I have another issue with the latest linux-rpi4 released yesterday where bluetooth is not working right. I was reluctant to create an issue with it because they seem to not want to pay attention lately. What is the use of filing an issue?

1 Like
154

I changed my mind and it is compiling now.

155

can you share PKGBUILD?

156

I will after the kernel builds/tested/pushed. All of my devices are tied up in a distcc farm compiling.

157

No V3D at the moment, I have mesa-git installed, and I reinstalled it just to make sure.

$ glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig

$ glxgears
Error: couldn't get an RGB, Double-buffered visual

So currently Xorg is falling back to the fb driver, I do not have fbturbo installed.

Edit: The kernel modules seem to be loaded.

$ lsmod | grep vc
bcm2835_mmal_vchiq     32768  3 bcm2835_codec,bcm2835_v4l2,bcm2835_isp
vc_sm_cma              36864  2 bcm2835_mmal_vchiq,bcm2835_isp
vc4                   270336  8
cec                    53248  1 vc4
drm_kms_helper        253952  3 vc4
snd_soc_core          241664  1 vc4
snd_pcm               126976  5 vc4,snd_bcm2835,snd_compress,snd_soc_core,snd_pcm_dmaengine
drm                   561152  7 gpu_sched,drm_kms_helper,v3d,vc4

$ lsmod | grep v3d
v3d                    81920  1
gpu_sched              45056  1 v3d
drm                   561152  7 gpu_sched,drm_kms_helper,v3d,vc4
158

Try going back to mesa.

159

Will do, but I bet it is due to the older dtb.

Edit: But rolling back did work, V3D is back.

160

I have tested with glxgears -info and it shows v3d as renderer.

My glxinfo with 5.9 .dtb:

glxinfo
glxinfo826×520 50.5 KB