On Freitag, 9. Februar 2018 01:36:49 CET Jakub Jančo wrote:
> Hello,
>
> is there any reason why LEDE needs more empty space in firmware for
> TP-link tl-wr1043nd v3 ?
OpenWrt master should show you the exact same error message. OpenWrt 15.05 is
quite outdated.
> In OpenWRT 15.01 we are buildin
On Freitag, 9. Februar 2018 09:05:02 CET Sven Eckelmann wrote:
[...]
> > In OpenWRT 15.01 we are building 7.3MB large images and have just
> > enought space for configs.
> > In LEDE 17.01 is max size ~6.5MB and we are not able to build our
> > images, because we cannot strip more packages, now we a
On 8 February 2018 at 18:34, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> It may happen that on mountd start some devices are already mounted.
> This could due to killing previous mountd instance or just a crash. In
> such case device shouldn't get remounted but added to the list with a
> mount
From: Rafał Miłecki
Caller of mount_dev_del() already has struct mount * so there is no
point in passing matchin device and then looking for struct mount *
again.
Signed-off-by: Rafał Miłecki
---
mount.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff
From: Rafał Miłecki
Kernel can report mount point as expired and when that happens mountd
unmounts it. It's still important to:
1) Cleanup directories
2) Call hotplug scripts
when device for such a mount disappears. Fix this by adding a new
EXPIRED status and checking it when block device disappe
From: Rafał Miłecki
There is no need to store status using these 2 separated fields.
Obviously ignored mount should never get mounted. This change will also
allow adding more statuses easily in the future if needed.
Signed-off-by: Rafał Miłecki
---
mount.c | 47 ++--
LGTM
Been using it here for a few days.
> On Feb 1, 2018, at 5:57 PM, Daniel Golle wrote:
>
> When sourcing /sys/class/block/*/uevent values have to be quoted as
> they may contain spaces (e.g. in PARTNAME).
> Fix this by pre-processing with sed before sourcing.
>
> Signed-off-by: Daniel Goll
> On Jan 18, 2018, at 2:15 PM, Hauke Mehrtens wrote:
>
> On 01/18/2018 01:51 PM, Nick Lowe wrote:
>> Does an update to the Kernel, 4.9.77 and 4.14.14 need to be made to
>> properly address this? There are fixes to mitigate Spectre.
>
> We even need a patch for GCC which will be in GCC 8 and 7.
On 02/09/2018 12:27 AM, Lucian Cristian wrote:
> On 21.01.2018 19:53, Hauke Mehrtens wrote:
>> This add support for kernel 4.14 to the mvebu target. My main reason to
>> add kernel 4.14 support is to make it easier to also add support for the
>> Marvell Armada 3700LP ARM64 SoCs especially the ESPRE
On 01/21/2018 06:53 PM, Hauke Mehrtens wrote:
> This add support for kernel 4.14 to the mvebu target. My main reason to
> add kernel 4.14 support is to make it easier to also add support for the
> Marvell Armada 3700LP ARM64 SoCs especially the ESPRESSObin board.
>
> I do not have any of the cu
On 02/09/2018 09:46 PM, Philip Prindeville wrote:
>
>
>> On Jan 18, 2018, at 2:15 PM, Hauke Mehrtens wrote:
>>
>> On 01/18/2018 01:51 PM, Nick Lowe wrote:
>>> Does an update to the Kernel, 4.9.77 and 4.14.14 need to be made to
>>> properly address this? There are fixes to mitigate Spectre.
>>
>>
On Fri, Feb 9, 2018 at 1:52 PM, Hauke Mehrtens wrote:
> On 01/21/2018 06:53 PM, Hauke Mehrtens wrote:
>> This add support for kernel 4.14 to the mvebu target. My main reason to
>> add kernel 4.14 support is to make it easier to also add support for the
>> Marvell Armada 3700LP ARM64 SoCs especiall
On Fri, Feb 9, 2018 at 2:57 PM, Rosen Penev wrote:
> On Fri, Feb 9, 2018 at 1:52 PM, Hauke Mehrtens wrote:
>> On 01/21/2018 06:53 PM, Hauke Mehrtens wrote:
>>> This add support for kernel 4.14 to the mvebu target. My main reason to
>>> add kernel 4.14 support is to make it easier to also add supp
On 02/09/2018 11:57 PM, Rosen Penev wrote:
> On Fri, Feb 9, 2018 at 1:52 PM, Hauke Mehrtens wrote:
>> On 01/21/2018 06:53 PM, Hauke Mehrtens wrote:
>>> This add support for kernel 4.14 to the mvebu target. My main reason to
>>> add kernel 4.14 support is to make it easier to also add support for t
This config option was renamed in upstream Linux commit 681bec0367
("tracing: Rename update the enum_map file")
Reported-by: Rosen Penev
Signed-off-by: Hauke Mehrtens
---
target/linux/generic/config-4.14 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/generic/co
On Fri, Feb 9, 2018 at 3:44 PM, Hauke Mehrtens wrote:
> This config option was renamed in upstream Linux commit 681bec0367
> ("tracing: Rename update the enum_map file")
>
> Reported-by: Rosen Penev
> Signed-off-by: Hauke Mehrtens
> ---
> target/linux/generic/config-4.14 | 2 +-
> 1 file change
The arm CPUs uses in the supported Mediatket SoCs have a FPU accordingly
to the datasheet, activate it also. The CPU subtype "neon-vfpv4" is
selected, but the toolcahin generated for this SoC will still be
compiled with soft float and not with the hard float ABI as we haven't
the fpu feature flag s
On 09.02.2018 23:48, Hauke Mehrtens wrote:
On 02/09/2018 12:27 AM, Lucian Cristian wrote:
On 21.01.2018 19:53, Hauke Mehrtens wrote:
This add support for kernel 4.14 to the mvebu target. My main reason to
add kernel 4.14 support is to make it easier to also add support for the
Marvell Armada 37
On Thu, Feb 1, 2018 at 9:23 AM, Lucian Cristian wrote:
> On 30.01.2018 18:14, Rosen Penev wrote:
>>
>> Based on Qualcomm's upstream code. Reordered a bit different.
>>
>> iperf3 speed goes from ~279mbps to ~320mbps.
>>
>> Signed-off-by: Rosen Penev
>> ---
>> .../files/drivers/net/ethernet/ather
19 matches
Mail list logo
