Re: Paid support for MT7621 WAN port bugs in 21.02 HEAD/MASTER
Actually in this case the problems seem to be in the new wired ethernet drivers using the linux DSA infrastructure (mtk_soc_eth.c and mt7530.c) are causing the issues. I have had no luck narrowing down either fault as every avenue i have explored has lead to a dead end so far. One of the fault test cases i found the watchdog timeout was more reliably triggered by using wifi -> wan traffic, but i don't believe the problem is the wifi (mt76) driver, because the timeout is caused by mtk_soc_eth.c blocking. The old drivers in the v4.xx kernels worked fine in this regard, so its something to do with the new DSA drivers. The odd thing is Lan1-Lan4 use the same drivers, but do no exhibit the issue, its constrained to the WAN interface. Steven. On 4/5/21 10:35 pm, Fernando Frediani wrote: > That's a great initiative. Well done. > > Regards mt76 driver if I am not wrong MediaTek had sponsored someone > from the community a while ago to develop it, but I guess that is not > the case anymore. > If after this offer someone can take it again that would be great. > These 2 bugs are not the only ones that needs fixing int mt76 > > Regards > Fernando > > On 04/05/2021 00:56, Strontium wrote: >> The company I work for is interested in contracting/sponsoring a >> knowledgeable developer to resolve the following bug reports in OpenWrt >> 21.02: >> >> https://bugs.openwrt.org/index.php?do=details_id=3760 >> https://bugs.openwrt.org/index.php?do=details_id=3762 >> >> These problems will negatively effect the entire OpenWrt community of >> users with MT7621 based devices if they are not addressed before OpenWrt >> 21.02 is formally released, so we would like to see them addressed for >> everyone's benefit. >> >> If you are interested in helping us, please contact me directly and we >> can discuss the details. >> >> Steven >> >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] mac80211: use auto channel list by default
Hi David, On 5/3/21 1:14 AM, David Bauer wrote: Hi Hauke, On 5/3/21 12:23 AM, Hauke Mehrtens wrote: This change removes setting the channels property by default to the channel property if nothing else is specified. When hostapd detects a DFS alarm and it has to switch channels allow hostapd to switch to any channel in the frequency band if channels property is not specified. This was exactly the behavior I've tried to fix. My expectation when configuring a specific channel would be, that the radio does not switch to an arbitrary channel when it is forced to do DFS. Especially as DFS channels are required to be used when the AP is used Outdoors (At least in Germany / ETSI). When dynamic channel usage is desired, I'd expect the user to provide a chanlist or use the "auto" channel. Maybe this is something which is is flexible in how it can be interpreted, so I'm open to find an alternative solution for that. ;) I assumed that this was intentional. ;-) I was not aware of chanlist until recently, should we add this to the default configuration to promote it more? If the interface is just off for an hour and comes back this should be fine. Should we set the default 5GHz channel to auto? When we set channels to the same channel as the channel variable it will not switch channel, the interface will be deactivated and hostapd writes this error message: Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: DFS-NOP-FINISHED freq=5640 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5640 cf2=0 Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: interface state DFS->DFS Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: DFS-CAC-START freq=5580 chan=116 sec_chan=1, width=0, seg0=122, seg1=0, cac_time=60s Wed Feb 10 17:24:48 2021 daemon.err hostapd: 20/40 MHz: center segment 0 (=122) and center freq 1 (=5590) not in sync Wed Feb 10 17:24:48 2021 daemon.err hostapd: Can't set freq params Wed Feb 10 17:24:48 2021 daemon.err hostapd: DFS start_dfs_cac() failed, -1 Can you share your radio settings? I've tested this back when the patch was applied and the radio reappeared after the NOP period. I used these settings: config wifi-device 'radio1' option type 'mac80211' option channel '120' option hwmode '11a' option path '1e14.pcie/pci:00/:00:01.0/:02:00.0' option htmode 'VHT80' option country 'DE' config wifi-iface 'default_radio1' option device 'radio1' option network 'lan' option mode 'ap' option ssid 'mywifi' option encryption 'sae-mixed' option key 'mykeykey' - on a Xiaomi Mi Router 3G (MT76x2E) I think hostapd tries to switch from 80MHz channel size to 40MHz to try to avoid DFS. When I debugged this further it looked like this switch is not fully working, it ends up in a mix of 80MHz and 40MHz settings and the validation fails. I am also seeing this with hostapd from April 2021. Did anyone ever ran the hostapd test suite? I would like to reproduce this problem there. I think there is a test case for this scenario already, but it could be that it needs some tweaks. Can I trigger DFS events intentional to trigger this code in hostapd? I do not want to wait 3 days till this happens. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Paid support for MT7621 WAN port bugs in 21.02 HEAD/MASTER
That's a great initiative. Well done. Regards mt76 driver if I am not wrong MediaTek had sponsored someone from the community a while ago to develop it, but I guess that is not the case anymore. If after this offer someone can take it again that would be great. These 2 bugs are not the only ones that needs fixing int mt76 Regards Fernando On 04/05/2021 00:56, Strontium wrote: The company I work for is interested in contracting/sponsoring a knowledgeable developer to resolve the following bug reports in OpenWrt 21.02: https://bugs.openwrt.org/index.php?do=details_id=3760 https://bugs.openwrt.org/index.php?do=details_id=3762 These problems will negatively effect the entire OpenWrt community of users with MT7621 based devices if they are not addressed before OpenWrt 21.02 is formally released, so we would like to see them addressed for everyone's benefit. If you are interested in helping us, please contact me directly and we can discuss the details. Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] added support for comfast jw-ew74
From: eric
---
.../ramips/dts/mt7628an_comfast_jw-ew74.dts | 147 ++
target/linux/ramips/image/mt76x8.mk | 9 ++
.../mt76x8/base-files/etc/board.d/01_leds | 7 +
.../mt76x8/base-files/etc/board.d/02_network | 4 +
4 files changed, 167 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7628an_comfast_jw-ew74.dts
diff --git a/target/linux/ramips/dts/mt7628an_comfast_jw-ew74.dts
b/target/linux/ramips/dts/mt7628an_comfast_jw-ew74.dts
new file mode 100644
index 00..dc6aaeb4fe
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_comfast_jw-ew74.dts
@@ -0,0 +1,147 @@
+/dts-v1/;
+
+#include "mt7628an.dtsi"
+
+#include
+#include
+
+/ {
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "comfast,jw-ew74\0mediatek,mt7628an-soc";
+ model = "Comfast JW-EW74";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+
+
+ gpio-keys-polled {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ compatible = "gpio-keys-polled";
+ poll-interval = <0x14>;
+
+ reset {
+ gpios = < 0x06 0x01>;
+ label = "reset";
+ linux,code = ;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ wifi {
+ gpios = < 0x0c 0x01>;
+ label = "comfast:blue:wifi";
+ };
+
+ wifi0 {
+ gpios = < 0x0b 0x01>;
+ label = "comfast:blue:wifi0";
+ };
+
+ wifi1 {
+ gpios = < 0x05 0x01>;
+ label = "comfast:blue:wifi1";
+ };
+
+ wifi2 {
+ gpios = < 0x0d 0x01>;
+ label = "comfast:blue:wifi2";
+ };
+ };
+
+};
+
+
+
+
+
+ {
+status = "okay";
+
+flash@0 {
+compatible = "jedec,spi-nor";
+reg = <0>;
+spi-max-frequency = <1000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+
+ partition@0 {
+ label = "u-boot";
+ read-only;
+ reg = <0x00 0x3>;
+ };
+
+
+ partition@3 {
+ label = "u-boot-env";
+ read-only;
+ reg = <0x3 0x1>;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ read-only;
+ reg = <0x4 0x1>;
+ };
+
+ partition@5 {
+ compatible = "denx,uimage";
+ label = "firmware";
+ reg = <0x5 0x77>;
+ };
+
+ partition@7c {
+ label = "configs";
+ reg = <0x7c 0x4>;
+ };
+ partition@100 {
+label = "reserve";
+reg = <0x100 0x100>;
+};
+
+ };
+ };
+};
+
+ {
+ mtd-mac-address = < 0xe00 >;
+};
+
+
+ {
+
+ status = "okay";
+ mtd-mac-address = < 0xe00>;
+ mtd-mac-address-increment = <1>;
+
+};
+
+
+ {
+ status = "okay";
+};
+
+
+ {
+wifi: mt76@0,0 {
+reg = <0x 0 0 0 0>;
+ mediatek,5ghz = <0x00>;
+mediatek,mtd-eeprom = < 0x8000>;
+ ieee80211-freq-limit = <500 600>;
+ mtd-mac-address = < 0xe00>;
+ mtd-mac-address-increment = <2>;
+
+};
+};
+ {
+ status = "okay";
+};
diff --git a/target/linux/ramips/image/mt76x8.mk
b/target/linux/ramips/image/mt76x8.mk
index d5a9684dba..35402edc3b 100644
--- a/target/linux/ramips/image/mt76x8.mk
+++ b/target/linux/ramips/image/mt76x8.mk
@@ -78,6 +78,15 @@ define Device/buffalo_wcr-1166ds
endef
TARGET_DEVICES += buffalo_wcr-1166ds
+define Device/comfast_jw-ew74
+ IMAGE_SIZE := 7798784
+ DEVICE_VENDOR := Comfast
+ DEVICE_MODEL := JW-EW74
+ DEVICE_PACKAGES := kmod-mt76x2
+ SUPPORTED_DEVICES += comfast_jw-ew74
+endef
+TARGET_DEVICES += comfast_jw-ew74
+
define Device/cudy_wr1000
IMAGE_SIZE := 7872k
IMAGES += factory.bin
diff --git
[PATCH] fstools: block: fix segfault on mount with no target
When a UCI fstab mount config doesn't contain a target option,
a 'block mount' call segfaults when comparing a mount's target (NULL)
to a found mount point returned by find_mount_point()
Signed-off-by: Daniel Danzberger
---
block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b/block.c
index f094216..c6d93d1 100644
--- a/block.c
+++ b/block.c
@@ -1021,7 +1021,7 @@ static int mount_device(struct probe_info *pr, int type)
mp = find_mount_point(pr->dev);
if (mp) {
- if (m && m->type == TYPE_MOUNT && strcmp(m->target, mp)) {
+ if (m && m->type == TYPE_MOUNT && m->target &&
strcmp(m->target, mp)) {
ULOG_ERR("%s is already mounted on %s\n", pr->dev, mp);
err = -1;
} else
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[openwrt] Patch notification: 1 patch updated
Hello, The following patch (submitted by you) has been updated in Patchwork: * openwrt: Fix URL validation for more than one URLs. - http://patchwork.ozlabs.org/project/openwrt/patch/mailman.1440.1619955388.1230.openwrt-de...@lists.openwrt.org/ - for: OpenWrt development was: New now: Changes Requested This email is a notification only - you do not need to respond. Happy patchworking. -- This is an automated mail sent by the Patchwork system at patchwork.ozlabs.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.ozlabs.org/mail/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core
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 --- Friendly ping. Bas. On 2021-04-29 22:39, Bas Mevissen wrote: On 4/29/21 11:40 AM, Paul Spooren wrote: On 4/20/21 1:08 AM, Bas Mevissen wrote: OpenWRT requires a number of Perl modules to be installed. It wasn't checking on all of them. This patch adds checks for Perl FindBin, File::Copy, File::Compare and Thread::Queue modules. Failing to install these, will have the build break at some point. By adding these to the prereq-build.mk script, they are checked on forehand. Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears to break up Perl modules into small packages that need to be installed for the build to succeed. Signed-off-by: Bas Mevissen --- include/prereq-build.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 86c22f7c95..cb3dcc51e3 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \ Please install the Perl Data::Dumper module, \ perl -MData::Dumper -e 1)) +$(eval $(call TestHostCommand,perl-findbin, \ + Please install the Perl FindBin module, \ + perl -MFindBin -e 1)) + +$(eval $(call TestHostCommand,perl-file-copy, \ + Please install the Perl File::Copy module, \ + perl -MFile::Copy -e 1)) + +$(eval $(call TestHostCommand,perl-file-compare, \ + Please install the Perl File::Compare module, \ + perl -MFile::Compare -e 1)) Could you please point me to where this module is required? I naively grepped through openwrt.git and couldn't find it. The other added requirements seem fine. It is in the host autoconf build. On Fedora 34, against current master, without the patch to test the need for File::Compare: $ sudo rpm -e perl-File-Compare (...) $ make -j1 V=s (...) make[3]: Entering directory '/home/bas/Workspace/openwrt-master/tools/autoconf' export SHELL="bash"; make -C /home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69 make[4]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' make all-recursive make[5]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69' Making all in bin make[6]: Entering directory '/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69/bin' autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache '' --melt ./autoconf.as -o autoconf.in Can't locate File/Compare.pm in @INC (you may need to install the File::Compare module) (@INC contains: ../lib /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ../lib/Autom4te/FileUtils.pm line 166. BEGIN failed--compilation aborted at ../lib/Autom4te/FileUtils.pm line 166. Compilation failed in require at ../bin/autom4te line 43. BEGIN failed--compilation aborted at ../bin/autom4te line 43. make[6]: *** [Makefile:641: autoconf.in] Error 2 (...) $ sudo dnf install -y perl-File-Compare (...) $ make -j4 (build finishes) + $(eval $(call TestHostCommand,perl-thread-queue, \ Please install the Perl Thread::Queue module, \ perl -MThread::Queue -e 1)) - $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \ gtar --version 2>&1 | grep GNU, \ gnutar --version 2>&1 | grep GNU, \ --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] tplink-safeloader: fix product_name of TP-Link AD7200
Alex Henrie [2021-05-03 21:07:17]:
Hi,
> The stock firmware does not accept firmware with "Talon" in the name.
can you provide information about your stock firmware? Something others could
be able to reproduce, for example:
Tested on latest firmware version 1.1.2 Build 20210125 rel.37999 flashed from
c7v5_us-up-ver1-1-2-P1[20210125-rel37999]_2021-01-25_10.33.55.bin filename.
No need to send v3, just send this information as a reply to this email,
thanks.
> Fixes: 1a775a4fd033 ("ipq806x: add support for TP-Link Talon AD7200")
> Signed-off-by: Alex Henrie
> ---
> tools/firmware-utils/src/tplink-safeloader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/firmware-utils/src/tplink-safeloader.c
> b/tools/firmware-utils/src/tplink-safeloader.c
> index b3d5c9151d..8a47e6a58f 100644
> --- a/tools/firmware-utils/src/tplink-safeloader.c
> +++ b/tools/firmware-utils/src/tplink-safeloader.c
> @@ -676,7 +676,7 @@ static struct device_info boards[] = {
> .vendor = "",
> .support_list =
> "SupportList:\r\n"
> - "{product_name:Talon
> AD7200,product_ver:1.0.0,special_id:}\r\n",
> +
> "{product_name:AD7200,product_ver:1.0.0,special_id:}\r\n",
> .part_trail = 0x00,
> .soft_ver = NULL,
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Patches to enable DPDK and Pktgen for ipq40xx device
Hi Maintainers, We want to enable DPDK and Pktgen support for the ipq40xx device (WPJ419 platform) in the OpenWRT build system. We have tested DPDK/Pktgen for the ipq40xx platform using OpenWRT 19.07 stable release. We are ready with our changes to contribute to the OpenWRT community. Kindly let us know the process involved and the version which we shall contribute to, also kindly provide the dates planned for the next release. Regards, Supriya Mane -- Disclaimer:This message is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to other confidentiality protections. If you are not a designated recipient, you may not review, copy or distribute this message. Please notify the sender by e-mail and delete this message. GlobalEdge does not accept any liability for virus infected mails. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
