Moving Linux Kernel to 6.1

[dom]

Is there any hope we could try to convince you to do "CONFIG_BTRFS_FS=y" instead?

You can create an issue for discussion.
You should be willing to describe why this change is beneficial
(a built in modules will the reduce free ram available to every user).

[OpenSource Ghost]

Will the next RPiOS image come with in BTRFS format? Kernel 6.1 ofers plenty of improvement to BTRFS. don't want to convert EXT4 to BTRFS, but start from scratch and format SDCard in BTRFS.

All kernels are built with "CONFIG_BTRFS_FS=m".
All previous images are formatted as EXT4, and there are no current plans to change this.
A decision like this is beyond the scope of this thread which is for testing the 6.1 kernel.
Feel free to create a new thread discussing the merits of a switch to a different filesystem.

Did Kernel 6.1 resolve neighbor eviction problem? With Linux 5.15 static ARP is lost if Ethernet link goes down. If static ARP is assigned on RPi and on router and router reboots, then RPi loses static ARP entries. That wasn't the case with Linux Kernel before BullsEye was released. There was a thread about it somewhere on these forums...

That is beyond my knowledge, but this thread details how to update to 6.1 if you want to test.

Kernel 6.1+ did fix the ARP eviction issue present in Kernel 5.15! Kernel 6.1 added back SysCTL flag for "net.ipv4.conf.<interface>.arp_evict_nocarrier=0" that was removed from Kernel 5.15, but existed in pre-5.15 Kernel versions.

Is there a list of new SysCTL flags present in Kernel 6.1 that aren't present in Kernel 5.15? I know how to list all flags, but not new ones.

[PhilE]

The ARP eviction problem was introduced in 4.20 by https://github.com/raspberrypi/linux/co ... 53a6260a76, and fixed in 5.16 by https://github.com/raspberrypi/linux/co ... 156ec6f34e.

If you can list all current sysctl flags then you can run it on 5.15 and 6.1 and diff the two, something like:

Code: Select all

$ sort sysctl_flags_5.15.txt > 1
$ sort sysctl_flags_6.1.txt > 2
$ comm -13 1 2

[dom]

Is there a list of new SysCTL flags present in Kernel 6.1 that aren't present in Kernel 5.15? I know how to list all flags, but not new ones.

It seems that setting is documented here.
If you hit the history button you can see how it has changed over time.

You could also checkout the raspberrypi/linux git tree, and run git diff between different branches. But this is really beyond the scope of this thread.

[DougieLawson]

Is there any hope we could try to convince you to do "CONFIG_BTRFS_FS=y" instead?

You can create an issue for discussion.
You should be willing to describe why this change is beneficial
(a built in modules will the reduce free ram available to every user).

It's not beneficial while everyone else runs ext4.
If you need BTRFS for booting you'll have to include it in your initramfs.

[dickon]

The module's 2MB. That's quite a lot of RAM.

[dickon]

