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 ke
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 ---
On 04/09/2017 04:14 PM, Jo-Philip
Not all topology or connectivity changes may be detected by netifd,
depending on the underlying technology (e.g. VPN software); this adds a way
to explicitly trigger a renew.
Signed-off-by: Matthias Schiffer
---
interface.c | 9 +
interface.h | 1 +
ubus.c | 14 ++
3 f
Hello Sergey,
I forget to include the mailing list and did so now, so others can also maybe
benefit from our findings.
The board is booted with 17.01.0 initramfs image and “sysupgraded” with the
17.01.0 nand-large image (corresponding with the 2048 byte page size of the
NAND flash).
Then I use
The original implementation loaded the count register with (wrong) semi-
random values due to its implemenation nature.
If the wrongly calulated value was below the kickrate,
the WD was triggered and rebooted the system.
Rework this, partly based on upstream patches, to dynamically fetch the
curr
Signed-off-by: Koen Vandeputte
---
target/linux/cns3xxx/config-4.9 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/cns3xxx/config-4.9 b/target/linux/cns3xxx/config-4.9
index 8ae9714..2fec4f0 100644
--- a/target/linux/cns3xxx/config-4.9
+++ b/target/linux/cns3xxx/c
Signed-off-by: Koen Vandeputte
---
target/linux/cns3xxx/config-4.9 | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/linux/cns3xxx/config-4.9 b/target/linux/cns3xxx/config-4.9
index c8c029b..8ae9714 100644
--- a/target/linux/cns3xxx/config-4.9
+++ b/target/linux/cns3xxx/config-4.9
@@ -170
Hi Felix,
On Wed, 2017-04-12 at 10:53 +0200, Felix Fietkau wrote:
> On 2017-03-12 17:06, Felix Fietkau wrote:
> >
> > On 2017-03-10 17:01, Alexey Brodkin wrote:
> > >
> > > Hi Felix,
> > >
> > > On Fri, 2017-03-10 at 16:59 +0100, Felix Fietkau wrote:
> > > >
> > > > On 2017-03-10 16:57, Alexe
On 2017-03-12 17:06, Felix Fietkau wrote:
> On 2017-03-10 17:01, Alexey Brodkin wrote:
>> Hi Felix,
>>
>> On Fri, 2017-03-10 at 16:59 +0100, Felix Fietkau wrote:
>>> On 2017-03-10 16:57, Alexey Brodkin wrote:
>>> >
>>> > Completely forgot about feeds, sorry.
>>> > So what I did now was "./scripts
Commit 1f5ea4eae46e46a87353a751637ccb5d5cd5f60b disable the ath9k-phy led's
which caused the wifi LEDs on this board to remain dark. This commit
re-enables them using the target/linux/ar71xx/base-files/etc/board.d/01_leds
using the ucidef_set_led_wlan. The LEDs do not illuminate until firstboot
10 matches
Mail list logo