Re: [PATCH 21.02] ipq806x: backport cpufreq changes to 5.4

2021-07-26 Thread Shane Synan 
[Since the mailing list didn't seem to pick up Ansuel's mobile reply,
I've reformatted here for easier future reference.]

On 7/20/21 8:36 PM EST, Ansuel Smith wrote:
> Sorry for the bad answer (I'm from phone)
> Anyway what you can try is tweak the OPP table and increase your CPU
> voltage...
> Don't know if it was related but some time ago I tested the router
> with overclock and strangely the router was more stable - 28 days of
> uptime while normally I have 3-4 days.
> My idea is some chip degradation or bad power supply and this cause
> crash.  Increasing the voltage seems to fix the problem.

Thank you!  In the upcoming weeks, I'll look into tinkering with the
voltage settings for the CPU in the OPP table.

With your advice in mind, I'm also suspecting it may be the combination
of CPU power draw and my USB 3.0 HDD's power drain (an old 1 TB Seagate
SRD00F1), as the latter is bus-powered rather than using an external
power supply.  I've acquired a digital USB test load and a USB 3.0
voltage/current meter is on the way (estimated arrival August 15th).
With any luck, I hope to reliably recreate the issue by running a
CPU-intensive task combined with a fixed current load to mimic the HDD
drawing from the NBG6817's USB 3.0 port, instead of the convoluted
Deja Dup SFTP backup test that I've been doing.

I'll also look at measuring the DC side of the power supply while it's
under load.  It might even be a combination of the bus-powered USB 3.0
HDD, chip degradation, and/or failing power supply.  I've had the
NBG6817 as my primary home router since November 2019 (bought new).

Again, thank you for your patience and time spent on this tricky issue!
I'll follow up if I uncover anything of interest, and I'll keep updating
folks in the OFTC/#openwrt-devel IRC channel too.

~ Shane

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: On a newer kernel, only the first port of a bridge is brought up

2021-07-26 Thread Nick 

Also on mt7621 Xiaomi Mi 3G v2.

On 7/26/21 8:42 PM, Chad Monroe wrote:

On Mon, Jul 26, 2021 at 10:14 AM Klaus Kudielka
 wrote:

  > I tried to run OpenWrt with a bleeding-edge net-next kernel (commit

0e804326759d), then noticed that only the first port of a bridge is
brought up automatically, the rest are down and not members of the
bridge.
i.e. with the following settings
network.@device  
[0]=device

  > network.@device  
[0].ports='lan1' 'lan2' 
'lan3' 'lan4'
  > network.@device  
[0].type='bridge'
  > network.@device  
[0].name='br-lan'


Only lan1 is in br-lan, and I have to manually configure the rest:

Exactly the same happens to me on Turris Omnia with master, either 5.4
OpenWrt kernel or 5.10 OpenWrt kernel.

I bisected this to "2801fe6132c4e2e364e2d5a304594185351b501b netifd:
update to the latest version".

And, I believe, Petr has noticed the same thing with 21.02.

Regards, Klaus


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

I ran into this on our mt7622 (mediatek) target as well.

It appears to be related to this netifd commit specifically:
https://git.openwrt.org/?p=project/netifd.git;a=commit;h=85f01c44a950be8518ce5a7d251b5bba219348cf

I’m not sure exactly where the issue is just yet but will take a look
and see if it’s something I can identify.

Thanks,
 -Chad

___
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: On a newer kernel, only the first port of a bridge is brought up

2021-07-26 Thread Chad Monroe 
On Mon, Jul 26, 2021 at 11:42 AM Chad Monroe  wrote:
>
> On Mon, Jul 26, 2021 at 10:14 AM Klaus Kudielka
>  wrote:
> >
> >  > I tried to run OpenWrt with a bleeding-edge net-next kernel (commit
> > > 0e804326759d), then noticed that only the first port of a bridge is
> > > brought up automatically, the rest are down and not members of the
> > > bridge.
> >
> > > i.e. with the following settings
> > > network.@device  
> > > [0]=device
> >  > network.@device  
> > [0].ports='lan1' 
> > 'lan2' 'lan3' 'lan4'
> >  > network.@device  
> > [0].type='bridge'
> >  > network.@device  
> > [0].name='br-lan'
> >
> > > Only lan1 is in br-lan, and I have to manually configure the rest:
> >
> > Exactly the same happens to me on Turris Omnia with master, either 5.4
> > OpenWrt kernel or 5.10 OpenWrt kernel.
> >
> > I bisected this to "2801fe6132c4e2e364e2d5a304594185351b501b netifd:
> > update to the latest version".
> >
> > And, I believe, Petr has noticed the same thing with 21.02.
> >
> > Regards, Klaus
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> I ran into this on our mt7622 (mediatek) target as well.
>
> It appears to be related to this netifd commit specifically:
> https://git.openwrt.org/?p=project/netifd.git;a=commit;h=85f01c44a950be8518ce5a7d251b5bba219348cf
>
> I’m not sure exactly where the issue is just yet but will take a look
> and see if it’s something I can identify.
>
> Thanks,
> -Chad

Ahh, I am too slow. It looks like Felix fixed this just now. Thanks!

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 21.02] Revert "netifd: update to the latest version"

