When we upgrade firmware(without saving config files), system will
reboot and executes switchjffs2() function(see fstools package).
During the process of switchjffs2(), the devices(such as /dev/sdaxx,
/dev/blockmmcxx) mounted under /mnt dir will lost.
This is for patch https://patchwork.
* Refreshed patches
Compile-tested: ar71xx
Run-tested: ar71xx
Signed-off-by: Etienne Haarsma
---
include/kernel-version.mk| 4 ++--
...03-mtd_fix_cfi_cmdset_0002_status_check.patch | 14 +++---
...11-mtd-cfi_cmdset_0002-force-word-write.patch | 6 +++---
.../pa
Am 02.05.2018 um 18:02 schrieb Jo-Philipp Wich:
> This small patch series changes the default location of various temporary
> and automatically generated files used by dnsmasq and odhcpd during normal
> operation.
If the location of /tmp/hosts/odhcpd and /tmp/dhcp.leases is changed and the
config
* Refreshed patches
Compile-tested: ar71xx
Run-tested: ar71xx
Signed-off-by: Etienne Haarsma
---
include/kernel-version.mk| 4 ++--
.../patches-4.4/630-packet_socket_type.patch | 16
...cting-with-source-address-failed-policy.patch | 14 +++-
On 03-05-18 14:01, Felix Fietkau wrote:
On 2018-05-03 13:12, Felix Fietkau wrote:
On 2018-05-02 17:37, Koen Vandeputte wrote:
Config moved from option.h to localoptions.h
refreshed all patches
deleted upstreamed patches:
- 010-runtime-maxauthtries.patch
- 610-skip-default-keys-in-custom-runs
On 2018-05-03 13:12, Felix Fietkau wrote:
> On 2018-05-02 17:37, Koen Vandeputte wrote:
>> Config moved from option.h to localoptions.h
>> refreshed all patches
>>
>> deleted upstreamed patches:
>> - 010-runtime-maxauthtries.patch
>> - 610-skip-default-keys-in-custom-runs.patch
>>
>> introduced n
I've detected that this error only happens when using 4.14 kernel and an
ath10k radio that is part of a bridge.
If the wireless interface is not part of a bridge, it works correctly
and no errors are shown.
Maybe this is a kernel related issue?
El 04/04/18 a las 15:39, Enrique Rodríguez Val
On 2018-05-02 17:37, Koen Vandeputte wrote:
> Config moved from option.h to localoptions.h
> refreshed all patches
>
> deleted upstreamed patches:
> - 010-runtime-maxauthtries.patch
> - 610-skip-default-keys-in-custom-runs.patch
>
> introduced new patch:
> - 610-disable-ec-by-default.patch
>
> T
Hi Felix,
I understand. I just sent an alternative patch which maintains an
independent linked list which I think should circumvent the corruption
of the same. This of course introduces some additional memory
allocation on the heap.
When this shouldn't be an option, what would be your suggestion
The fixed size array for queuing messages led to discarding messages
when it was full, using a linked list instead solves this issue.
The motivation was that for a recursive "ubus list" the function
ubusd_proto.c:ubusd_handle_lookup() produces more than n messages in
one uloop cycle when n objects
All,
Please skip these.
It does not apply anymore due to: "kernel: add missing
in6_dev_put_clear call to an ipv6 network patch"
Also .. yet another kernel bump was released yesterday ..
V2 later on ..
Koen
___
Lede-dev mailing list
Lede-dev@lists
On Thu, May 3, 2018 at 12:07 PM, Felix Fietkau wrote:
> Hi Benjamin,
>
> On 2018-05-02 22:55, Benjamin Hansmann wrote:
>> The fixed size array for queuing messages led to discarding messages
>> when it was full, using a linked list instead solves this issue.
>>
>> Having the list_head link in the
Hi Benjamin,
On 2018-05-02 22:55, Benjamin Hansmann wrote:
> The fixed size array for queuing messages led to discarding messages
> when it was full, using a linked list instead solves this issue.
>
> Having the list_head link in the ubus_msg_buf itself avoids the
> allocation of more memory for
On Wed, May 2, 2018 at 11:55 PM, Benjamin Hansmann wrote:
> The fixed size array for queuing messages led to discarding messages
> when it was full, using a linked list instead solves this issue.
>
> Having the list_head link in the ubus_msg_buf itself avoids the
> allocation of more memory for an
14 matches
Mail list logo
