Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Thibaut [2023-06-01 18:21:22]: Hi, > > There has been many timeouts of "3600 seconds without output" in master, > > These look like connectivity issues. I'm not sure, as there is a keep alive going on between master/worker so master would remove the worker quite sooner due to keep alive response timeout, wouldn't it? Putting asside some buildbot bugs of course. Workers osuosl-dock-09,10,11,12 are on one build host and osuosl-dock-05,06,07,08 are on the second build host, wouldn't they have same connectivity issues at the same time? I'm not saying it's not possible, there has been similar network issues in the past, so it might be it. > > and quite too many "out of space" errors in the 23.05 packages buildbot. > > 23.05 package builders are nearly all out of space, possibly due to > accumulated cruft in dl dir. from the quick look it seems like Rust has increased the disk space requirements in shared work directory. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Hannu Nyman [2023-06-01 19:11:13]: Hi, > * zabbix x13 (and borgbackup plus other python packages before it) seem to > be the typical last lines before he timeout failures... Random failures or > something due to recent changes ??? IIUC then from the buildbot master perspective it seems like the compilation got stuck somewhere for 1 hour, thats indeed quite strange. I don't remember seeing those errors previously. Anyway, as a quick fix attempt, I've now changed build worker CPU affinity, so each worker uses CPUs from the same NUMA node: NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22 NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23 -cpuset: 0-5 +cpuset: 0,2,4,6,8,10 We've 2 such hosts with 2x Xeon X5680 CPUs, having 4 build workers on each, using 6 CPUs for each build worker. So lets see if it improves the situation, I'll try to look at those build workers more closely now. > * with 23.05 the main problem seems to be "No space left on device"... I've noticed that as well, probably 23.05 is more disk space greedy and current 60GB allocation is not enough, so going to increase the disk size to fix that. I've just added 2x8 temporary build workers to cleanup the build queue and refresh the packages. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: add support for TP-Link TL-WDR6500 v2
From: Xiaobing Luo
This ports the TP-Link TL-WDR6500 v2 from ar71xx to ath79.
Specifications:
SoC: QCA9561
CPU: 750 MHz
Flash: 8 MiB (Winbond W25Q64FVSIG)
RAM: 128 MiB
WiFi 2.4 GHz: QCA956X 3x3 MIMO 802.11b/g/n
WiFi 5 GHz: QCA9882-BR4A 2x2 MIMO 802.11a/n/ac
Ethernet: 4x LAN and 1x WAN (all 100M)
USB: 1x Header
Flashing instructions:
As it appears, the device does not support flashing via GUI or
TFTP, only serial is possible.
Signed-off-by: Adrian Schmutzler
Signed-off-by: Xiaobing Luo
---
.../dts/qca9561_tplink_tl-wdr6500-v2.dts | 172 ++
.../generic/base-files/etc/board.d/01_leds| 7 +
.../generic/base-files/etc/board.d/02_network | 3 +-
target/linux/ath79/image/generic-tp-link.mk | 16 ++
4 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ath79/dts/qca9561_tplink_tl-wdr6500-v2.dts
diff --git a/target/linux/ath79/dts/qca9561_tplink_tl-wdr6500-v2.dts
b/target/linux/ath79/dts/qca9561_tplink_tl-wdr6500-v2.dts
new file mode 100644
index ..15c586865975
--- /dev/null
+++ b/target/linux/ath79/dts/qca9561_tplink_tl-wdr6500-v2.dts
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "qca956x.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "tplink,tl-wdr6500-v2", "qca,qca9561";
+ model = "TP-Link TL-WDR6500 v2";
+
+ aliases {
+ led-boot = _system;
+ led-failsafe = _system;
+ led-running = _system;
+ led-upgrade = _system;
+ label-mac-device =
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "Reset button";
+ linux,code = ;
+ gpios = < 1 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ lan4 {
+ label = "green:lan4";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ };
+
+ lan3 {
+ label = "green:lan3";
+ gpios = < 15 GPIO_ACTIVE_LOW>;
+ };
+
+ lan2 {
+ label = "green:lan2";
+ gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+ lan1 {
+ label = "green:lan1";
+ gpios = < 17 GPIO_ACTIVE_LOW>;
+ };
+
+ wan {
+ label = "green:wan";
+ gpios = < 18 GPIO_ACTIVE_LOW>;
+ };
+
+ led_system: system {
+ label = "white:system";
+ gpios = < 21 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2500>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x01>;
+ read-only;
+
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_uboot_0fc00: macaddr@0fc00 {
+ reg = <0x0fc00 0x6>;
+ };
+ };
+
+ partition@1 {
+ compatible = "tplink,firmware";
+ label = "firmware";
+ reg = <0x01 0x7e>;
+ };
+
+ partition@7f {
+ label = "art";
+ reg = <0x7f 0x01>;
+ read-only;
+
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ calibration_ath9k: calibration@1000 {
+ reg = <0x1000 0x440>;
+ };
+
+ calibration_ath10k: calibration@5000 {
+ reg = <0x5000 0x844>;
+ };
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ wifi@0,0 {
+ compatible = "qcom,ath10k";
+ reg = <0 0 0 0 0>;
+
Re: [PATCH 4/4] gemini: Bump to kernel v6.1
On 6/1/23 15:50, Linus Walleij wrote: On Thu, Jun 1, 2023 at 3:48 PM Christian Lamparter wrote: Hmpf. Unfortunately, OpenWrt's 6.1 isn't ready yet. If I just set the KERNEL_VERSION to 6.1 then the build-bots will fail to produce images. Aha how typical. hey, easy there ;) I think I might be able to explain why I resort to "sorry, but we are not ready yet" excuses based on this patch series. I looked into "how to get the old and new usb-fotg210" into one "define KernelPackage/usb-fotg210". Thing is, you put backported fotg's 6.2 infrastructure into your gemini's patches: 0002-usb-fotg210-Collect-pieces-of-dual-mode-controller.patch (that's a big one!) ... So, your gemini's 6.1 isn't the same as every other target in regard to fotg210 there (that said, gemini is currently the only user due to @TARGET_gemini. phew!). Due to the Makefile and KConfig changes: in OpenWrt's vanilla 6.1 the module is still fotg210-hcd(.ko), whereas gemini's 6.1 its been changed to fotg210(.ko). So, to deal with this at least a little bit, I just moved it to target/linux/gemini/modules.mk . That said: This should be worth it? Reason being that since all this extra time spend, should make the target+fotg210 ready for the upcoming, next stable release (v6.6/7?), right? Cheers, Christian BTW: Do you have some time to look into realtek's DSA for the RTL8363SB? I'm converting some of the APM821xx Devices to DSA and the rtl8365mb seems promising. I've seen that you did some major work there. But there are some snags that I'm not sure are limited to the RTL8363SB (access through MDIO needs different code. And what's up with the CPU-Port or Extif?) or not. (will post to the appropriate ML for that in the "upcoming months") ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Non-SoC target for ARM64
W dniu 1.06.2023 o 18:58, Philip Prindeville pisze: > Hi, Hi. > I'm thinking about the utility of being able to build a generalized ARM64 > image (not "armvirt") for bring up on new platforms for testing. > > There are a lot of generalized computing platforms like the Ampere Altra > servers that you might want to use as in inbound Apache proxy server, a load > balancer, a traffic shaper, etc. > > Can we add a generic target for ARM64 just as x86_64 (or x86/64) is the > generic AMD64 target? > > I'd like something that I could easily run on a Graviton2 or Altra or Ten64, > etc. > > Also not clear to me why the various ARM targets like "layerscape", "imx", > "octeontx", etc. don't live under a common directory. > > Yes, ARM is more optimized for SoCs that have I/O on-chip and hence there's > less mix-n-match compared to x86, but it's not completely unheard of either. > > What do you all think of adding a generic target for aarch64? > > And how awful would refactoring arm and aarch64 be? Did You overlook this message http://lists.openwrt.org/pipermail/openwrt-devel/2023-May/041091.html ? Posted a week ago. It's modifying armvirt target to boot it effortlessly on arm64 hardware. The name of target stays but that's only a name. > Thanks, > > -Philip Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] brcm: add CLM BLOB files for Luxul devices
From: Dan Haab
Add per-device regulatory configuration files for complete channel support and
maximum transmission power per regulatory domain.
Signed-off-by: Dan Haab
---
WHENCE | 15 +++
...rcmfmac4366c-pcie.luxul,xap-1610-v1.clm_blob | Bin 0 -> 28224 bytes
...rcmfmac4366c-pcie.luxul,xwr-3100-v1.clm_blob | Bin 0 -> 34368 bytes
3 files changed, 15 insertions(+)
create mode 100644 brcm/brcmfmac4366c-pcie.luxul,xap-1610-v1.clm_blob
create mode 100644 brcm/brcmfmac4366c-pcie.luxul,xwr-3100-v1.clm_blob
diff --git a/WHENCE b/WHENCE
index 32d71481..d3fc870d 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2630,6 +2630,21 @@ File: brcm/brcmfmac4371-pcie.bin
Licence: Redistributable. See LICENCE.broadcom_bcm43xx for details.
+File: brcm/brcmfmac4366c-pcie.luxul,xap-1610-v1.clm_blob
+File: brcm/brcmfmac4366c-pcie.luxul,xwr-3100-v1.clm_blob
+Link: brcm/brcmfmac4366c-pcie.luxul,xwr-3150-v1.clm_blob ->
brcmfmac4366c-pcie.luxul,xwr-3100-v1.clm_blob
+
+Licence: Redistributable.
+
+CLM (Country Locale Matrix) BLOB files contain regulatory configuration data.
+It's to be parsed and used by a wireless driver.
+
+Permission is hereby granted to use and redistribute those files as required.
+
+These firmware files are distributed in the hope that they will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.
+
File: brcm/brcmfmac4373.bin
File: cypress/cyfmac43012-sdio.bin
Link: brcm/brcmfmac43012-sdio.bin -> ../cypress/cyfmac43012-sdio.bin
diff --git a/brcm/brcmfmac4366c-pcie.luxul,xap-1610-v1.clm_blob
b/brcm/brcmfmac4366c-pcie.luxul,xap-1610-v1.clm_blob
new file mode 100644
index
..32ca36d7df48ecc5e899e89da347e16a8bcfdcb4
GIT binary patch
literal 28224
zcmeHwYkV8ob>E#kcODoF9y6E=5CBOKAP7PfNr7C51i>LRgg_FcKnNlr3Zkf$mf`Xz
zY3((uDz3Usw(EE;uQ!|Rw#{bkI_cU;wsq??w$t>Twt2X1+UC(m(mL-)`=KBEvES5l
zXD}c|Qd+eh}{5x%WK(=iGDeKw!CczHB0dw9PO65(l3c-t5Kt(8~zDW=
zP4+V3n!x8q<+oSa_1W6$KxMu)kB|=YX2vIT<2ly9_nH`gZfbney|z9Mb3XR*<=v
z;`W{5z{Gg|^nnTG+n;!0`};oe@v#ReaefXl*>1p__d4x6&`yn$v_-bxA@6>JFu7iX
zccvuoye+@?H5uAGynhtlBgNpYH-lgNYOvGy75H>t9LFh~ms2?(=f@Z;*o#%(qbOdl
zs;WNK@ALWnsqu6=ol9HkJL$L5@1(z+{viF0Y(AnxnaVK5yo&{9E~V@*fn;f(5T_
zc-`54Yx|w;4{p46d!^FO
z$p__jcaidH>~CU%vP9+xPC>d;jgX-+S-9_uu>4`|pF!BO}F;TO+TGygBm4k*^ku
zw{G2f<<^_GzWB;3ue|xnSKoZ|%`d|1s|ayAcb}UF3kUern28PB?;Pd`CvZB}4XjhF
zM>vBwQYLQ*iIIHu5;#ni;%DK3H|Chjr0C>P`6d}`FhDH9Ky
z+$cB8nTqQ32ZEX_6;%o9PBWRC*Y?)HZxdUbi_Ty3>}zHwo#*}AxXseRcv+_iC~
zH#af)T>kXbbYaGvE1j|C%V#SKn^|cKwB|?;Ggt>rV_MQ-kTD%y9O^$VqpwJ2ZW8
z!06avCYi&7Tsr%i5?hy^Xe^#}6*)N3o#wL79vpBK`|(p7S4J4w!-HLV`^6Y_nH%(|
z+pcNCk>c#)Qf_bX@u=sHFUa^Q#$odK6I{^>k3YrXWx3iM)WtP~Yxjdbb~#rMP8=O`
zr|viL!RhVGE&(RT#+Ah-*_A|g!QFCu4Ej--gd;AS_8!sW+w9@e?-54(V|0(nkzuJH
z*5}AbHI6c6{~qz9ZhvS14;(ei^#;S=F@yK%hwNj;;pkx-9;KKA^YP;icCGN(F`j=s
z`Uhg~xcGL(b3nJa^weT+We-xvQ{>?R@ofrYC`8oMAS_R?jIk6IbmX=dEgJ?wH;cHc
z9kDv<2gexn=rBAyE*voqcCvN!Lxb;_u|*iMXNvHH(jWA@8%u8fe6L{*eRsE={xDstXDWQi4>%P?sp=Ta3Pb)aSi{s*{W%C)DD%4ZDpr@asy
zGo@z_8|rXih9etSo+Z4$y;=NwXmz>OUugMR$lq$zx((9;aC6TfBMhA_Up=j
z`LF->6|BwIqt>01i25ekW_lEq>oEPe)soucR4T2xGSXYuI!Zss3h%^1O4mY
z__=@l^Z(?Z{9mk
zef;H5?Ean?V9jM-~F-oe(l$P<2OJ5g}?K~AODHJ`@U<|qKX<$U`fCwmxV#o43mbSM?N7IK~M5*mG!virTr
zJeYqX>p#gP7jx#5OlCl3`@iz>qTsN#_po1i68^66t{jW|ZG13Ne&7e+_?#OVKl-j4
z3t#&3VXxMXr;h8{!pxo;4@$%WSZ0bbxf+ia#W=0e|ehJrRHMrw$AGvtMhtIe^8z
zJMp8$eB-d*hg}wq)XzUGW)H`eA}@cnl=n0Qo4{@%mBZ_PoK+xpC#Am(lY9~|fFD#y=>5eJzVbAUfzE=xxV}vxPQesSoA$h-+Zqc
zevE4P_~qbXSJ%(GwY$3xunI5xFgUw|SV3PMt1Eihb?o8bJ$C*1
za1sx$^=xDJVO8Q?6A3yO6X6$+-x0o{G)yMC^=mWe|OZd$1K9$dRz;;R&=A|
Re: Non-SoC target for ARM64
I would like the comparative simplicity, size, and ease of configuration in openwrt to make it up into more virtualized environments, also. On Thu, Jun 1, 2023 at 11:01 AM Philip Prindeville wrote: > > Hi, > > I'm thinking about the utility of being able to build a generalized ARM64 > image (not "armvirt") for bring up on new platforms for testing. > > There are a lot of generalized computing platforms like the Ampere Altra > servers that you might want to use as in inbound Apache proxy server, a load > balancer, a traffic shaper, etc. > > Can we add a generic target for ARM64 just as x86_64 (or x86/64) is the > generic AMD64 target? > > I'd like something that I could easily run on a Graviton2 or Altra or Ten64, > etc. > > Also not clear to me why the various ARM targets like "layerscape", "imx", > "octeontx", etc. don't live under a common directory. > > Yes, ARM is more optimized for SoCs that have I/O on-chip and hence there's > less mix-n-match compared to x86, but it's not completely unheard of either. > > What do you all think of adding a generic target for aarch64? > > And how awful would refactoring arm and aarch64 be? > > Thanks, > > -Philip > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Podcast: https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/ Dave Täht CSO, LibreQos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Non-SoC target for ARM64
Hi, I'm thinking about the utility of being able to build a generalized ARM64 image (not "armvirt") for bring up on new platforms for testing. There are a lot of generalized computing platforms like the Ampere Altra servers that you might want to use as in inbound Apache proxy server, a load balancer, a traffic shaper, etc. Can we add a generic target for ARM64 just as x86_64 (or x86/64) is the generic AMD64 target? I'd like something that I could easily run on a Graviton2 or Altra or Ten64, etc. Also not clear to me why the various ARM targets like "layerscape", "imx", "octeontx", etc. don't live under a common directory. Yes, ARM is more optimized for SoCs that have I/O on-chip and hence there's less mix-n-match compared to x86, but it's not completely unheard of either. What do you all think of adding a generic target for aarch64? And how awful would refactoring arm and aarch64 be? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Hi, > Le 1 juin 2023 à 18:11, Hannu Nyman a écrit : > > Looks like the new buildbot code and new instances (also for 23.05) are not > yet quite stable... > > Packages of some popular architectures like aarch64_cortex-a53 for mt7622 and > ipq807x have not been built for a week in master. « packages » buildbots (aka phase2) haven’t been updated. They’re still running old buildbot code, even though the hostname says « staging ». See ‘About’ on buildbot page to confirm. Only phase1 has been updated, for master and 23.05 (22.03 pending). > There has been many timeouts of "3600 seconds without output" in master, These look like connectivity issues. > and quite too many "out of space" errors in the 23.05 packages buildbot. 23.05 package builders are nearly all out of space, possibly due to accumulated cruft in dl dir. HTH T ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Packages buildbot is erratic, both master and 23.05 packages fail often
Looks like the new buildbot code and new instances (also for 23.05) are not yet quite stable... Packages of some popular architectures like aarch64_cortex-a53 for mt7622 and ipq807x have not been built for a week in master. There has been many timeouts of "3600 seconds without output" in master, and quite too many "out of space" errors in the 23.05 packages buildbot. * zabbix x13 (and borgbackup plus other python packages before it) seem to be the typical last lines before he timeout failures... Random failures or something due to recent changes ??? * with 23.05 the main problem seems to be "No space left on device"... Much too many buildbot-specifc errors compared to proper build failures due to source code... Something strange/unstabilized in the buildbot ? Or just some newly updated problematic packages causing havoc? https://buildbot.staging.openwrt.org/openwrt-23.05/packages/#/ https://buildbot.staging.openwrt.org/master/packages/#/builders Downloads https://downloads.openwrt.org/releases/23.05-SNAPSHOT/packages/ https://downloads.openwrt.org/snapshots/packages/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] firmware-utils: add required PKG_BUILD_DEPENDS
From: Rafał Miłecki This project provides a lot of independent utils. Most of them don't depend on SSL (or zlib). Build process however compiles all of them including those few that require SSL/ZLIB. To make copmilation step always succeed it's needed to specify build time dependencies. Runtime dependencies will be handled per-package (if we ever package one of those needing SSL/ZLIB). This fixes: -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) -- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR) CMake Error at CMakeLists.txt:9 (MESSAGE): Unable to find zlib library. Reported-by: Hauke Mehrtens Signed-off-by: Rafał Miłecki --- package/utils/firmware-utils/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/package/utils/firmware-utils/Makefile b/package/utils/firmware-utils/Makefile index f49cca01bb..2f77d001ff 100644 --- a/package/utils/firmware-utils/Makefile +++ b/package/utils/firmware-utils/Makefile @@ -11,6 +11,8 @@ PKG_SOURCE_DATE:=2023-05-18 PKG_SOURCE_VERSION:=02cdbc6a4d61605c008efef09162f772f553fcde PKG_MIRROR_HASH:=f5188fc38bb03ddbcc34763ff049597e2d8af98c0854910dc87f10e5927096e2 +PKG_BUILD_DEPENDS:=openssl zlib + include $(INCLUDE_DIR)/package.mk include $(INCLUDE_DIR)/cmake.mk -- 2.35.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/4] gemini: Bump to kernel v6.1
On Thu, Jun 1, 2023 at 3:48 PM Christian Lamparter wrote: > Hmpf. Unfortunately, OpenWrt's 6.1 isn't ready yet. If I just > set the KERNEL_VERSION to 6.1 then the build-bots will fail to > produce images. Aha how typical. > If you want to look: There's this fortify-source bug in mac80211 > ath9k that needs to be fixed first: > https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568297522 > https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568856473 > https://github.com/openwrt/openwrt/pull/12764#issuecomment-1569473000 > > (And it looks like not all modules dependencies have been sorted out yet). Oh I really don't know my way around that code... > For the time being. I could just change this to > KERNEL_TESTING_PATCHVER=6.1 and leave KERNEL_PATCHVER at 5.15. > > (So, people can pick 6.1 when they do their own builds until the > 6.1 woes have been sorted out?) This works for me, it's nice to have it upstream rather than in my odd trees. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/4] gemini: Bump to kernel v6.1
On 5/31/23 23:21, Linus Walleij wrote: This bumps the Gemini kernel to use v6.1. There is no reason to stay with v5.15, I personally use newer upstream kernels constantly and they are tested and work well. Hmpf. Unfortunately, OpenWrt's 6.1 isn't ready yet. If I just set the KERNEL_VERSION to 6.1 then the build-bots will fail to produce images. If you want to look: There's this fortify-source bug in mac80211 ath9k that needs to be fixed first: https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568297522 https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568856473 https://github.com/openwrt/openwrt/pull/12764#issuecomment-1569473000 (And it looks like not all modules dependencies have been sorted out yet). For the time being. I could just change this to KERNEL_TESTING_PATCHVER=6.1 and leave KERNEL_PATCHVER at 5.15. (So, people can pick 6.1 when they do their own builds until the 6.1 woes have been sorted out?) Cheers, Christian Signed-off-by: Linus Walleij --- target/linux/gemini/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile index 4266db16cd37..b7f1962c9a59 100644 --- a/target/linux/gemini/Makefile +++ b/target/linux/gemini/Makefile @@ -11,7 +11,7 @@ FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part CPU_TYPE:=fa526 SUBTARGETS:=generic -KERNEL_PATCHVER:=5.15 +KERNEL_PATCHVER:=6.1 define Target/Description Build firmware images for the StorLink/Cortina Gemini CS351x ARM FA526 CPU ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt IKEv2 NAT traversal (or similar) problem
On 5/31/23 21:08, Yousong Zhou wrote: Not that I got any clue, but this looks very suspicious that you saw the supposed-to-go-through-tunnel packet at an intermediate router (the openwrt device). I don't know exactly what happened here, but I didn't see it again. In any case, it turns out that enabling the xfrm module resolved the problem - hopefully this saves someone else some grief. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