2021-07-26 Thread Felix Fietkau 
On 2021-07-26 17:09, Petr Štetiar wrote:
> Petr Štetiar  [2021-07-26 17:01:32]:
> 
>> This reverts commit 089efd61e9a6cdc0ea39c184d37bc8ebbe03175c as it
>> breaks LAN network on at least mvebu/turris-omnia device.
>> 
>> Confirmed-by: Josef Schlehofer 
>> Signed-off-by: Petr Štetiar 
>> ---
>> 
>> I've discovered this today in the morning in my testbed where I perform daily
>> runtime tests of initramfs images on several devices, where images/tests for
>> snapshot and 21.02-SNAPSHOT failed on turris-omnia device.
> 
> Sorry, forgot to provide more detials. The problem is with initialization of
> LAN network, where the interface readiness is tested by following command:
> 
>  ifstatus lan | jsonfilter -qe "@.up"
> 
> then the LAN network availability is tested with simple `ping -c1 192.168.1.2`
> command which timeouts. This is pristine image with no config changes, so the
> device has 192.168.1.1/24 network config and the other end 192.168.1.2/24.
> 
> Console logs are available:
> 
>  snapshot 
> https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/1451323563/artifacts/file/console_turris-omnia-initramfs.txt
>  21.02
> https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/1451222403/artifacts/file/console_turris-omnia-initramfs.txt
Fixed the regression in master and 21.02, sorry about the mess.
For some reason, it did not trigger in my configurations...

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: On a newer kernel, only the first port of a bridge is brought up

2021-07-26 Thread Chad Monroe 
On Mon, Jul 26, 2021 at 10:14 AM Klaus Kudielka
 wrote:
>
>  > I tried to run OpenWrt with a bleeding-edge net-next kernel (commit
> > 0e804326759d), then noticed that only the first port of a bridge is
> > brought up automatically, the rest are down and not members of the
> > bridge.
>
> > i.e. with the following settings
> > network.@device  
> > [0]=device
>  > network.@device  
> [0].ports='lan1' 
> 'lan2' 'lan3' 'lan4'
>  > network.@device  
> [0].type='bridge'
>  > network.@device  
> [0].name='br-lan'
>
> > Only lan1 is in br-lan, and I have to manually configure the rest:
>
> Exactly the same happens to me on Turris Omnia with master, either 5.4
> OpenWrt kernel or 5.10 OpenWrt kernel.
>
> I bisected this to "2801fe6132c4e2e364e2d5a304594185351b501b netifd:
> update to the latest version".
>
> And, I believe, Petr has noticed the same thing with 21.02.
>
> Regards, Klaus
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

I ran into this on our mt7622 (mediatek) target as well.

It appears to be related to this netifd commit specifically:
https://git.openwrt.org/?p=project/netifd.git;a=commit;h=85f01c44a950be8518ce5a7d251b5bba219348cf

I’m not sure exactly where the issue is just yet but will take a look
and see if it’s something I can identify.

Thanks,
-Chad

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: On a newer kernel, only the first port of a bridge is brought up

2021-07-26 Thread Klaus Kudielka 

> I tried to run OpenWrt with a bleeding-edge net-next kernel (commit

0e804326759d), then noticed that only the first port of a bridge is
brought up automatically, the rest are down and not members of the
bridge.



i.e. with the following settings
network.@device  
[0]=device

> network.@device  
[0].ports='lan1' 'lan2' 
'lan3' 'lan4'
> network.@device  
[0].type='bridge'
> network.@device  
[0].name='br-lan'


Only lan1 is in br-lan, and I have to manually configure the rest:


Exactly the same happens to me on Turris Omnia with master, either 5.4 
OpenWrt kernel or 5.10 OpenWrt kernel.


I bisected this to "2801fe6132c4e2e364e2d5a304594185351b501b netifd: 
update to the latest version".


And, I believe, Petr has noticed the same thing with 21.02.

Regards, Klaus


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 21.02] Revert "netifd: update to the latest version"

2021-07-26 Thread Petr Štetiar 
Petr Štetiar  [2021-07-26 17:01:32]:

