kernel: status of 6.1 version

[hauke]

Status of Linux kernel 6.1 migration in master:

• airoha
• apm821xx
• archs38
• armsr
• at91
  • testing: at91: add testing kernel 6.1 #15196
• ath25
  • Drop: ath25: drop target #14793
• ath79
  • testing
• bcm27xx
• bcm47xx
  • testing
• bcm4908
  • testing
• bcm53xx
  • testing
• bcm63xx
  • Drop: [RFC] bcm63xx: drop target #14559
• bmips
• gemini
• imx
• ipq40xx
• ipq806x
• ixp4xx
• kirkwood
• lantiq
  • lantiq: Update to kernel 6.1 #13046
• layerscape
• malta
• mediatek
  • testing
• mpc85xx
• mvebu
• mxs
• octeon
• octeontx
  • testing: octeontx: add 6.1 testing kernel #15191
• omap
  • testing: omap: add support and switch to kernel 6.1 #14582
• oxnas
  • oxnas: drop target #15251
• pistachio
• qoriq
  • testing
• qualcommax
• ramips
  • testing: ramips: add 6.1 support #12738
  • ramips: switch to 6.1 kernel #14863
• realtek
  • https://git.openwrt.org/?p=openwrt/staging/svanheule.git;a=shortlog;h=refs/heads/realtek/testing-6.1
• rockchip
• sifiveu
• sunxi
• tegra
  • tegra: add kernel 6.1 support #14679
  • https://git.openwrt.org/?p=openwrt/staging/xback.git;a=shortlog;h=refs/heads/nvidia_jetson
• uml
• x86
• zynq
  • testing: zynq: add testing support for 6.1 #15188
  • zynq: switch to 6.1 as default kernel #15349

There is a discussion if we should use kernel 6.1 or kernel 6.6 for the next release, see http://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042204.html

This ticket was used to track the kernel 5.15 migration: #10672

Please comment to this ticket if there is something wrong or missing. If you have the permissions just update the ticket.

[xback]

@hauke
I have a large update for target Tegra pending here.

• bump to 6.1
• split to subtargets
• adds nvidia jetson board support

It already received a lot of testing offlist through nvidia channels.

I'll finish this up asap.

[svanheule]

@hauke
Testing 6.1 for realtek is mostly ready:
https://git.openwrt.org/?p=openwrt/staging/svanheule.git;a=shortlog;h=refs/heads/realtek/testing-6.1

[namiltd]

In reference to http://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042204.html maybe it would be worth creating a similar list for the 6.6 kernel? For now only for Loongson LoongArch 64 but you have to start somewhere.

[Noltari]

Speaking of bcm63xx I don't want to maintain it any further because it's such a PITA considering that there's no full device tree support, so I propose to drop it.
I know that a lot of bcm63xx devices aren't supported on bmips yet, but all of them could be added again in the future if users are still interested on them...

EDIT: PR created #14559

[remittor]

Patch add-cmdline-override is missing on many platforms!
Status OK: ipq806x, mediatek/filogic, mpc85xx

Appeal to maintainers:
This patch needs to be added to absolutely all targets! Regardless of the actual need to use option bootargs-override.

[dhewg]

omap @ #14582

[dhewg]

ramips got merged

[ptpt52]

with kernel 6.1 WED reboot/crash on mt7981

insmod mt7915e wed_enable=Y
[   74.734159] mt798x-wmac 18000000.wifi: attaching wed device 0 version 2
[   74.787920] platform 15010000.wed: MTK WED WO Firmware Version: DEV_000000, Build Time: 20221208202138
[   74.797280] platform 15010000.wed: MTK WED WO Chip ID 00 Region 3
(hang...and...reboot)

[raenye]

What is needed to make 6.1 the current version on apm821xx? I've been running 6.1 fine on my WD my book live since September or so.

[castillofrancodamian]

• ramips

  • testing: ramips: add 6.1 support #12738

I think the check is incorrect since kernel 6.1 has not been enabled by default.

[jeffguillaume]

mediatek package has updated to 6.1, apparently

[romanovj]

threaded backlog not working on 6.1 kernel, isn't it?

echo 1 > /proc/sys/net/core/backlog_threaded

[CHKDSK88]

mpc85xx: #14678

[Neustradamus]

@hauke: Thanks to have listenned to me! :)

• Kernel 6.6.x LTS instead of 6.1 LTS? #14262

It is important to use latest Kernel LTS: 6.6.x.

And please like LibreOffice, plan RC versions with the real official month release date.
LibreOffice 24.2 has been released the last day of January: 2024-01-31:

• https://blog.documentfoundation.org/blog/2024/01/31/libreoffice-24-2/

Mailing list message:

• https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042204.html

[edrikk]

Not sure how / if it’s tracked, but although MediaTek is checked, the AX6S and rfb1 builds are being skipped and require attention.

[KA2107]

Not sure how / if it’s tracked, but although MediaTek is checked, the AX6S and rfb1 builds are being skipped and require attention.

#14140 (comment)

[ttc0419]

Not sure how / if it’s tracked, but although MediaTek is checked, the AX6S and rfb1 builds are being skipped and require attention.

#14140 (comment)

Is that mean AX6S is no longer supported in future releases?

[namiltd]

I am asking for the same topic for kernel v6.6.

[danpawlik]

Not sure how / if it’s tracked, but although MediaTek is checked, the AX6S and rfb1 builds are being skipped and require attention.

#14140 (comment)

Is that mean AX6S is no longer supported in future releases?

Please don't make offtop here.
The AX3200 will be supported, there is a discussion - please read #14768 and #14770 and/or dadad6b

[CHKDSK88]

Layerscape is switched: 73f99b6
Kirkwood have PR for switching: #14803

[namiltd]

Test support for kernel 6.6 has just been merged into the repository: #14751
Support for mediatek is added in #14772

[khanjui]

Why SNAPSHOTS aren't building for ramips other than mt7620 for more than 4 days (after switching to 6.1(?))

https://buildbot.openwrt.org/images/#/builders/61/builds/113

[csharper2005]

Why SNAPSHOTS aren't building for ramips other than mt7620 for more than 4 days (after switching to 6.1(?))

https://buildbot.openwrt.org/images/#/builders/61/builds/113

Some devices exceed their limits:

	Line 23718:     WARNING: Image file /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/ubnt_edgerouter-x-kernel.bin is too big: 3175504 > 3145728
	Line 23729: if [ -e /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-kernel.bin -a "$(stat -c%s /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-kernel.bin)" -lt "3145728" ]; then echo '21001:7' > /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-factory.tar.compat; tar -cf /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-factory.tar --transform='s/^.*/compat/' /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-factory.tar.compat; tar -rf /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-factory.tar --transform='s/^.*/vmlinux.tmp/' /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-kernel.bin; /builder/shared-workdir/build/staging_dir/host/bin/mkhash md5 /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-kernel.bin > /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-factory.tar.md5; tar -rf /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-factory.tar --transform='s/^.*/vmlinux.tmp.md5/' /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-initramfs-factory.tar.md5; echo "dummy" > /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/o ...
	Line 23732: WARNING: initramfs kernel image too big, cannot generate factory image (actual 5840174; max 3145728)
	Line 23806:     WARNING: Image file /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/ubnt_edgerouter-x-sfp-kernel.bin is too big: 3175658 > 3145728
	Line 23826: if [ -e /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-kernel.bin -a "$(stat -c%s /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-kernel.bin)" -lt "3145728" ]; then echo '21001:7' > /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-factory.tar.compat; tar -cf /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-factory.tar --transform='s/^.*/compat/' /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-factory.tar.compat; tar -rf /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-factory.tar --transform='s/^.*/vmlinux.tmp/' /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-kernel.bin; /builder/shared-workdir/build/staging_dir/host/bin/mkhash md5 /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-kernel.bin > /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-factory.tar.md5; tar -rf /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-factory.tar --transform='s/^.*/vmlinux.tmp.md5/' /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-factory.tar.md5; echo "dummy" > /builder/shared-workdir/build/build_dir/targe ...
	Line 23828: WARNING: initramfs kernel image too big, cannot generate factory image (actual 5840327; max 3145728)
	Line 34122: file-system partition too big (more than 2858911 bytes): Success
	Line 34123: file-system partition too big (more than 2818048 bytes): Success
	Line 34130:     WARNING: Image file /builder/shared-workdir/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/tmp/openwrt-ramips-mt7621-tplink_re350-v1-squashfs-sysupgrade.bin is too big:  > 6160384

[castillofrancodamian]

@csharper2005 And what is happening that they don't fix it?

[csharper2005]

@castillofrancodamian anyone can figure it out, fix it and open a pull request. Therefore, we can ask ourselves the same question: why haven't we fixed it yet?

[castillofrancodamian]

@csharper2005 If anyone can fix it, why isn't it at this point?

[csharper2005]

@csharper2005 If anyone can fix it, why isn't it at this point?

I think this is obvious, but let's look at the possible reasons:

1. Lack of resources (motivation, knowledge, time, fast (or even any) build environment);
2. No one opened an issue and collected diagnostic data here https://github.com/openwrt/openwrt/issues;
3. No one indicated that this was important or posted on IRC;
4. There are more important tasks to do (according to priorities);
5. Passive behavior (it's easier to wait for someone else to fix it);
6. Passive-aggressive behavior (why should I fix everything);
7. etc

[wigyori]

The pistachio target doesn't seem to have too much traction, but I'll see if I can get together a 6.1 kernel for it.

[namiltd]

bcm47xx: #14968

[schuettecarsten]

Maybe this pinned issue should be updated to a new "kernel: status of 6.6 version"?

[namiltd]

Take a look at: 5876b4a and 076f945
It appears that kernel 6.6 has been selected as the default for the next OpenWRT release.

[namiltd]

@schuettecarsten

Maybe this pinned issue should be updated to a new "kernel: status of 6.6 version"?

kernel: status of 6.6 version #15192

[ascendbeing]

EDIT: I did flash it as instructed. That is, I did the fw_setenv commands and flashed factory. after hooking up that USB ath9k_htc card, the mwl8k 5ghz doesn't show up for other devices anymore, just the ath9k. I wanted both to work as AP. The 2.4 builtin is in STA and nothing changed from what I had before other than the addition of the USB card and the upgrade from 82 to 86 kernel. Instead of 5g AP now I only have 2g AP yet in luci 5g AP looks like it's working normally (but nothing will connect to it, and no it's not disabled).
ORIGINAL POST: I flashed an ea3500 to the new 6.1/apk styled packages around mar 31. I was going to add a kmod for a USB wifi dongle. But the kernel from mar 31 isn't still on the kmods dir. There are newer 6.1.82s but not the same one.
So I tried to sysupgrade today, and to my shock, I got the message, again, that I would have to do the fw_setenv commands again with a factory image. It claimed that I was still on a 2.0 image, not a 3.0 image.
Is that normal? Or was there another image upgrade after mar 31? For Kirkwood and specifically for arm xscale based ea3500/ea4500/e4200v2.
I didn't want to make an issue because the bot is sensitive and I don't have the router up rn to grab the specific log but you probably know what I'm talking about.
It may be worth mentioning that this router is dual partition so maybe it's the other partition that's not the new format? Maybe it would work if I advanced reboot to the other partition, then sysupgrade how I was trying to from that partition?
I think I answered my own question with that last paragraph, but I'll leave this up for anyone who might run into the same thing. Or if I'm missing something. Most likely, you have to do the process twice: 1x for 1 partition, then do the same thing while in your new boot environment, to have them both on the updated format. After that it should be smooth sailing, right?
My only concern is if I'm missing something here.

[sch-m]

I've added a new PR for lantiq 6.1 support: #15233
When this is merged, I will have a look at the 6.6 support.

[ascendbeing]

BTW, i didn't end up having answered my own question: it appears to want the factory firmware process to be done every single time you upgrade after you've upgraded from 5.15 or older to 6.1.
that is to say, 6.1 on Kirkwood , at least for ea3500, and probably its cousins, ea4500+e4200v2, have a major issue on 6.1.
if you're on 6.1, or migrating to 6.1, you can't do a straight sysup. it will whinge that you need to edit certain boot parameters and use factory fw.
it does end up working, but even after you've done so, and you're on the new one, it wants you to do it every single time for the rest of time.
is the warning being overly cautious? that is to say, is it triggering when it no longer needs to?
is there a compatibility issue with the advanced reboot software? i have that installed, and I've seen it does weird stuff like mounting the other partition, when you visit the advanced reboot page.
that's all i can think of as a largely non-coder. if i knew that's what upgrading to 6.1 would've gotten me to, I would've left things at 5.15 on the ea3500, cause it didn't claim every single time that the alleged format vs what it alleges the format i currently have are incompatible and require running and double-checking some fw_setenv cmds, before upgrading, and even after having done so like 3x so far, it always requires me to do that.

also, i still dont know why running an ath9k_htc USB AP on the ea3500 renders 1/2 of the built-in wifi devices useless. openwrt acts like they all work. i can get 2.4sta to work, and 2.4ap with the ath9k_htc to work. but 5ap, no matter what i have the settings set to, different tx powers, diff ssid, etc, no device is ever able to find it or connect. do i need to set a different mac? i never changed them