Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart
Hi Sander, I don't have the GS1900-48 at hand or even my records. I am on vacation and I will only be back in 10 days, we actually got stuck here in quarantine... You can also test the GPIO access in U-Boot using md.l and mw.l using the the indirect access register. I tested this once for the indirect table access registers and that worked. But I looked up when the GS1900-48 was released and it was around since at least 2013. I would be surprised if there are _not_ different versions around. We know that there _are_ actually different version with regards to the SoC. They use at least 3 different processor generations including different work-arounds necessary. Have a look at the forum on issues with reading non-existing PHYs and the port flooding table, which in SoC revisions < D cannot be read and requires a shadow table (not implemented, since we always flood to all ports, because port isolation overrides this anyway). On the warning: At least the initial warning came from the lock debugging I compiled in, which is based on Daniel's standard settings. IIRC, the lengthy warning was about sleeping in the wrong context, maybe there was also something about an issue with lock contention. Cheers, Birger On 24/02/2022 21:19, Sander Vanheule wrote: On Tue, 2022-02-22 at 23:39 +0100, Birger Koblitz wrote: Hi, the information on the external GPIO resetting the board of the Zyxel GS1900-48 comes from the hardware configuration reported by the stock firmware. It says: GS1900# show board [...] == Reset = Type: GPIO GPIO: EXT_5 [...] Using the rtk gpio commands in u-boot this can be confirmed. Can you list the commands that you used to test this? My bootloader only supports "rtk network ..." and "cst pinSet ...". On 22/02/2022 23:00, Sander Vanheule wrote: On Mon, 2022-02-21 at 21:23 +0100, Birger Koblitz wrote: Hi, I just checked with my multimeter, and while the GPIO5 on the RTL8231 does go high/low when I set the output high/low from Linux, my device certainly doesn't reset. The other GPIO lines on the chip do work, since SFP modules are correctly detected. Birger, just to be sure, can you confirm that your device does reset with GPIO5 on the RTL8231? Yes, it does.There is a warning, but then it reliably resets. That was why I left it in as is. I had another hard look at my board, to check if something may be wrong physically, but I cannot find anything. My device's board looks identical to the pictures on the switch wiki [1], which I think you uploaded earlier. There is some reset logic on the board [2], but I cannot figure out how GPIO5 would be connected to it electrically. Unless I missed a via connecting to that pin on the RTL8231, GPIO5 only appears to lead to TP2. GPIO5/TP2 does not appear to be connected electrically to any part of the circuit next to SW1. I could add a bodge wire to connect TP2 to pad U25:3, but gpio-restart should really work on unmodified hardware. [1] https://svanheule.net/switches/gs1900-48#board_details [2] https://svanheule.net/switches/gs1900-48#hard_reset_circuit Having another look at the source code of gpio-restart, the WARNING-s I reported in the patch's commit message occur at the following points of the GPIO output waveform: |< 100ms >|< 100 ms >|< 3000 ms >|< Restart failed _|_| |___|__ [ active ] _X \__/ [inactive] || | | || | ^ WARN @ drivers/power/reset/gpio-restart.c:46 || | || ^ WARN @ drivers/gpio/gpiolib.c:3098 |^ WARN @ drivers/gpio/gpiolib.c:3098 | ^ Restart should already occur here If everything is set up correctly, the system should restart before execution reaches the point where a warning can be emitted. If you say that you see a warning (any at all), AFAICT that means gpio-restart is not working. As they say, the proof of the pudding is in the eating, so I soldered a jumper wire between the RTL8231's GPIO5 pin (U38:25) and the line driven by the hard reset button (U25:3) [https://svanheule.net/switches/gs1900-48#hard_reset_circuit]. As expected from the analysis above, this results in a system rebooting without _any_ warning (using an initramfs from yesterday's snapshot builds): root@OpenWrt:/# reboot root@OpenWrt:/# [ 185.092891] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported [ 185.101879] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported [ 185.111835] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported [ 185.120484] rtl83xx_fib4_del: found a route with id 1, nh-id 0 [ 185.127681] rtl83xx-switch switch@1b00: unknown nexthop, id 0 [ 185.149505] rtl83xx-switch switch@1b00: unknown nexthop, id 0 [ 185.157262] rtl83xx_fib4_del: found a route with id 2, nh-id 0 [ 185.164418] rtl83xx-switch
Re: ubifs: handling dirty data (writing back) + power cuts
Rafał, - Ursprüngliche Mail - > Von: "Rafał Miłecki" > On 25.02.2022 15:17, Rafał Miłecki wrote: >> My actual problem is related to ubifs behaviour for power cuts happening >> between 5 and 35 seconds after saving a file: >> date > /mount/ubifs/test.txt && sleep 15 && echo CUT POWER *NOW* >> >> On the next boot test.txt exists but it's EMPTY (file size 0). > > FWIW I get acceptable ubifs behaviour if power cut happens in less than > 5 seconds after saving a file. For example: > date > /mount/ubifs/foo.txt && sleep 4 && echo CUT POWER *NOW* > > On the next boot foo.txt simply doesn't exist. > > > Everything works fine for power cuts happening after 30 + 5 seconds: > date > /mount/ubifs/bar.txt && sleep 35 && echo CUT POWER *NOW* > > On the next boot bar.txt exists and it contains a date. See: http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file Please let me know whether this helped. I guess mounting UBIFS in sync mode is what you want. But please also keep this in mind: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_semantics Thanks, //richard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ubifs: handling dirty data (writing back) + power cuts
On 25.02.2022 15:17, Rafał Miłecki wrote: My actual problem is related to ubifs behaviour for power cuts happening between 5 and 35 seconds after saving a file: date > /mount/ubifs/test.txt && sleep 15 && echo CUT POWER *NOW* On the next boot test.txt exists but it's EMPTY (file size 0). FWIW I get acceptable ubifs behaviour if power cut happens in less than 5 seconds after saving a file. For example: date > /mount/ubifs/foo.txt && sleep 4 && echo CUT POWER *NOW* On the next boot foo.txt simply doesn't exist. Everything works fine for power cuts happening after 30 + 5 seconds: date > /mount/ubifs/bar.txt && sleep 35 && echo CUT POWER *NOW* On the next boot bar.txt exists and it contains a date. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ubifs: handling dirty data (writing back) + power cuts
Hi, my system is setup as follows: # mount | grep ubifs /dev/ubi0_1 on /mount/ubifs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=1) # cat /proc/sys/vm/dirty_writeback_centisecs 500 # cat /proc/sys/vm/dirty_expire_centisecs 3000 (5 s and 30 s respectively) and I'm currently debugging some data issues related to power cuts. My actual problem is related to ubifs behaviour for power cuts happening between 5 and 35 seconds after saving a file: date > /mount/ubifs/test.txt && sleep 15 && echo CUT POWER *NOW* On the next boot test.txt exists but it's EMPTY (file size 0). For newly created files above behaviour is not the worst one - however I'd expect such file to not exist at all. The biggest problem is when dealing with existing files. In such case power cut means loosing it completely. I don't get *old* content nor *new* content. I noticed this behaviour with kernel 5.10 and also reproduced it with 5.4, 4.14 and 4.4. Is this a bug or some quirky feature? Can I do anything to avoid such situations except modifying all user space to call fsync() when needed? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] firewall3: bump to latest git HEAD
4cd7d4f Revert "firewall3: support table load on access on Linux 5.15+" 50979cc firewall3: remove unnecessary fw3_has_table Signed-off-by: Rui Salvaterra --- package/network/config/firewall/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/network/config/firewall/Makefile b/package/network/config/firewall/Makefile index f0123aa7fb..e5a58cc2e3 100644 --- a/package/network/config/firewall/Makefile +++ b/package/network/config/firewall/Makefile @@ -13,9 +13,9 @@ PKG_RELEASE:=2 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(PROJECT_GIT)/project/firewall3.git -PKG_SOURCE_DATE:=2022-01-10 -PKG_SOURCE_VERSION:=0f16ea5f055722a532d4e68c7ba34ed084b48b37 -PKG_MIRROR_HASH:=219478ef95b170b5122030715eac7b3317f2ac4d67e1a936c22a78b10e056123 +PKG_SOURCE_DATE:=2022-02-17 +PKG_SOURCE_VERSION:=4cd7d4f36bea731bf901cb067456f1d460294926 +PKG_MIRROR_HASH:=307baf09c61ce727b4edb4283144b0d8128ebba34b858cc6389571421f829a24 PKG_MAINTAINER:=Jo-Philipp Wich PKG_LICENSE:=ISC -- 2.35.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello, I'm new to this list and I hope I'm not doing anything wrong. I'm a CS student and I've used OpenWrt for years. I'm writing to this mailing list because I'd like to contribute to the project by adding support of the aformentioned device. From what I can see, there's already an open PR (https://github.com/openwrt/openwrt/pull/3762). I've merged the current master into my fork (https://github.com/eutampieri/openwrt) and I've built it. I can boot it from ramdisk but as soon as I flash the sysupgrade I get this into the serial log: >Kernel panic - not syncing: No working init found. Try passing init= option to >kernel. See Linux Documentation/admin-guide/init.rst for guidance. As far as I can tell, the init var isn't passed from the bootloader (uboot), but how can I fix this? Moreover, other users on the PR haven't reported any issue with the setup. Regards, Eugenio Tampieri --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipset: update to 7.15
Update to the latest upstream version. In this version there is a new
tool with which you we convert ipsets into nftables sets. Since we are
now using nftables as default firewall, this could be a useful tool for
porting ipsets to nftables sets.
Signed-off-by: Florian Eckert
---
package/network/utils/ipset/Makefile | 5 +++--
.../patches/0001-lib-ipset-fix-printf-warning.patch | 11 +++
2 files changed, 14 insertions(+), 2 deletions(-)
create mode 100644
package/network/utils/ipset/patches/0001-lib-ipset-fix-printf-warning.patch
diff --git a/package/network/utils/ipset/Makefile
b/package/network/utils/ipset/Makefile
index bc4945e0f6..7b8d035198 100644
--- a/package/network/utils/ipset/Makefile
+++ b/package/network/utils/ipset/Makefile
@@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=ipset
-PKG_VERSION:=7.6
+PKG_VERSION:=7.15
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=http://ipset.netfilter.org
-PKG_HASH:=0e7d44caa9c153d96a9b5f12644fbe35a632537a5a7f653792b72e53d9d5c2db
+PKG_HASH:=0a5545aaadb640142c1f888d366a78ddf8724799967fa20686a70053bd621751
PKG_MAINTAINER:=Jo-Philipp Wich
PKG_LICENSE:=GPL-2.0
@@ -62,6 +62,7 @@ endef
define Package/ipset/install
$(INSTALL_DIR) $(1)/usr/sbin
$(CP) $(PKG_INSTALL_DIR)/usr/sbin/ipset $(1)/usr/sbin/
+ $(CP) $(PKG_INSTALL_DIR)/usr/sbin/ipset-translate $(1)/usr/sbin/
endef
define Package/libipset/install
diff --git
a/package/network/utils/ipset/patches/0001-lib-ipset-fix-printf-warning.patch
b/package/network/utils/ipset/patches/0001-lib-ipset-fix-printf-warning.patch
new file mode 100644
index 00..90dfacab8f
--- /dev/null
+++
b/package/network/utils/ipset/patches/0001-lib-ipset-fix-printf-warning.patch
@@ -0,0 +1,11 @@
+--- a/lib/ipset.c
b/lib/ipset.c
+@@ -1847,7 +1847,7 @@ static int ipset_xlate(struct ipset *ips
+ return -1;
+ case IPSET_CMD_LIST:
+ if (!set) {
+- printf("list sets %s\n",
++ printf("list sets %s %s\n",
+ ipset_xlate_family(family), table);
+ } else {
+ printf("list set %s %s %s\n",
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] check-toolchain-clean.sh: workaround stray rebuilds
It seems, that there are currently some unhandled corner cases in which
`.toolchain_build_ver` results in empty file and thus forcing rebuilds,
even if the toolchain was build correctly just a few moments ago. Until
proper fix is found, workaround that by checking for this corner case
and simply populate `.toolchain_build_ver` file.
While at it, improve the UX and display version mismatch, so it's more
clear what has forced the rebuild:
"Toolchain build version changed (11.2.0-1 != ), running make targetclean"
References: https://gitlab.com/ynezz/openwrt/-/jobs/212533/raw
Signed-off-by: Petr Štetiar
---
scripts/check-toolchain-clean.sh | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/scripts/check-toolchain-clean.sh b/scripts/check-toolchain-clean.sh
index 34b82dec5d22..455cfb0449f3 100755
--- a/scripts/check-toolchain-clean.sh
+++ b/scripts/check-toolchain-clean.sh
@@ -2,8 +2,13 @@
eval "$(grep CONFIG_GCC_VERSION .config)"
CONFIG_TOOLCHAIN_BUILD_VER="$CONFIG_GCC_VERSION-$(cat toolchain/build_version)"
touch .toolchain_build_ver
-[ "$CONFIG_TOOLCHAIN_BUILD_VER" = "$(cat .toolchain_build_ver)" ] && exit 0
-echo "Toolchain build version changed, running make targetclean"
+CURRENT_TOOLCHAIN_BUILD_VER="$(cat .toolchain_build_ver)"
+[ -z "$CURRENT_TOOLCHAIN_BUILD_VER" ] && {
+ echo "$CONFIG_TOOLCHAIN_BUILD_VER" > .toolchain_build_ver
+ exit 0
+}
+[ "$CONFIG_TOOLCHAIN_BUILD_VER" = "$CURRENT_TOOLCHAIN_BUILD_VER" ] && exit 0
+echo "Toolchain build version changed ($CONFIG_TOOLCHAIN_BUILD_VER !=
$CURRENT_TOOLCHAIN_BUILD_VER), running make targetclean"
make targetclean
echo "$CONFIG_TOOLCHAIN_BUILD_VER" > .toolchain_build_ver
exit 0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] check-toolchain-clean.sh: fix shellcheck warnings
Fixes following complaints and suggestions: In scripts/check-toolchain-clean.sh line 2: eval `grep CONFIG_GCC_VERSION .config` ^-- SC2046 (warning): Quote this to prevent word splitting. ^-- SC2006 (style): Use $(...) notation instead of legacy backticks `...`. Signed-off-by: Petr Štetiar --- scripts/check-toolchain-clean.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/check-toolchain-clean.sh b/scripts/check-toolchain-clean.sh index af24e740b7d4..34b82dec5d22 100755 --- a/scripts/check-toolchain-clean.sh +++ b/scripts/check-toolchain-clean.sh @@ -1,5 +1,5 @@ #!/bin/sh -eval `grep CONFIG_GCC_VERSION .config` +eval "$(grep CONFIG_GCC_VERSION .config)" CONFIG_TOOLCHAIN_BUILD_VER="$CONFIG_GCC_VERSION-$(cat toolchain/build_version)" touch .toolchain_build_ver [ "$CONFIG_TOOLCHAIN_BUILD_VER" = "$(cat .toolchain_build_ver)" ] && exit 0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.2 Second service release
Hi, The OpenWrt community is proud to announce the second service release of OpenWrt 21.02. It fixes security issues, improves device support, and brings a few bug fixes. We recently moved our bugs to GitHub, please report issues over there (after checking that nobody else posted the same issue before). Download firmware images via the Firmware Selector or directly from our download servers: • https://firmware-selector.openwrt.org • https://downloads.openwrt.org/releases/21.02.2/ Main changes from OpenWrt 21.02.1 Device support • Support for the following devices was added: • Xiaomi AIoT Router AC2350 • Linksys EA6300 & EA9200 • Netgear RAXE500 • TP-Link TL-WA1201 v2 • Minew G1-C: Allow dynamic RAM sizes • Fix U-Boot hang on lantiq danube-s v1.5 with MX29LV640EB NOR • TP-Link tl-mr3020-v3: Fix switch topology • Luxul XWR-3150 LAN: Fix ports numbering • WD MyBook Live DUO: Fix USB-Port • Turris Omnia: Use SFP module, if present • OpenMesh OM5P-AC v2: Fixed device tree Various fixes and improvements • Add new rpcapd package • chmod 1777 /var/lock to follow FHS 3.0 guideline • netifd: fix deletion of ip tunnels (FS#4058) • multiple mac80211 backports: • Add support Wifi 6 GHz band and HE options in scripts • mac80211: fix IBSS/adhoc mode for brcmfmac • Add ath10k smallbuffers Core components • Update Linux kernel from 5.4.154 to 5.4.179 • Update mac80211 from 5.10.68 to 5.10.85 • Update wolfssl from 4.8.1 to 5.1.1 • Update wireless-regdb from 2021.04.21 to 2021.08.28 • Update mt76 from 2021-06-06 to 2021-12-03 • Update busybox from 1.33.1 to 1.33.2 • Update intel-microcode from 20200616 to 20210608 • Update linux-firmware from 20201118 to 20211216 • Update openssl from 1.1.1l to 1.1.1m • Update mbedtls from 2.16.11 to 2.16.12 Regressions • Certificate validation fails in wolfssl against some sites especially sites using lets encrypt certificates. This affects for example wget in the default configuration #9283 Known issues • Some IPv6 packets are dropped when software flow offloading is used: https://bugs.openwrt.org/index.php?do=details_id=3373 • As a workaround, do not activate software flow offloading, it is deactivate by default. Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.2 1 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.2#known_issues 1 For a detailed list of all changes since 21.02.1, refer to https://openwrt.org/releases/21.02/changelog-21.02.2 To download the 21.02.2 images, navigate to: https://downloads.openwrt.org/releases/21.02.2/ To stay informed of new OpenWrt releases and security advisories, there are new channels available: • a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce • a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 • other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Sunshine! The OpenWrt Community ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