> This reverts commit 089efd61e9a6cdc0ea39c184d37bc8ebbe03175c as it
> breaks LAN network on at least mvebu/turris-omnia device.
> 
> Confirmed-by: Josef Schlehofer 
> Signed-off-by: Petr Štetiar 
> ---
> 
> I've discovered this today in the morning in my testbed where I perform daily
> runtime tests of initramfs images on several devices, where images/tests for
> snapshot and 21.02-SNAPSHOT failed on turris-omnia device.

Sorry, forgot to provide more detials. The problem is with initialization of
LAN network, where the interface readiness is tested by following command:

 ifstatus lan | jsonfilter -qe "@.up"

then the LAN network availability is tested with simple `ping -c1 192.168.1.2`
command which timeouts. This is pristine image with no config changes, so the
device has 192.168.1.1/24 network config and the other end 192.168.1.2/24.

Console logs are available:

 snapshot 
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/1451323563/artifacts/file/console_turris-omnia-initramfs.txt
 21.02
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/1451222403/artifacts/file/console_turris-omnia-initramfs.txt

> 1. 
> https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/pipelines/342708318
> 
>  package/network/config/netifd/Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/package/network/config/netifd/Makefile 
> b/package/network/config/netifd/Makefile
> index 35035519f95f..f80f07a4ff3a 100644
> --- a/package/network/config/netifd/Makefile
> +++ b/package/network/config/netifd/Makefile
> @@ -5,9 +5,9 @@ PKG_RELEASE:=1
>  
>  PKG_SOURCE_PROTO:=git
>  PKG_SOURCE_URL=$(PROJECT_GIT)/project/netifd.git
> -PKG_SOURCE_DATE:=2021-07-23
> -PKG_SOURCE_VERSION:=17e453bd68b41780b6564dafa8358efc29a00930
> -PKG_MIRROR_HASH:=06b6e10a71e3002fa03579846b97af29be9503d61486486c639dbfae423b398f
> +PKG_SOURCE_DATE:=2021-07-14
> +PKG_SOURCE_VERSION:=7f24a063475e1e2be4e0c516a5b62c3fae5ec542
> +PKG_MIRROR_HASH:=3fad25b8655e01e20f54b6c6decad6a660a34ab3ca2de97fe3c9b7db5aa485fe
>  PKG_MAINTAINER:=Felix Fietkau 
>  
>  PKG_LICENSE:=GPL-2.0
> 

-- 
ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 21.02] Revert "netifd: update to the latest version"

2021-07-26 Thread Petr Štetiar 
This reverts commit 089efd61e9a6cdc0ea39c184d37bc8ebbe03175c as it
breaks LAN network on at least mvebu/turris-omnia device.

Confirmed-by: Josef Schlehofer 
Signed-off-by: Petr Štetiar 
---

I've discovered this today in the morning in my testbed where I perform daily
runtime tests of initramfs images on several devices, where images/tests for
snapshot and 21.02-SNAPSHOT failed on turris-omnia device.

1. https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/pipelines/342708318

 package/network/config/netifd/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/network/config/netifd/Makefile 
b/package/network/config/netifd/Makefile
index 35035519f95f..f80f07a4ff3a 100644
--- a/package/network/config/netifd/Makefile
+++ b/package/network/config/netifd/Makefile
@@ -5,9 +5,9 @@ PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=$(PROJECT_GIT)/project/netifd.git
-PKG_SOURCE_DATE:=2021-07-23
-PKG_SOURCE_VERSION:=17e453bd68b41780b6564dafa8358efc29a00930
-PKG_MIRROR_HASH:=06b6e10a71e3002fa03579846b97af29be9503d61486486c639dbfae423b398f
+PKG_SOURCE_DATE:=2021-07-14
+PKG_SOURCE_VERSION:=7f24a063475e1e2be4e0c516a5b62c3fae5ec542
+PKG_MIRROR_HASH:=3fad25b8655e01e20f54b6c6decad6a660a34ab3ca2de97fe3c9b7db5aa485fe
 PKG_MAINTAINER:=Felix Fietkau 
 
 PKG_LICENSE:=GPL-2.0

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

On a newer kernel, only the first port of a bridge is brought up

2021-07-26 Thread DENG Qingfang 
I tried to run OpenWrt with a bleeding-edge net-next kernel (commit
0e804326759d), then noticed that only the first port of a bridge is
brought up automatically, the rest are down and not members of the
bridge.

i.e. with the following settings
network.@device[0]=device
network.@device[0].ports='lan1' 'lan2' 'lan3' 'lan4'
network.@device[0].type='bridge'
network.@device[0].name='br-lan'

Only lan1 is in br-lan, and I have to manually configure the rest:
> ip link set lan2 up master br-lan
...

If I change the "ports" value to "'lan4' 'lan3' 'lan2' 'lan1'", only
lan4 is brought up.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel