Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
Hi John, Thank you very much. But I still feel it's strange the crash didn't happen if used brctl to configure instead of /etc/config/network. Much memory(about 700MB) was consumed in UDP throughput test only when used /etc/config/network. As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe ethernet driver had this issue. I think maybe I should focus on deep studying in /etc/config/network. But we had a deadline by this month to resolve it. Is there any possibility the issue was caused by OpenWrt? Thanks again. Best regards, Yangbo Lu > -Original Message- > From: John Crispin [mailto:j...@phrozen.org] > Sent: Monday, April 24, 2017 12:31 PM > To: Y.B. Lu; lede-dev@lists.infradead.org; j...@mein.io > Cc: Wes Li; Xiaobo Xie > Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if > configured bridge mode in /etc/config/network > > Hi, > > this is most certainly a bug in the kernel. either the ethernet driver > blows up under load or some other memory allocation related bug. it is > very common for ethernet to kill boards under load by triggering bugs. > > John > > On 24/04/17 05:49, Y.B. Lu wrote: > > Hi John and Jo-Philipp, > > > > Have you ever got similar problem, or known any possible reason about > > this, or known anyone who probably know this? > > > > I just found much memory would be consumed if I configured board as > > bridge mode in /etc/config/network and did UDP throughput test. > > But using brctl to configure bridge mode didn't consume memory. > > > > Thank you very much. > > > > > > Best regards, > > Yangbo Lu > > > > > >> -Original Message- > >> From: Y.B. Lu > >> Sent: Thursday, April 13, 2017 1:24 PM > >> To: 'lede-dev@lists.infradead.org' > >> Subject: UDP throughput caused kernel panic if configured bridge mode > >> in /etc/config/network > >> > >> Hi all, > >> > >> Recently I got below kernel panic when did UDP throughput test on NXP > >> LS1043ARDB board. I configured the bridge mode in /etc/config/network. > >> But if I used 'brctl' to configure the bridge mode, this issue would > >> not happen. > >> I also noticed almost all memory was consumed(about 700MB) when > >> kernel crashed. > >> Anyone have any idea about this? Thank you very much. > >> > >> root@LEDE:/etc/fmc/config# [ 263.981540] ksoftirqd/3: page > >> allocation > >> failure: order:0, mode:0x2080020 [ 263.988339] CPU: 3 PID: 19 Comm: > >> ksoftirqd/3 Not tainted 4.4.52 #0 [ 263.994508] Hardware name: > >> Freescale LS1043A [ 263.998767] Backtrace: > >> [ 264.001213] [] (dump_backtrace) from [] > >> (show_stack+0x18/0x1c) [ 264.008771] r7: r6: > >> r5:6013 r4: [ 264.014435] [] (show_stack) from > >> [] (dump_stack+0x84/0xa4) [ 264.021652] [] > >> (dump_stack) from [] (warn_alloc_failed+0xf0/0x114) [ > >> 264.029558] r5:02080020 r4: [ 264.033133] [] > >> (warn_alloc_failed) from [] > >> (__alloc_pages_nodemask+0x68c/0x6c0) > >> [ 264.042166] r3: r2: [ 264.045735] r7:0030 > >> r6:02080020 r5: r4:02080020 [ 264.051400] [] > >> (__alloc_pages_nodemask) from [] > >> (_dpa_bp_add_8_bufs+0x40/0x250) [ 264.060434] r10:c001db08 > >> r9:ebc93d48 > >> r8:ebf61650 r7:0003 r6:0004 r5:eb603c10 [ 264.068266] > >> r4:8193f040 [ 264.070796] [] (_dpa_bp_add_8_bufs) from > >> [] (dpaa_eth_refill_bpools+0x28/0x58) > >> [ 264.079742] r10:eb09d480 r9:eb604a74 r8:ef1d9400 r7:eb09d000 > >> r6:ebf61650 r5:ef1e0b44 [ 264.087577] r4:007f [ 264.090106] > >> [] (dpaa_eth_refill_bpools) from [] > >> (priv_rx_default_dqrr+0xd8/0x124) [ 264.099313] r7:eb09d000 > >> r6:ebf61650 > >> r5:ef1e0b44 r4:ef1e15e0 > >> > >> The /etc/config/network for bridge mode as below. > >> config interface 'lan' > >> option type 'bridge' > >> option ifname 'eth2 eth6' > >> option proto 'static' > >> option ipaddr '192.168.1.1' > >> option netmask '255.255.255.0' > >> option ip6assign '60' > >> > >> brctl manual config as below. > >> ifconfig eth2 up > >> ifconfig eth6 up > >> brctl addif br-lan eth6 > >> brctl addif br-lan eth2 > >> > >> > >> > >> best regards, > >> Yangbo Lu > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] asterisk-13.x: Add func_periodic_hook module
On 20/04/17 15:37, Roman Spychała wrote: From: Roman Spychała Signed-off-by: Roman Spychała --- net/asterisk-13.x/Makefile | 1 + 1 file changed, 1 insertion(+) Hi Roman, asterisk is part of the packaged feed on github. please send the patch as a PR there. John diff --git a/net/asterisk-13.x/Makefile b/net/asterisk-13.x/Makefile index b2d1275..0722098 100644 --- a/net/asterisk-13.x/Makefile +++ b/net/asterisk-13.x/Makefile @@ -380,6 +380,7 @@ $(eval $(call BuildAsterisk13Module,func-global,Global variable,global variable $(eval $(call BuildAsterisk13Module,func-groupcount,Group count,for counting number of channels in the specified group,,,func_groupcount,,)) $(eval $(call BuildAsterisk13Module,func-math,Math functions,Math functions,,,func_math,)) $(eval $(call BuildAsterisk13Module,func-module,Simple module check function,Simple module check function,,,func_module,)) +$(eval $(call BuildAsterisk13Module,func-periodic-hook,Periodic dialplan hooks,Execute a periodic dialplan hook into the audio of a call,,,func_periodic_hook,,)) $(eval $(call BuildAsterisk13Module,func-presencestate,Hinted presence state,Gets or sets a presence state in the dialplan,,,func_presencestate,,)) $(eval $(call BuildAsterisk13Module,func-realtime,realtime,the realtime dialplan function,,,func_realtime,,)) $(eval $(call BuildAsterisk13Module,func-shell,Shell,support for shell execution,,,func_shell,,)) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] asterisk-13.x: Add func_periodic_hook module
On 04/24/2017 09:43 AM, John Crispin wrote: > > > On 20/04/17 15:37, Roman Spychała wrote: >> From: Roman Spychała >> >> Signed-off-by: Roman Spychała >> --- >> net/asterisk-13.x/Makefile | 1 + >> 1 file changed, 1 insertion(+) > > Hi Roman, > > asterisk is part of the packaged feed on github. please send the patch > as a PR there. > > John > > Telephony feed, this is the github https://github.com/openwrt/telephony -Alberto >> >> diff --git a/net/asterisk-13.x/Makefile b/net/asterisk-13.x/Makefile >> index b2d1275..0722098 100644 >> --- a/net/asterisk-13.x/Makefile >> +++ b/net/asterisk-13.x/Makefile >> @@ -380,6 +380,7 @@ $(eval $(call >> BuildAsterisk13Module,func-global,Global variable,global variable >> $(eval $(call BuildAsterisk13Module,func-groupcount,Group count,for >> counting number of channels in the specified group,,,func_groupcount,,)) >> $(eval $(call BuildAsterisk13Module,func-math,Math functions,Math >> functions,,,func_math,)) >> $(eval $(call BuildAsterisk13Module,func-module,Simple module check >> function,Simple module check function,,,func_module,)) >> +$(eval $(call BuildAsterisk13Module,func-periodic-hook,Periodic >> dialplan hooks,Execute a periodic dialplan hook into the audio of a >> call,,,func_periodic_hook,,)) >> $(eval $(call BuildAsterisk13Module,func-presencestate,Hinted >> presence state,Gets or sets a presence state in the >> dialplan,,,func_presencestate,,)) >> $(eval $(call BuildAsterisk13Module,func-realtime,realtime,the >> realtime dialplan function,,,func_realtime,,)) >> $(eval $(call BuildAsterisk13Module,func-shell,Shell,support for >> shell execution,,,func_shell,,)) > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
On 24 April 2017 at 15:39, Y.B. Lu wrote: > Hi John, > > Thank you very much. > > But I still feel it's strange the crash didn't happen if used brctl to > configure instead of /etc/config/network. > Much memory(about 700MB) was consumed in UDP throughput test only when used > /etc/config/network. > > As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe > ethernet driver had this issue. > I think maybe I should focus on deep studying in /etc/config/network. But we > had a deadline by this month to resolve it. > > Is there any possibility the issue was caused by OpenWrt? > Thanks again. > Most parts of /etc/config/network will be parsed and executed by netifd. Comparing strace output of both brctl and netifd may reveal something useful. The kernel is supposed to be resilient against whatever ways applications may use its exposed userspace interface which is driver and device-agnostic. If the driver fails, there is very likely an issue within the driver itself. yousong ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 13/13] x86: sysupgrade: explicitly rescan disk after writing partition table
Hi, > While we're at it, also remove the ask_bool that can't work anymore with > staged sysupgrade. We should find an alternative solution though; like some new flag "--proceed-even-if-partition-table-changed" to avoid accidentally killing user partitions. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 13/13] x86: sysupgrade: explicitly rescan disk after writing partition table
On 04/24/2017 12:19 PM, Jo-Philipp Wich wrote: > Hi, > >> While we're at it, also remove the ask_bool that can't work anymore with >> staged sysupgrade. > > We should find an alternative solution though; like some new flag > "--proceed-even-if-partition-table-changed" to avoid accidentally > killing user partitions. > > ~ Jo Well, it only had an effect in interactive mode anyways, which I didn't even know before this weekend of working on sysupgrade. I think we can just move the check to platform_check_image. Matthias signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] early printk breaks kernel on the clearfog board
Am Montag, 24. April 2017, 02:37:48 CEST schrieb Syrone Wong: > You may want to enable CONFIG_DEBUG_MVEBU_UART0_ALTERNATE Yes, this is the one. But it is not visible from the Lede menuconfig. The problem I was trying to point out is that in the kernel-config this is what should be selected when selecting early-printk in the Lede menuconfig. > or CONFIG_DEBUG_MVEBU_UART1_ALTERNATE if early printk is being enabled. > > > Best Regards, > Syrone Wong > > On Mon, Apr 24, 2017 at 3:39 AM, Josua Mayer wrote: > > Hi everybody, > > > > I noticed a serious problem with a Clearfog build that enables > > CONFIG_KERNEL_EARLY_PRINTK=y. > > In short: after Loading Kernel, the serial console stays completely > > silent, and apparently the board does *not* boot. > > > > This came as a serious surprise to me. > > Turns out the reason for this is the usage of the old uart physical > > address: CONFIG_DEBUG_UART_PHYS=0xd0012000 > > This is the default for if DEBUG_MVEBU_UART0 > > However the Clearfog Pro uses mainline u-boot, and requires: > > CONFIG_DEBUG_UART_PHYS=0xf1012000 > > > > Any opinions what should be done about this? > > I personally suggest to switch to what the kernel config calls "new > > bootloaders". > > After all this is quite the trap when somebody is so thoughtful to start > > with a debug build, only to find out that is the reason his builds don't > > boot. > > > > Imre Kaloz: you are the one who committed this setting with config-4.4, > > so I figured you may have some valuable insight here. > > > > br > > Josua Mayer > > > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
On 04/24/2017 12:39 AM, Y.B. Lu wrote: Hi John, Thank you very much. But I still feel it's strange the crash didn't happen if used brctl to configure instead of /etc/config/network. Much memory(about 700MB) was consumed in UDP throughput test only when used /etc/config/network. As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe ethernet driver had this issue. I think maybe I should focus on deep studying in /etc/config/network. But we had a deadline by this month to resolve it. Is there any possibility the issue was caused by OpenWrt? Thanks again. Best regards, Yangbo Lu -Original Message- From: John Crispin [mailto:j...@phrozen.org] Sent: Monday, April 24, 2017 12:31 PM To: Y.B. Lu; lede-dev@lists.infradead.org; j...@mein.io Cc: Wes Li; Xiaobo Xie Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network Hi, this is most certainly a bug in the kernel. either the ethernet driver blows up under load or some other memory allocation related bug. it is very common for ethernet to kill boards under load by triggering bugs. John On 24/04/17 05:49, Y.B. Lu wrote: Hi John and Jo-Philipp, Have you ever got similar problem, or known any possible reason about this, or known anyone who probably know this? I just found much memory would be consumed if I configured board as bridge mode in /etc/config/network and did UDP throughput test. But using brctl to configure bridge mode didn't consume memory. Thank you very much. Best regards, Yangbo Lu -Original Message- From: Y.B. Lu Sent: Thursday, April 13, 2017 1:24 PM To: 'lede-dev@lists.infradead.org' Subject: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network Hi all, Recently I got below kernel panic when did UDP throughput test on NXP LS1043ARDB board. I configured the bridge mode in /etc/config/network. But if I used 'brctl' to configure the bridge mode, this issue would not happen. I also noticed almost all memory was consumed(about 700MB) when kernel crashed. Anyone have any idea about this? Thank you very much. root@LEDE:/etc/fmc/config# [ 263.981540] ksoftirqd/3: page allocation failure: order:0, mode:0x2080020 [ 263.988339] CPU: 3 PID: 19 Comm: ksoftirqd/3 Not tainted 4.4.52 #0 [ 263.994508] Hardware name: This looks like just a warning...did the system really panic and stop working? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 01/13] procd: prepare NAND sysupgrade for making upgraded dynamically linked
Inline…
> On Apr 23, 2017, at 6:06 PM, Matthias Schiffer
> wrote:
>
> Use install_bin to copy upgraded with all dependencies. The old name
> /tmp/upgraded is temporarily retained as a symlink to avoid breaking
> things.
>
> Signed-off-by: Matthias Schiffer
> ---
> package/system/procd/files/nand.sh | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/package/system/procd/files/nand.sh
> b/package/system/procd/files/nand.sh
> index 01dba61644..9c831df3b4 100644
> --- a/package/system/procd/files/nand.sh
> +++ b/package/system/procd/files/nand.sh
> @@ -194,7 +194,7 @@ nand_upgrade_prepare_ubi() {
>
> nand_do_upgrade_success() {
> local conf_tar="/tmp/sysupgrade.tgz"
> -
> +
> sync
> [ -f "$conf_tar" ] && nand_restore_config "$conf_tar"
> echo "sysupgrade successful"
> @@ -231,7 +231,7 @@ nand_upgrade_ubifs() {
> local rootfs_length=`(cat $1 | wc -c) 2> /dev/null`
>
> nand_upgrade_prepare_ubi "$rootfs_length" "ubifs" "0" "0"
> -
> +
Please avoid whitespace-only changes.
> local ubidev="$( nand_find_ubi "$CI_UBIPART" )"
> local root_ubivol="$(nand_find_volume $ubidev rootfs)"
> ubiupdatevol /dev/$root_ubivol -s $rootfs_length $1
> @@ -333,7 +333,7 @@ nand_upgrade_stage1() {
> [ "$SAVE_CONFIG" != 1 -a -f "$CONF_TAR" ] &&
> rm $CONF_TAR
>
> - ubus call system nandupgrade "{\"path\": \"$path\" }"
> + ubus call system nandupgrade "{\"prefix\": \"$RAM_ROOT\",
> \"path\": \"$path\" }"
> exit 0
> }
> }
> @@ -370,6 +370,7 @@ nand_do_platform_check() {
> # $(1): file to be used for upgrade
> nand_do_upgrade() {
> echo -n $1 > /tmp/sysupgrade-nand-path
> - cp /sbin/upgraded /tmp/
> + install_bin /sbin/upgraded
> + ln -s "$RAM_ROOT"/sbin/upgraded /tmp/upgraded
> nand_upgrade_stage1
> }
> --
> 2.12.2
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 07/13] fstools: snapshot: handle jffs2 conversion using upgraded
Inline…
> On Apr 23, 2017, at 6:06 PM, Matthias Schiffer
> wrote:
>
> We can reuse the kill_remaining and run_ramfs facilities of the stage2 run
> by upgraded.
>
> Signed-off-by: Matthias Schiffer
> ---
> package/system/fstools/Makefile | 2 +-
> package/system/fstools/files/snapshot | 16 +---
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/package/system/fstools/Makefile b/package/system/fstools/Makefile
> index 759ea65978..db234aeecf 100644
> --- a/package/system/fstools/Makefile
> +++ b/package/system/fstools/Makefile
> @@ -8,7 +8,7 @@
> include $(TOPDIR)/rules.mk
>
> PKG_NAME:=fstools
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>
> PKG_SOURCE_PROTO:=git
> PKG_SOURCE_URL=$(LEDE_GIT)/project/fstools.git
> diff --git a/package/system/fstools/files/snapshot
> b/package/system/fstools/files/snapshot
> index c1a5b733f3..a495e34345 100644
> --- a/package/system/fstools/files/snapshot
> +++ b/package/system/fstools/files/snapshot
> @@ -42,7 +42,7 @@ do_snapshot_upgrade() {
>
> opkg list-upgradable
> [ $? -eq 0 ] || exit 2
> -
> +
Same as above… please make your changeset the absolute smallest substantive set
of changes.
We can live with a tab on an otherwise empty line…
> UPDATES=`opkg list-upgradable | cut -d" " -f1`
> [ -z "${UPDATES}" ] && exit 0
>
> @@ -64,14 +64,16 @@ do_convert_jffs2() {
> do_convert() {
> . /lib/functions.sh
> . /lib/upgrade/common.sh
> - ubus call system upgrade
> - touch /tmp/sysupgrade
> +
> cd /overlay/upper
> tar czf /tmp/snapshot.tar.gz *
> - kill_remaining TERM
> - sleep 3
> - kill_remaining KILL
> - run_ramfs '. /sbin/snapshot; do_convert_jffs2'
> +
> + install_bin /sbin/upgraded
> + ubus call system sysupgrade "{
> + \"prefix\": \"$RAM_ROOT\",
> + \"path\": \"\",
> + \"command\": \". /sbin/snapshot; do_convert_jffs2\"
> + }"
> }
>
> [ -n "$(cat /proc/mounts|grep /overlay|grep jffs2)" ] && {
> --
> 2.12.2
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 01/13] procd: prepare NAND sysupgrade for making upgraded dynamically linked
Inline…
> On Apr 24, 2017, at 2:20 PM, Matthias Schiffer
> wrote:
>
> On 04/24/2017 10:05 PM, Philip Prindeville wrote:
>> Inline…
>>
>>> On Apr 23, 2017, at 6:06 PM, Matthias Schiffer
>>> wrote:
>>>
>>> Use install_bin to copy upgraded with all dependencies. The old name
>>> /tmp/upgraded is temporarily retained as a symlink to avoid breaking
>>> things.
>>>
>>> Signed-off-by: Matthias Schiffer
>>> ---
>>> package/system/procd/files/nand.sh | 9 +
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/package/system/procd/files/nand.sh
>>> b/package/system/procd/files/nand.sh
>>> index 01dba61644..9c831df3b4 100644
>>> --- a/package/system/procd/files/nand.sh
>>> +++ b/package/system/procd/files/nand.sh
>>> @@ -194,7 +194,7 @@ nand_upgrade_prepare_ubi() {
>>>
>>> nand_do_upgrade_success() {
>>> local conf_tar="/tmp/sysupgrade.tgz"
>>> -
>>> +
>>> sync
>>> [ -f "$conf_tar" ] && nand_restore_config "$conf_tar"
>>> echo "sysupgrade successful"
>>> @@ -231,7 +231,7 @@ nand_upgrade_ubifs() {
>>> local rootfs_length=`(cat $1 | wc -c) 2> /dev/null`
>>>
>>> nand_upgrade_prepare_ubi "$rootfs_length" "ubifs" "0" "0"
>>> -
>>> +
>>
>>
>> Please avoid whitespace-only changes.
>
> Well, this is trailing whitespace, which every sensible editor should strip
> automatically (or at least warn about it). In my opinion, this change
> should be done, as a lot of developers will stumble over it, and would have
> to reconfigure their editors or exclude the changes from their commits…
Okay, what happens if someone else (with the same editor settings) is in the
file at the same time working on a PR? Then they will also try to correct the
whitespace stuff, and their commit will need to be rebased and hand-edited if
your commits go in first (or alternatively, your commits will need to be
rebased and hand-edited if theirs goes in first).
Simpler just to clean all of that up in a single commit which does nothing
else, and then set the pre-commit hook to check for PR’s which re-introduce
trailing whitespace and reject them before they get merged.
No argument about whether it should be done. Just about the “how” and “when”.
-Philip
>
>
>>
>>
>>> local ubidev="$( nand_find_ubi "$CI_UBIPART" )"
>>> local root_ubivol="$(nand_find_volume $ubidev rootfs)"
>>> ubiupdatevol /dev/$root_ubivol -s $rootfs_length $1
>>> @@ -333,7 +333,7 @@ nand_upgrade_stage1() {
>>> [ "$SAVE_CONFIG" != 1 -a -f "$CONF_TAR" ] &&
>>> rm $CONF_TAR
>>>
>>> - ubus call system nandupgrade "{\"path\": \"$path\" }"
>>> + ubus call system nandupgrade "{\"prefix\": \"$RAM_ROOT\",
>>> \"path\": \"$path\" }"
>>> exit 0
>>> }
>>> }
>>> @@ -370,6 +370,7 @@ nand_do_platform_check() {
>>> # $(1): file to be used for upgrade
>>> nand_do_upgrade() {
>>> echo -n $1 > /tmp/sysupgrade-nand-path
>>> - cp /sbin/upgraded /tmp/
>>> + install_bin /sbin/upgraded
>>> + ln -s "$RAM_ROOT"/sbin/upgraded /tmp/upgraded
>>> nand_upgrade_stage1
>>> }
>>> --
>>> 2.12.2
>>>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 01/13] procd: prepare NAND sysupgrade for making upgraded dynamically linked
On 04/24/2017 10:05 PM, Philip Prindeville wrote:
> Inline…
>
>> On Apr 23, 2017, at 6:06 PM, Matthias Schiffer
>> wrote:
>>
>> Use install_bin to copy upgraded with all dependencies. The old name
>> /tmp/upgraded is temporarily retained as a symlink to avoid breaking
>> things.
>>
>> Signed-off-by: Matthias Schiffer
>> ---
>> package/system/procd/files/nand.sh | 9 +
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/package/system/procd/files/nand.sh
>> b/package/system/procd/files/nand.sh
>> index 01dba61644..9c831df3b4 100644
>> --- a/package/system/procd/files/nand.sh
>> +++ b/package/system/procd/files/nand.sh
>> @@ -194,7 +194,7 @@ nand_upgrade_prepare_ubi() {
>>
>> nand_do_upgrade_success() {
>> local conf_tar="/tmp/sysupgrade.tgz"
>> -
>> +
>> sync
>> [ -f "$conf_tar" ] && nand_restore_config "$conf_tar"
>> echo "sysupgrade successful"
>> @@ -231,7 +231,7 @@ nand_upgrade_ubifs() {
>> local rootfs_length=`(cat $1 | wc -c) 2> /dev/null`
>>
>> nand_upgrade_prepare_ubi "$rootfs_length" "ubifs" "0" "0"
>> -
>> +
>
>
> Please avoid whitespace-only changes.
Well, this is trailing whitespace, which every sensible editor should strip
automatically (or at least warn about it). In my opinion, this change
should be done, as a lot of developers will stumble over it, and would have
to reconfigure their editors or exclude the changes from their commits...
>
>
>> local ubidev="$( nand_find_ubi "$CI_UBIPART" )"
>> local root_ubivol="$(nand_find_volume $ubidev rootfs)"
>> ubiupdatevol /dev/$root_ubivol -s $rootfs_length $1
>> @@ -333,7 +333,7 @@ nand_upgrade_stage1() {
>> [ "$SAVE_CONFIG" != 1 -a -f "$CONF_TAR" ] &&
>> rm $CONF_TAR
>>
>> -ubus call system nandupgrade "{\"path\": \"$path\" }"
>> +ubus call system nandupgrade "{\"prefix\": \"$RAM_ROOT\",
>> \"path\": \"$path\" }"
>> exit 0
>> }
>> }
>> @@ -370,6 +370,7 @@ nand_do_platform_check() {
>> # $(1): file to be used for upgrade
>> nand_do_upgrade() {
>> echo -n $1 > /tmp/sysupgrade-nand-path
>> -cp /sbin/upgraded /tmp/
>> +install_bin /sbin/upgraded
>> +ln -s "$RAM_ROOT"/sbin/upgraded /tmp/upgraded
>> nand_upgrade_stage1
>> }
>> --
>> 2.12.2
>>
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] ath10k ct ack timeout/coverage class
I have AP <-> Client links on the ath10k-ct driver+ firmware on QCA 9882 radios that work fine at a couple of hundred Meters. I recently tried a link at 1.2 Kilometers, but only got <1Mbps throughput. Does anyone know if coverage class/ack timeout is implemented in the ath10k-ct driver+firmware? Thanks ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MT7621 support Jumbo frames
Excuse me for my lack of experience with the patches. It turned out the patch was just fine, but gmail probably messed up the formatting. Thank you all very much for the links to the informative patches guides. I created my own patch with quilt and applied all the changes to the source manually. This allowed me to create a patch file with the proper formatting, which applied just fine. @Gaetano Catalli Very good job at the patch! It is working flawlessly for me in the limited amount of testing that I did. If there is anything else I can help you with, just let me know. I posted my MTU test results in the following Lede forum topic: https://forum.lede-project.org/t/build-for-the-d-link-dir-860l/948/62 On Sun, Apr 23, 2017 at 2:42 PM, Jaap Buurman wrote: > The mediatek folder is not there by default. It gets generated in the > during the "make" command when compiling the image by the patches. It > can be found at the following full path: > > source/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/linux-4.4.61/drivers/net/ethernet/mediatek > > I will try if I can patch the 17.01 branch. Does anyone have an idea > why gsw_mt7620.h is missing from the master branch? > > On Sun, Apr 23, 2017 at 2:30 PM, Alberto Bursi > wrote: >> Weird, I'm not seeing the whole "mediatek" folder if I try to follow >> your steps from a fresh source download with LEDE master (trunk/HEAD, >> whatever). >> >> I've checked the LEDE 17.01 branch and yes, there the "mediatek" folder >> is there and also that file. Kernel version is the same for both, >> 4.4.61, and that "mediatek" folder isn't there in the source package >> downloaded so it must come from LEDE patches. >> >> So go in main source folder and write "git checkout lede-17.01" then it >> should work. >> >> -Alberto >> >> >> On 04/23/2017 12:52 PM, Jaap Buurman wrote: >>> Thank you all for the suggestions. I've tried the following steps: >>> >>> 1) Add the patch in a file with a name so that it will be added last: >>> 999-mtu.patch. This failed during the build. >>> 2) Next, I wanted to write these changes manually to a patch with >>> quilt. However, the file /drivers/net/ethernet/mediatek/gsw_mt7620.h >>> was not there, so I could not apply those changes manually either. >>> That was the only file that gave me issues. The other files could be >>> found in the build_dir, and thus I could apply all the changes >>> manually. So that's where I'm stuck at the moment. >>> >>> On Sun, Apr 23, 2017 at 11:34 AM, Alberto Bursi >>> wrote: That patch is a raw kernel patch, you need to integrate it in LEDE's buildsystem and hope that he is working with LEDE patches already applied. Copy the patch's text in a text file and place this file in the /patches-* folder in your device's source folder Your SoC is a ramips so it should be target/linux/ramips/patches-4.4 as he said it is for kernel 4.4.7 Give it a name that makes sure it will be added last, like 999-mypatch.patch Then you can select your device with make menuconfig and then start a compilation with make and see if it goes well. If that fails, you need to follow the tutorial as linked, and create a new kernel patch where you write these changes manually to each file he changed, then save the new patch, and then move the patch file you created from the quilt kernel patch folder (platform/) to the patch folder as said above. There might be better ways, but that's what I did when I had to add new kernel patches. -Alberto On 04/22/2017 01:53 PM, Jaap Buurman wrote: I have never applied patches before, so I am probably making mistakes. The first problem I'm running into, is that it is trying to patch the following file: /drivers/net/ethernet/mediatek/gsw_mt7620.h However, such a file does not exist in that path in my build_dir. I can find gsw_mt7620.c and gsw_mt7620.o files just fine in the aforementioned path, but not the .h file it is trying to patch. To which branch does the patch apply cleanly? I am currently trying to patch the master branch. Should I try the 17.01 branch instead? On Wed, Apr 19, 2017 at 10:32 AM, Jaap Buurman wrote: Ah, that sounds even better :) I will try to compile and test this patch tomorrow or the day after tomorrow. Will let you know if it works. Thanks again for the effort you're putting into this! On Wed, Apr 19, 2017 at 10:23 AM, Gaetano Catalli wrote: I'm still working on this since I would like to raise the limit up to 9KB if possible. Please, let me know if this works for you. On Wed, Apr 19, 2017 at 10:18 AM, Jaap Buurman wrote: Wow, this is perfect. Thank you very much. I will try to use this patch and compile my own image with up to 2kb frame support. Do you have any plans on submitting th
Re: [LEDE-DEV] ath10k ct ack timeout/coverage class
There are some un-documented hacks using the ct_special debugfs file.
Very unlikely they are hooked into LEDE.
See this code in wmi.h:
/* CT firmware only, and only builds after June 26, 2015 */
struct wmi_pdev_set_special_cmd {
#define SET_SPECIAL_ID_ACK_CTS 0 /* set ack-cts-timeout register */
#define SET_SPECIAL_ID_SLOT1 /* set slot-duration register */
#define SET_SPECIAL_ID_SIFS2 /* set sifs-duration register */
and the set_special logic in debugfs.
Thanks,
Ben
On 04/24/2017 03:36 PM, Nick Dennis wrote:
I have AP <-> Client links on the ath10k-ct driver+ firmware on QCA 9882 radios
that work fine at a couple of hundred Meters. I recently tried a link at 1.2 Kilometers,
but only got <1Mbps throughput. Does anyone know if coverage class/ack timeout is
implemented in the ath10k-ct driver+firmware? Thanks
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] early printk breaks kernel on the clearfog board
try `make kernel_menuconfig` and select the corresponding one. Best Regards, Syrone Wong On Mon, Apr 24, 2017 at 11:18 PM, Josua Mayer wrote: > Am Montag, 24. April 2017, 02:37:48 CEST schrieb Syrone Wong: >> You may want to enable CONFIG_DEBUG_MVEBU_UART0_ALTERNATE > Yes, this is the one. But it is not visible from the Lede menuconfig. The > problem I was trying to point out is that in the kernel-config this is what > should be selected when selecting early-printk in the Lede menuconfig. >> or CONFIG_DEBUG_MVEBU_UART1_ALTERNATE if early printk is being enabled. >> >> >> Best Regards, >> Syrone Wong >> >> On Mon, Apr 24, 2017 at 3:39 AM, Josua Mayer > wrote: >> > Hi everybody, >> > >> > I noticed a serious problem with a Clearfog build that enables >> > CONFIG_KERNEL_EARLY_PRINTK=y. >> > In short: after Loading Kernel, the serial console stays completely >> > silent, and apparently the board does *not* boot. >> > >> > This came as a serious surprise to me. >> > Turns out the reason for this is the usage of the old uart physical >> > address: CONFIG_DEBUG_UART_PHYS=0xd0012000 >> > This is the default for if DEBUG_MVEBU_UART0 >> > However the Clearfog Pro uses mainline u-boot, and requires: >> > CONFIG_DEBUG_UART_PHYS=0xf1012000 >> > >> > Any opinions what should be done about this? >> > I personally suggest to switch to what the kernel config calls "new >> > bootloaders". >> > After all this is quite the trap when somebody is so thoughtful to start >> > with a debug build, only to find out that is the reason his builds don't >> > boot. >> > >> > Imre Kaloz: you are the one who committed this setting with config-4.4, >> > so I figured you may have some valuable insight here. >> > >> > br >> > Josua Mayer >> > >> > >> > ___ >> > Lede-dev mailing list >> > Lede-dev@lists.infradead.org >> > http://lists.infradead.org/mailman/listinfo/lede-dev > > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ath10k ct ack timeout/coverage class
Thanks. i did see something in mail-archive (don't know what source)
https://www.mail-archive.com/search?l=ath...@lists.infradead.org&q=subject:%22request%5C%3A+ACK+timing+setting+required%22&o=newest&f=1
Does the debugfs setting get overwritten by the ini settings during
resets and have to be re-done ?
In the past, I just set the ack timeout register without adjusting any
others and it worked, so I'll try that first.
Nick
On 24/04/2017 4:58 PM, Ben Greear wrote:
There are some un-documented hacks using the ct_special debugfs file.
Very unlikely they are hooked into LEDE.
See this code in wmi.h:
/* CT firmware only, and only builds after June 26, 2015 */
struct wmi_pdev_set_special_cmd {
#define SET_SPECIAL_ID_ACK_CTS 0 /* set ack-cts-timeout register */
#define SET_SPECIAL_ID_SLOT1 /* set slot-duration register */
#define SET_SPECIAL_ID_SIFS2 /* set sifs-duration register */
and the set_special logic in debugfs.
Thanks,
Ben
On 04/24/2017 03:36 PM, Nick Dennis wrote:
I have AP <-> Client links on the ath10k-ct driver+ firmware on QCA
9882 radios that work fine at a couple of hundred Meters. I recently
tried a link at 1.2 Kilometers, but only got <1Mbps throughput. Does
anyone know if coverage class/ack timeout is implemented in the
ath10k-ct driver+firmware? Thanks
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH netifd] Revert: set prefix indicator flag when IPv6 prefix lifetime, changes
Hi Hans I guess I should have double checked FS#713. I thought it was set to notify, and just wasn't touched. Sorry about that. wrt: > As explained in FS#713 reverting this patch will lead to complaints > from people homenet is broken > (https://github.com/openwrt/openwrt/issues/346[1]); a more > fundamental fix is required possible in procd to fix the issue. Just a collection of thoughts: If HNET is "broken," then is HNET the daemon that needs a change not netifd? If a network parameter is a trivial change, then should a daemon use ubus/dbus/whatever to poll it on its own schedule? If a network parameter is critical to function like address (non-wildcard binding) or route, then isn't the network manager necessary to announce the surprise updates? If a package is "core," then shouldn't it be cared for more than something more external? Do we want dnsmasq to flush its cache frequently in the default LEDE distro, or do we want HNET to work (for how many users)? If procd isn't discerning about trigger types, then is netifd update premature? Should procd be fixed before netifd? As LEDE gets supplemented with more packages, we need delay-trigger control like LEDE, but frequent noise like this doesn't help? I see a few issues with a balanced path to a solution. So maybe a better plan could be revert this for _now_ and have a less troublesome change with procd and netifd updated coherently. Thanks Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ath10k ct ack timeout/coverage class
The settings should stick in the firmware, but they have to be set each time the
firmware starts (the ath10k-ct driver should do that now, I think).
I haven't tested this feature though, so let me know if you find any issues.
Thanks,
Ben
On 04/24/2017 05:17 PM, Nick Dennis wrote:
Thanks. i did see something in mail-archive (don't know what source)
https://www.mail-archive.com/search?l=ath...@lists.infradead.org&q=subject:%22request%5C%3A+ACK+timing+setting+required%22&o=newest&f=1
Does the debugfs setting get overwritten by the ini settings during resets and
have to be re-done ?
In the past, I just set the ack timeout register without adjusting any others
and it worked, so I'll try that first.
Nick
On 24/04/2017 4:58 PM, Ben Greear wrote:
There are some un-documented hacks using the ct_special debugfs file.
Very unlikely they are hooked into LEDE.
See this code in wmi.h:
/* CT firmware only, and only builds after June 26, 2015 */
struct wmi_pdev_set_special_cmd {
#define SET_SPECIAL_ID_ACK_CTS 0 /* set ack-cts-timeout register */
#define SET_SPECIAL_ID_SLOT1 /* set slot-duration register */
#define SET_SPECIAL_ID_SIFS2 /* set sifs-duration register */
and the set_special logic in debugfs.
Thanks,
Ben
On 04/24/2017 03:36 PM, Nick Dennis wrote:
I have AP <-> Client links on the ath10k-ct driver+ firmware on QCA 9882 radios
that work fine at a couple of hundred Meters. I recently tried a link at 1.2 Kilometers,
but only got <1Mbps throughput. Does anyone know if coverage class/ack timeout is
implemented in the ath10k-ct driver+firmware? Thanks
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
