Moving Linux Kernel to 6.1

[craigevil]

The 6.1 kernel is now available from apt. Thanks for testing.

Awesome! Thanks.

[AkulaMD]

The 6.1 kernel is now available from apt. Thanks for testing.

Updated mine a while ago. Thanks.

[mitu]

The latest update changes a couple of defaults that may be significant:
1. Pi4 now defaults to preferring a 64-bit kernel when arm_64bit is not specified. You can use arm_64bit=0 to request the 32-bit kernel.

In general a switch to 64-bit kernel should be unnoticed. It works fine with a 32-bit OS.
It should improve performance of some kernel driver code.

As usual, report here if there are any issues from this change.

For an existing 32bit installation, wouldn't this break the ability to compile your own modules, since gcc cannot build 64bit modules ?
Leaving aside the myriad of script/build files which assume the current system architecture by inspecting uname -m and would fail in this scenario.

[redvli]

The latest update changes a couple of defaults that may be significant:
1. Pi4 now defaults to preferring a 64-bit kernel when arm_64bit is not specified. You can use arm_64bit=0 to request the 32-bit kernel.

In general a switch to 64-bit kernel should be unnoticed. It works fine with a 32-bit OS.
It should improve performance of some kernel driver code.

As usual, report here if there are any issues from this change.

For an existing 32bit installation, wouldn't this break the ability to compile your own modules, since gcc cannot build 64bit modules ?
Leaving aside the myriad of script/build files which assume the current system architecture by inspecting uname -m and would fail in this scenario.

You can use arm_64bit=0 to request the 32-bit kernel. So after the upgrade, but before you reboot, edit /boot/config.txt to set the value.

I have used / use getconf LONG_BIT to determine if the SBC under maintenance is 64-kernel+32-userland, currently only for a mostly powered-off Pi3B. The rest is all 64-userland (if ARMv8). It costs some time to port, but you can run your 32-bit root-tree in a KVM on 64-bit or container or systemd-nspawn. Or cross-compile (32-gcc => 64-kernel files). Or re-think and remove/replace hardware that requires kernel compilation. I was and am glad at least that we can get rid of kernel7l.img now. Maybe you have memory issues (1GB Pi4).

[rpdom]

since gcc cannot build 64bit modules ?

Can't it? Why not?

Surely all you need is the appropriate cross-compiler and set the architecture type when compiling.

[dickon]

since gcc cannot build 64bit modules ?

Can't it? Why not?

Surely all you need is the appropriate cross-compiler and set the architecture type when compiling.

32b userland /usr/bin/gcc won't be able to target aarch64.

Interesting point.

[PhilE]

Code: Select all

 sudo apt install gcc-aarch64-linux-gnu

?

[andrum99]

.

[PhilE]

To expand on my earlier post a bit, after installing the ARM 32 -> 64-bit compiler toolchain:

Code: Select all

sudo apt install gcc-aarch64-linux-gnu

you just need to ensure that your kernel "make" lines include "ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-", e.g.

Code: Select all

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image modules dtbs

Watch out for the arm64/aarch64 naming confusion - AArch64 is what ARM call it, but you'll see both in the wild.

Alternatively, you can put them in your environment with:

Code: Select all

export ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-

That way you don't need to change the make command, and you may save some typing. Just be aware that it may affect other builds you do.

[Xesarni]

I have an audio library on a USB stick. After upgrading to 6.1, I'm getting errors like this when using foobar2000 (Windows 10 22H2) to play audio files from that library (SMB share):

"Decoding failure at 1:51.993 (Unexpected network error)"

journalctl shows no errors. Switching from ksmbd to Samba didn't help to resolve this issue.

[dickon]

Code: Select all

 sudo apt install gcc-aarch64-linux-gnu

?

Yes, you know that and I know that and we know how to sort out cross-compilation and whatnot, but the average user who doesn't do this sort of thing for a living likely won't and will come unstuck if /usr/bin/gcc won't compile the out-of-tree kernel module that they're relying on using the instructions they've always followed.

Don't get me wrong: I think it's by far the right thing to do, but then I've been running 64b kernels on these things since it's been possible and have advocated doing so around these parts ever since.

[redvli]

Yes, you know that and I know that and we know how to sort out cross-compilation and whatnot, but the average user who doesn't do this sort of thing for a living likely won't and will come unstuck if /usr/bin/gcc won't compile the out-of-tree kernel module that they're relying on using the instructions they've always followed.

I think if you compile out-of-tree kernel modules then you are not an average user. That is why I wrote earlier: "Or re-think and remove/replace hardware that requires kernel compilation." Or choose another Linux distro maybe or other OS (FreeBSD if ZFS is important). Also this topic is in "Advanced users", started as 'testing'.

[redvli]

I have an audio library on a USB stick. After upgrading to 6.1, I'm getting errors like this when using foobar2000 (Windows 10 22H2) to play audio files from that library (SMB share):

"Decoding failure at 1:51.993 (Unexpected network error)"

journalctl shows no errors. Switching from ksmbd to Samba didn't help to resolve this issue.

This looks to me as standard failure analysis. From the mp3file on the USB-stick to network cables to this windows player. Start in the middle I would say; play the same mp3file not on windows but on some other computer/platform. etc .

[dickon]

I think if you compile out-of-tree kernel modules then you are not an average user. That is why I wrote earlier: "Or re-think and remove/replace hardware that requires kernel compilation." Or choose another Linux distro maybe or other OS (FreeBSD if ZFS is important). Also this topic is in "Advanced users", started as 'testing'.

There are enough weird devices out there -- *plenty* of rtl8xxx wifi chips, each seeming to need its own OoT driver, for example -- that it's reasonably common to see people on these forums asking about them. This change will negatively affect people who are doing nothing different to what they've always done over the last few years on a kernel update, and they're going to be surprised by it. Yes, this topic is in 'advanced users', but this will be rolled out to ordinary mortals at some point in the not too distant.

[tvoverbeek]

Did a regular 'sudo apt update; sudo apt -y upgrade' today on a Pi3B+ and after reboot I got::

Code: Select all

Linux picam2-32 6.1.19-v7+ #1637 SMP Tue Mar 14 11:04:52 GMT 2023 armv7l

So I guess 6.1 is standard now.

[lurk101]

Did a regular 'sudo apt update; sudo apt -y upgrade' today on a Pi3B+ and after reboot I got::

Code: Select all

Linux picam2-32 6.1.19-v7+ #1637 SMP Tue Mar 14 11:04:52 GMT 2023 armv7l

So I guess 6.1 is standard now.

Yes, seems so. Across the board.

Code: Select all

pi@pi4b:~ $ uname -a
Linux pi4b 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux

[bensimmo]

yes that is what they announced
viewtopic.php?t=344246&start=250#p2091188

[PeaSea]

It seems that support for changing the onboard leds using /sys/class/leds/led[01] has disappeared when using 6.1. This seems to be the case on 3B, 3B+ and 4B.

Not sure where to report this.

[PhilE]

The names have changed to align with upstream, and to be more logical. They are called ACT and PWR.

[RonR]

since gcc cannot build 64bit modules ?

Can't it? Why not?

Surely all you need is the appropriate cross-compiler and set the architecture type when compiling.

build-kernel allows you to compile directly on a like-architecture Raspberry Pi or cross-compile on a dissimilar-architecture Raspberry Pi or other machine running a BASH compatible OS (such as x86 Debian, Ubuntu, etc) using a simple '--cross-compile' command line option.

[PeaSea]

The names have changed to align with upstream, and to be more logical. They are called ACT and PWR.

Thanks..

[dickon]

I think if you compile out-of-tree kernel modules then you are not an average user. That is why I wrote earlier: "Or re-think and remove/replace hardware that requires kernel compilation." Or choose another Linux distro maybe or other OS (FreeBSD if ZFS is important). Also this topic is in "Advanced users", started as 'testing'.

viewtopic.php?p=2091532#p2091532

That didn't take long.

[redvli]

There are enough weird devices out there -- *plenty* of rtl8xxx wifi chips, each seeming to need its own OoT driver, for example -- that it's reasonably common to see people on these forums asking about them. This change will negatively affect people who are doing nothing different to what they've always done over the last few years on a kernel update, and they're going to be surprised by it. Yes, this topic is in 'advanced users', but this will be rolled out to ordinary mortals at some point in the not too distant.

Those people rely on others, including you and me by posting on this forum, to get their stuff working. RealTek keeps dumping 'chips' on the market apparently without proper Linux kernel integration support. And not to forget the companies that solder some PCB around those chips. So should RPi engineers fix that while the Pi4 has onboard WiFi, paid for to Broadcom I assume and the Pi is cheap. Follow the money I would say.

[dickon]

Those people rely on others, including you and me by posting on this forum, to get their stuff working. RealTek keeps dumping 'chips' on the market apparently without proper Linux kernel integration support. And not to forget the companies that solder some PCB around those chips. So should RPi engineers fix that while the Pi4 has onboard WiFi, paid for to Broadcom I assume and the Pi is cheap. Follow the money I would say.

That's completely beside the point. I picked that example because it's one I've personally come across, but this change affects more than just a few bits of odd hardware -- it affects *eveyrbody* who wants to build a kernel module for whatever reason on a Pi 4 with a 32b userland following instructions that they've potentially been using for years now.

And no, I don't expect RPL to fix anything. I was merely pointing it out.

[bensimmo]

Perhaps a RPF/L blog post announcing the jump in kernel version, what it brings and what changes it makes with advice and work arounds would have been nice so people could prep for it when it happens. Or report any problems...

You know telling people first. (pro-active warning)

or 6:30pm on a Friday and go home and see what happens by Monday?

Yes most wouldn't notice anything, a few will and have. Many probably not even updated.
It's all advertisement that RPi are doing something too.

Anyway all working or me and the ones I've updated so far.