Hi,
the issue looks like a memory problem of kernel 4.14. If I reboot the router or
restart the network, netifd doesn't
crash again. Independently of this, memory consumption does increase very fast.
I let run an endless loop to call free
every 15min. The output from the beginning:
Sun May 20
On 19 May 2018 at 18:46, Christo Nedev wrote:
> Signed-off-by: Christo Nedev
> ---
> .../950-0001-brcm2708-raspberry-pi.patch | 19960
> +++
> 1 file changed, 19960 insertions(+)
> create mode 100644
>
On 19 May 2018 at 19:20, Christo Nedev wrote:
> Signed-off-by: Christo Nedev
While filename is chipset specific, this file is actually device
specific. So your brcmfmac43455-sdio.txt is for a specific device and
should not be used for all
This patch adds supports for GL-AR750S.
Specification:
- SOC: QCA9563 (775MHz)
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR2
- Ethernet: 2x 1Gbps LAN + 1x 1Gbps WAN
- Wireless: 2.4GHz (bgn) and 5GHz (ac)
- USB: 1x USB 2.0 port
- Button: 1x switch button, 1x reset button
- LED: 3x LEDS (green)
---
target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c
index 8457a0c..b556f9b 100755
---
On Sun, May 20, 2018 at 1:26 PM, Jo-Philipp Wich wrote:
> This commit changes ustream-ssl to support OpenSSL 1.1x as backend.
>
> OpenSSL 1.1.x made the BIO and BIO_METHOD structures opaque and
> introduced new getter/setter APIs to deal with them, therfore define
> forward-compat
This commit changes ustream-ssl to support OpenSSL 1.1x as backend.
OpenSSL 1.1.x made the BIO and BIO_METHOD structures opaque and
introduced new getter/setter APIs to deal with them, therfore define
forward-compat stubs for older OpenSSL versions and change the code in
ustream-io-openssl.c to
On Sun, May 20, 2018 at 1:04 PM, Kristian Evensen
wrote:
> Hello,
>
> When building and testing nightly on an MT7620-device I have (the
> Sanlinking D240), I noticed that changing the state of the two
> exported pins (45 and 46) had no effect. The pins are used to
Hello,
When building and testing nightly on an MT7620-device I have (the
Sanlinking D240), I noticed that changing the state of the two
exported pins (45 and 46) had no effect. The pins are used to control
the power to the two mini-PCIe slots on the board, and the devices
connected to the slots
I am using mips(ramips) target.
On 05/20/2018 11:42 AM, Rosysong wrote:
> Hi all,
> Using nftables to control the traffic flow through ip address has
> been succeed on my Linux PC, then I ported the same
> nft script into OpenWrt trunk. Unfortunately, it failed (has no effect on
>
On 05/20/2018 11:42 AM, Rosysong wrote:
> Hi all,
> Using nftables to control the traffic flow through ip address has
> been succeed on my Linux PC, then I ported the same
> nft script into OpenWrt trunk. Unfortunately, it failed (has no effect on
> restricting the speed of client). Is
Hi all,
Using nftables to control the traffic flow through ip address has been
succeed on my Linux PC, then I ported the same
nft script into OpenWrt trunk. Unfortunately, it failed (has no effect on
restricting the speed of client). Is there any conflict between iptables and
nftables ?
> On 19 May 2018, at 18:03, Rosen Penev wrote:
>
> Makes it easier to copy/paste the hash manually.
>
> Signed-off-by: Rosen Penev
> ---
> scripts/download.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/download.pl
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 ---
Hi Luochongjun,
> diff --git
14 matches
Mail list logo