Moving Linux Kernel to 6.1

[dom]

[EDIT: 6.1 kernel is now available from apt]

We are planning to move to the 6.1 kernel in the near future (perhaps a couple of months).

The (probably) the next upstream LTS (Long Term Support) kernel(*). It has just left -rc testing.

One advantage is there is more raspberry pi specific support in the newer upstream kernels which reduces the number of downstream raspberry pi patches and so reduces maintenance effort. In particular the KMS driver (arm side driver for hardware video scaler and displays like hdmi) has now almost complete support upstream.

Obviously a newer kernel will bring additional kernel features and support for more devices (e.g. USB devices like wifi and dvb).
You can read up on what appeared in 5.16, 5.17, 5.18, 5.19, 6.0 and 6.1.

We have enabled MGLRU as default, as that appears to have promise for a significant improvement to performance in some memory constrained situations.

We will do this in a few stages. Initially updating the "next" firmware branch to the 6.1 kernel.
Assuming testing is positive, we will update the master rpi-update firmware branch.
Eventually the 6.1 kernel will appear with "apt upgrade" and on new RPiOS images in the future.

[EDIT: the master rpi-update branch has now updated to 6.1. Please use this branch for updates]

Update with:

Code: Select all

sudo rpi-update

and reboot. Ideally nothing much will change. "uname -a" will report 6.1.
Please report if you have any positive or negative experiences, compared to the 5.15 kernel.

Obviously this release is for testers who like to live on the bleeding edge. It's not intended for beginners, or users who need stability.
Backing up is always advisable. There may be regressions. There may be improvements. But we won't know without testers trying it and reporting back.

(*) 6.1 hasn't yet been announced as LTS, but it seems very likely. If LTS happens to be a later kernel, we will move the testing in this thread to that version.
[EDIT: 6.1 is now announced as LTS]

[aBUGSworstnightmare]

I was running 5.15.82-v8+ on a CM4 DUT and 'sudo rpi-update' only brings me to 5.15.83-v8+ .
So what I'm doing wrong?
Also compiled 6.1 from source already but could not install the kernel on the 5.15.82-v8+ DUT.

Sounds like 'error 60' .. so please shine a light on me

[dom]

I was running 5.15.82-v8+ on a CM4 DUT and 'sudo rpi-update' only brings me to 5.15.83-v8+ .
So what I'm doing wrong?

Sorry - you need "sudo rpi-update next". I've corrected the post.

[aBUGSworstnightmare]

That's it.
On 6.1.0 now, cloned the sources and compiling a custom kernel config. Will report back on findings.

[jahboater]

Now using 6.1 on ...

64-bit: Raspberry Pi 4 Model B Rev 1.4 8GB (GPU 124MB)

32-bit: Raspberry Pi 4 Model B Rev 1.1 4GB (GPU 16MB)

32-bit: Raspberry Pi Model B Plus Rev 1.2 512MB (GPU 16MB)

32-bit: Raspberry Pi Zero W Rev 1.1 512MB (GPU 16MB)

All upgrades went fine, I'll report if I find any problems.

[bls]

Running 6.1 on:
64-bit p02w
64-bit pi4 8GB

Super-clean upgrades and no problems so far.

[craigevil]

No issues on pi400 running rpios arm64.

[lurk101]

Nice. Here I was thinking I'd have to wait forever.

[CaptainMidnight]

Test upgraded one of our GPS NTP servers - all functionality working perfectly, thanks.

[Undertow]

Upgraded Pi 400 to 6.1 - all well so far.

I confirm mglru enabled - /sys/kernel/mm/lru_gen/enabled is set to 1

I see /sys/kernel/mm/lru_gen/min_ttl_ms is 0 when some sources suggest a setting of 1000. [EDIT: Found it in kernel docs MGLRU Thrashing Prevention]. Is there any known reason not to set this to 1000 on the Raspberry Pi 6.1 kernel? I'll try it anyway as I suppose it is our job to find out

Much thanks for the fast work in getting 6.1 for us to test so soon after it went out the door!

We have enabled LGMRU as default, as that appears to have promise for a significant improvement to performance in some memory constrained situations.

Noticed a typo in above - should be MGLRU not LGMRU

[redvli]

Update with:

Code: Select all

sudo rpi-update next

and reboot. Ideally nothing much will change. "uname -a" will report 6.1.

If I would do this, it would result in a non-bootable system. The script does not handle initrd; it is not generated also naming of the file might be an issue. But running
update-initramfs -c -k 6.1.0-v8+ -v
and patching the right version string in config.txt makes it boot as usual. I had ran 6.1 via another OS earlier, the kernel version works fine.
This is on 64-bit, bit strange that also 3x 32bit stuff is copied.

[redvli]

I see that rpi-update has got updated compared to a month ago (just comparing btrfs snapshots), now it is:
# apt list --installed | grep rpi-update
rpi-update/stable,stable,now 20210618 all [installed]

But doing a diff with the latest from github, I see that that one has quite some 32-bit 64-bit changes.

[craigevil]

weird issue. The display configuration keeps popping up every so often.

Graphics info from inxi:

Code: Select all

  Features: asimd cpuid crc32 evtstrm fp
Graphics:
  Device-1: bcm2711-hdmi0 driver: vc4_hdmi v: N/A bus-ID: N/A
    chip-ID: brcm:fef00700 class-ID: hdmi
  Device-2: bcm2711-hdmi1 driver: vc4_hdmi v: N/A bus-ID: N/A
    chip-ID: brcm:fef05700 class-ID: hdmi
  Device-3: bcm2711-vc5 driver: vc4_drm v: N/A bus-ID: N/A chip-ID: brcm:gpu
    class-ID: gpu
  Display: x11 server: X.Org v: 1.21.1.5 compositor: xfwm v: 4.18.0 driver:
    X: loaded: modesetting unloaded: fbdev dri: vc4
    gpu: vc4-drm,vc4_crtc,vc4_dpi,vc4_dsi,vc4_firmware_kms,vc4_hdmi,vc4_hvs,vc4_txp,vc4_v3d,vc4_vec
    display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
    s-diag: 582mm (22.93")
  Monitor-1: HDMI-A-1 mapped: HDMI-1 model: Sceptre T27 res: 1920x1080
    hz: 60 dpi: 81 size: 600x330mm (23.62x12.99") diag: 685mm (27") modes:
    max: 1920x1080 min: 720x400
  API: OpenGL v: 2.1 Mesa 22.3.1 renderer: V3D 4.2 direct render: Yes

[aBUGSworstnightmare]

What a nice surprise ... a long-cherished wish came true with 6.1 kernel: SN65DSI83/4/5 DSI-to-LVDS bridge supported with no additional hacks!

CM4+CM4IO with a SN65DSI84 bridge, driving a 24in LG TFT with LVDS interface

IMG_20221218_091249.jpg (154.25 KiB) Viewed 30879 times

Screenshot from the DUT.

2022-12-18-091234_1920x1080.jpg (114.32 KiB) Viewed 30879 times

Linux 6.1 kernel supports DSI83/4/5 now. One only needs to enable the driver, add an overlay and compile the kernel with the new config.

bridgesupported.jpg (19.39 KiB) Viewed 30879 times

Will continue testing the kernel on some devices which were using the DSI bridge, as well as on stock Pi's.

[geev03]

, Kernel: 6.1.0-v8+

Code: Select all

pi@raspberrypi:~ $ inxi -bDc 6
System:    Host: raspberrypi Kernel: 6.1.0-v8+ aarch64 bits: 64 Console: tty 1 Distro: Debian GNU/Linux 11 (bullseye)
Machine:   Type: ARM Device System: Raspberry Pi 400 Rev 1.0 details: BCM2835 rev: c03130 serial: 100000005d38c2c9
CPU:       Info: Quad Core Model N/A [MCP] speed: 1800 MHz min/max: 600/1800 MHz
Graphics:  Device-1: bcm2711-hdmi0 driver: vc4_hdmi v: N/A
           Device-2: bcm2711-hdmi1 driver: vc4_hdmi v: N/A
           Device-3: bcm2711-vc5 driver: vc4_drm v: N/A
           Display: server: X.org 1.20.11 driver: loaded: modesetting unloaded: fbdev tty: 168x44
           Message: Advanced graphics data unavailable in console. Try -G --display
Network:   Message: No ARM data found for this feature.
Drives:    Local Storage: total: 223.57 GiB used: 55 GiB (24.6%)
           ID-1: /dev/sda type: USB vendor: Integral Memory model: V Series SATA SSD 240GB size: 223.57 GiB
Info:      Processes: 212 Uptime: 3m Memory: 3.7 GiB used: 664.1 MiB (17.5%) Init: systemd runlevel: 5 Shell: Bash
           inxi: 3.3.01
pi@raspberrypi:~ $ neofetch --off
pi@raspberrypi
--------------
OS: Debian GNU/Linux 11 (bullseye) aarch64
Host: Raspberry Pi 400 Rev 1.0
Kernel: 6.1.0-v8+
Uptime: 4 mins
Packages: 2500 (dpkg)
Shell: bash 5.1.4
Resolution: 1920x1080
Terminal: /dev/pts/1
CPU: BCM2835 (4) @ 1.800GHz
Memory: 572MiB / 3793MiB





pi@raspberrypi:~ $

[aBUGSworstnightmare]

There is an issue with 'vc4-kms-dpi-panel-overlay.dts' when using the override 'at056tn53v1'

Code: Select all

compatible = "innolux,at056tn53v1", "simple-panel";

'panel-simple.c' from 5.xx kernel had a timing added for the Innolux display
https://github.com/raspberrypi/linux/bl ... le.c#L2493

which is missing from the version in 6.1 kernel
https://github.com/raspberrypi/linux/bl ... le.c#L2138

As a result of this X will not get started as the display can't bind.

How to proceed? Make a pull-request (on 6.1) to get is added again or do you want to change the overlay?

[PhilE]

Thanks for the heads-up on that panel. Hopefully it's just a case of forward-porting a patch or two.

[dom]

weird issue. The display configuration keeps popping up every so often.

I don't understand what you mean by this. Do you mean a raspberry app ("screen configuration" from preferences, perhaps?) spontaneously launches?
Or is this just your display's OSD? If so, what is it showing?

[dom]

I see /sys/kernel/mm/lru_gen/min_ttl_ms is 0 when some sources suggest a setting of 1000. [EDIT: Found it in kernel docs MGLRU Thrashing Prevention]. Is there any known reason not to set this to 1000 on the Raspberry Pi 6.1 kernel? I'll try it anyway as I suppose it is our job to find out

I don't see an obvious way to set this in the kernel itself (obviously the code could be hacked, but there isn't a .config option).
It can be set from the command line (or sysfs), but that will require a means outside of rpi-update to set.
If we believe it is beneficial, then RPiOS can set this.

It looks like it is probably beneficial to us ("desktop users who do not have oomd"). Let us know if you can observe any difference in behaviour with it set or not.

Noticed a typo in above - should be MGLRU not LGMRU

Fixed.

[PhilE]

@aBUGSworstnightmare The changes supporting the AT056tN53V1 panel was previously part of a commit adding 18-bit support. In later branches - rpi-6.0.y and rpi-6.1.y - this commit just adds the 18-bit support, dropping the panel-simple changes.

https://github.com/raspberrypi/linux/pull/5288 should restore the missing panel support - please cast your eye over it and, ideally, test it if you can.

[aBUGSworstnightmare]

@aBUGSworstnightmare The changes supporting the AT056tN53V1 panel was previously part of a commit adding 18-bit support. In later branches - rpi-6.0.y and rpi-6.1.y - this commit just adds the 18-bit support, dropping the panel-simple changes.

https://github.com/raspberrypi/linux/pull/5288 should restore the missing panel support - please cast your eye over it and, ideally, test it if you can.

Following this on GitHub

[aBUGSworstnightmare]

@6by9: In case you wan't to test the overlay with the timing parameters, I'm using this (ignore the PCA9538 stuff):

Code: Select all

			panel: panel {
				compatible = "panel-lvds";
				/* panel enable through PCA9538 IO1 */
				enable-gpios = <&pca 1 0>;

				backlight = <&backlight_lvds>;

				/* Physical dimensions of active area */
				width-mm = <94>;
				height-mm = <150>;

				data-mapping = "jeida-18";

				/* chungwa claa070wp03xg (Google Nexus 7 Gen1) */
				/* 800x1280pixel portrait mode timing */
				panel-timing {
					clock-frequency = <66800000>;
					hactive = <800>;
					vactive = <1280>;
					hfront-porch = <16>;
					hback-porch = <32>;
					hsync-len = <16>;
					vfront-porch = <6>;
					vback-porch = <2>;
					vsync-len = <2>;
					hsync-active = <0>; /* Active LOW */
					vsync-active = <0>;
					de-active = <1>; /* Active HIGH */
				};

				port {
					panel_in_lvds: endpoint {
						remote-endpoint = <&bridge_out>;
					};
				};
			};

make sure to enable the generic LVDS panel driver in your kernel config.

lvds.jpg (117.82 KiB) Viewed 30488 times

[dom]

I see /sys/kernel/mm/lru_gen/min_ttl_ms is 0 when some sources suggest a setting of 1000. [EDIT: Found it in kernel docs MGLRU Thrashing Prevention]. Is there any known reason not to set this to 1000 on the Raspberry Pi 6.1 kernel? I'll try it anyway as I suppose it is our job to find out

I did a basic test. With a 1GB Pi4, I loaded chromium and a heavy site (engadget). With:
enabled:0 loading 3 tabs and switching between them repeatedly eventually resulting in "Aw Snap!"
enabled:1 min_ttl_ms:0 loading 4 tabs and switching between them repeatedly eventually resulting in "Aw Snap!"
enabled:1 min_ttl_ms:1000 loading 2 tabs and switching between them repeatedly eventually resulting in "Aw Snap!"
enabled:1 min_ttl_ms:3000 loading 2 tabs and switching between them repeatedly eventually resulting in "Aw Snap!"
enabled:1 min_ttl_ms:5000 loading 2 tabs and switching between them repeatedly eventually resulting in "Aw Snap!"

So enabling mglru is beneficial, but min_ttl_ms does make tabs close (effectively an OOM in dmesg) more readily.
Possibly that is desired (you are not reaching the low memory situations that can make the pi unresponsive),
but maybe it's preventing some high memory use cases from running at all which may be undesirable.

Needs more testing - any reports welcome.

[euu]

Did not update yet under Raspberry Pi OS, but I built it from source on Gentoo.
No issues, everything works fine: RPI 4B 8GB, OS on SATA SSD, Argon Fan hat, 2 monitors, one HDMI, one DisplayPort (through adapter).

[aBUGSworstnightmare]

Wanted to prepare another CM4 + CM4IO this morning for testing latest kernel and I've noticed a strange issue. The uSD of said DUT was copied from another system which already runs on 6.1 (a CM4 as well).

I'm forcing 1440x900pixels via kernel command line as the system is 'headless' - at least for the stating point.

Code: Select all

video=HDMI-A-1:1440x900M@60D console=serial0,115200 console=tty1 root=PARTUUID=4b2bc05e-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

My OS comes up with 320x200pixels resolution

Code: Select all

pi@evo-6-1:~ $ DISPLAY=:0 xrandr --verbose
Screen 0: minimum 320 x 200, current 320 x 200, maximum 7680 x 7680
HDMI-1 connected (normal left inverted right x axis y axis)
	Identifier: 0x45
	Timestamp:  11422
	Subpixel:   unknown
	Clones:    
	CRTCs:      3
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	Broadcast RGB: Automatic 
		supported: Automatic, Full, Limited 16:235
	max bpc: 8 
		range: (8, 12)
	bottom margin: 0 
		range: (0, 100)
	top margin: 0 
		range: (0, 100)
	right margin: 0 
		range: (0, 100)
	left margin: 0 
		range: (0, 100)
	Colorspace: Default 
		supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 32 
		supported: 32
	non-desktop: 0 
		range: (0, 1)
  1440x900 (0x48) 106.684MHz -HSync +VSync
        h: width  1440 start 1528 end 1672 total 1904 skew    0 clock  56.03KHz
        v: height  900 start  903 end  909 total  934           clock  59.99Hz
HDMI-2 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x46
	Timestamp:  11422
	Subpixel:   unknown
	Clones:    
	CRTCs:      4
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	Broadcast RGB: Automatic 
		supported: Automatic, Full, Limited 16:235
	max bpc: 8 
		range: (8, 12)
	bottom margin: 0 
		range: (0, 100)
	top margin: 0 
		range: (0, 100)
	right margin: 0 
		range: (0, 100)
	left margin: 0 
		range: (0, 100)
	Colorspace: Default 
		supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 41 
		supported: 41
	non-desktop: 0 
		range: (0, 1)
pi@evo-6-1:~ $ 

Also can't force any resolution for HDMI1

Code: Select all

pi@evo-6-1:~ $ uname -a
Linux evo-6-1 6.1.0-v8+ #1 SMP PREEMPT Mon Dec 19 09:41:49 CET 2022 aarch64 GNU/Linux
pi@evo-6-1:~ $ sudo cat /sys/kernel/debug/device_component/gpu
aggregate_device name                                  status
-------------------------------------------------------------
gpu                                                     bound

device name                                            status
-------------------------------------------------------------
fe400000.hvs                                            bound
fef00700.hdmi                                           bound
fef05700.hdmi                                           bound
fe004000.txp                                            bound
fe206000.pixelvalve                                     bound
fe207000.pixelvalve                                     bound
fe20a000.pixelvalve                                     bound
fe216000.pixelvalve                                     bound
fec12000.pixelvalve                                     bound
pi@evo-6-1:~ $ DISPLAY=:0 xrandr --output HDMI-1 --primary --mode "1440x900"
xrandr: Configure crtc 3 failed

Using raspi-config for selecting a headless VNC resolution and revving the video mode from kernel command line brings X up with the expected resolution.
Adding the video mode back to kernel command line let X start up with 320x200 pixels again.