FWIW, current 64b Bullseye PiOS with an 'rpi-update next' kernel is playing 4k 10b H.265 perfectly under Kodi (without the sync issues I was having earlier; might be the full-upgrade or the kernel that's fixed it), and still doing bluetooth as I'd expect.

AFAIAC, it's done.

Taken me too long to test this. Sorry. Been on the list, but you know how it is...

[dickon]

Typed too soon. A/V sync issues still there after a while.

[redvli]

Typed too soon. A/V sync issues still there after a while.

A/V sync can have a root cause in kernel or GPU of cource, but I remember MPlayer could fix A/V on-the-fly. I would try VLC and mpv as well in order to have some indication if it is purely 5.15 -> 6.1 reason or something in Kodi or in one of the many patches in Debian Bullseye. How much is the out-of-sync? few frames? second(s)? monotone increment? jitter?

[dickon]

Typed too soon. A/V sync issues still there after a while.

A/V sync can have a root cause in kernel or GPU of cource, but I remember MPlayer could fix A/V on-the-fly. I would try VLC and mpv as well in order to have some indication if it is purely 5.15 -> 6.1 reason or something in Kodi or in one of the many patches in Debian Bullseye. How much is the out-of-sync? few frames? second(s)? monotone increment? jitter?

After a while it starts to jitter. Stopping and restarting seems to resume a few seconds or so after the stopping point. Been doing it on the packaged kernels but appeared better on 6.1 for a good while longer than usual. I expect it's a Kodi-on-PiOS issue.

[Solskogen]

It's not beneficial while everyone else runs ext4.
If you need BTRFS for booting you'll have to include it in your initramfs.

Oh, I know. But why is then F2FS included?

[bensimmo]

It's not beneficial while everyone else runs ext4.
If you need BTRFS for booting you'll have to include it in your initramfs.

Oh, I know. But why is then F2FS included?

I think they released some F2FS OS images some time back for testing, no idea what came of it.
Or users asked for it and provided good evidence of why?

[dom]

After a while it starts to jitter. Stopping and restarting seems to resume a few seconds or so after the stopping point. Been doing it on the packaged kernels but appeared better on 6.1 for a good while longer than usual. I expect it's a Kodi-on-PiOS issue.

As it's not 6.1 specific - this is probably worth a separate thread.

[redvli]

It's not beneficial while everyone else runs ext4.
If you need BTRFS for booting you'll have to include it in your initramfs.

Oh, I know. But why is then F2FS included?

Btrfs needs device-scanning in order to know about RAID-like allocations. Just like LVM needs that. So if you want a generic always working implementation, you need initrd/initramfs where you include a "btrfs scan ..." command. There was someone on this forum complaining that his Pi did not boot from multi-device Btrfs. After some messages, it turned out he was using a self-compiled kernel (Gentoo) with no initramfs (so no scanning directly after kernel load from 1st FAT).
The following question would then be: 'Why does RPiOS not use initramfs'. At some point, you need to do it yourself or use another Linux Distro. For example openSUSE has Btrfs (and FAT and Ext4) even in their (U-boot) bootloader (read-only, stripped down of course).

[dom]

Oh, I know. But why is then F2FS included?

There appeared to be evidence that f2fs was much more efficient,
and we were seriously considering making it a default, so encouraged testing.

But the speed ups tended to be short lived. Delaying erasing blocks, means you
get an initial performance boost when the card is clean and empty but it fades over time.

This was a decision we've regretted. It's a lot harder to remove a built in kernel option,
which may leave users with a non-booting system, so we are stuck with it being built-in.

[Solskogen]

Thank you for the explanation, I understand.
I've been running 6.1.9-v8+ with btrfs on my external SSD on the Pi4 8G for some days now, and I've encountered no problems!

[down1]

Any idea when it will be in the main repository?

[PhilE]

Until 6.1 is declared to be a Long Term Stable version we won't be committing to it, but I think that's the only serious hurdle at the moment.

[redvli]

Code: Select all

https://github.com/raspberrypi/firmware/blob/next/extra/uname_string*

contains 2 lines, I think it should only be the second one.

[dom]

Code: Select all

https://github.com/raspberrypi/firmware/blob/next/extra/uname_string*

contains 2 lines, I think it should only be the second one.

Correct. It'll be fixed in next build.

[cjan]

Linux 6.1 Officially Promoted To Being An LTS Kernel.

[dom]

Linux 6.1 Officially Promoted To Being An LTS Kernel.

To celebrate this occasion, the master branch of rpi-update is now being updated to the 6.1 kernel.
Please use rpi-update (without the next branch specified) for future updates to 6.1 kernel.

[JinShil]

To celebrate this occasion, the master branch of rpi-update is now being updated to the 6.1 kernel.

Is it possible for you to estimate when 6.1 might become the default when running pi-gen? Just looking for a ballpark to plan my own future work. Next week? Next month? Next Quarter?

[JinShil]

Using CM3+ with Bullseye 64-bit...

In kernel v5.15.84 this audio configuration works fine:

Code: Select all

dtparam=audio=on
dtoverlay=pwm-2chan,pin=40,func=4,pin2=41,func2=4
dtoverlay=vc4-kms-v3d,noaudio

But that configuration doesn't work in v6.1.10. There is no audio with `speaker-test` and `snd_pcm_open(ppcm, "default", SND_PCM_STREAM_PLAYBACK, 0);` fails.

However, this configuration works fine in both 5.15.84 and 6.1.10.

Code: Select all

dtparam=audio=on
dtoverlay=audremap,pins_40_41
dtoverlay=vc4-kms-v3d,noaudio

I'm fine to update my config.txt files, but I'm not sure whether that breakage was intentional or not.

I've tested GPIO, I2C, UARTs, and a number of other features in v6.1.10 on the CM3+, CM4S, and CM4, and I have not yet found any other differences between v5.15 and v6.1.

[PhilE]

Does adding "snd_bcm2835.enable_headphones=1" to cmdline.txt make the pwm-2chan case work again?

Switching to audremap is the correct thing to do; the pwm-2chan overlay is not the right tool for the job because it also enables a Linux driver for the same PWM block that the firmware is using for the analogue audio output.