Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

On Mon, Nov 21, 2016 at 7:11 PM, Christian Lamparter
 wrote:
> On Monday, November 21, 2016 2:57:59 PM CET Christian Mehlis wrote:
>> I found your repo/branch. I think you did a great job! Unfortunately I
>> can't compile your staging branch:
>>
>> [  4%] Building C object CMakeFiles/netifd.dir/system-linux.c.o
>> In file included from
>> /home/cmehlis/git/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.15_eabi/netifd-2016-10-27/system-linux.c:24:0:
>> /home/cmehlis/git/source/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.15_eabi/include/linux/if.h:79:2:
>> error: expected identifier before numeric constant
>>IFF_UP= 1<<0,  /* sysfs */
>>
>> Do you see the same problem? Rebasing your staging branch on top of
>> lede/master did not help.
>
> Yes, I did get the same error for netifd (and for ppp later on).
> After a dirclean these showed up here too. I traced the netifd
> error down to the following patch:
> "include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and 
> linux/in6.h" [0]
>
> For now, I reverted the change (in the v4.8.10), but I think this needs to be 
> fixed
> in musl (to that end, I updated to musl.git - and that was enough to fix
> the ppp error).  Anyway, let me know, if this fixes the compile errors
> but don't forget run make dirclean.
>
> It would be great to add support for a IPQ4028 device too. However, the
> dtsi files for the IPQ4028 never landed in upstream vanilla?! Also, the
> kernel devicetree maintainers frown upon "catch-all" compatible strings [1].
> So, you'll need to replace all the "qcom,ipq40xx" with either "qcom,ipq4028"
> or stick with the "qcom,ipq4019" for now (you can add it as the second
> compatible string.) Also note: the qcom,ipq4019.dtsi doesn't have a
> memory-node. However, this node is essential for booting.

Also note, I don't have a board as QCA did not want to give me one as
I was exiting.

-M

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter]

Hello,

On Monday, November 21, 2016 2:57:59 PM CET Christian Mehlis wrote:
> I found your repo/branch. I think you did a great job! Unfortunately I 
> can't compile your staging branch:
> 
> [  4%] Building C object CMakeFiles/netifd.dir/system-linux.c.o
> In file included from 
> /home/cmehlis/git/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.15_eabi/netifd-2016-10-27/system-linux.c:24:0:
> /home/cmehlis/git/source/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.15_eabi/include/linux/if.h:79:2:
>  
> error: expected identifier before numeric constant
>IFF_UP= 1<<0,  /* sysfs */
> 
> Do you see the same problem? Rebasing your staging branch on top of 
> lede/master did not help.

Yes, I did get the same error for netifd (and for ppp later on).
After a dirclean these showed up here too. I traced the netifd
error down to the following patch:
"include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and 
linux/in6.h" [0]

For now, I reverted the change (in the v4.8.10), but I think this needs to be 
fixed
in musl (to that end, I updated to musl.git - and that was enough to fix
the ppp error).  Anyway, let me know, if this fixes the compile errors
but don't forget run make dirclean.

It would be great to add support for a IPQ4028 device too. However, the
dtsi files for the IPQ4028 never landed in upstream vanilla?! Also, the
kernel devicetree maintainers frown upon "catch-all" compatible strings [1].
So, you'll need to replace all the "qcom,ipq40xx" with either "qcom,ipq4028"
or stick with the "qcom,ipq4019" for now (you can add it as the second
compatible string.) Also note: the qcom,ipq4019.dtsi doesn't have a
memory-node. However, this node is essential for booting.

Best Regards,
Christian

[0] 

[1] 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] request testers: lantiq u-boot 13.10 performance issue [solved]

[Eddi De Pieri]

Found the problem:

https://forum.openwrt.org/viewtopic.php?id=68533

Ok... >=2013.10 disable cache for ram...
#if !defined(CONFIG_SKIP_LOWLEVEL_INIT) || defined(CONFIG_SYS_DISABLE_CACHE)
/* CONFIG0 register */
li t0, CONF_CM_UNCACHED
mtc0 t0, CP0_CONFIG
#endif



On Mon, Nov 21, 2016 at 6:07 PM, Eddi De Pieri  wrote:
> Hi to all,
>
> I own a lantiq based router. I've self buildt u-boot 13.04 about 2
> years ago and I was really satisfied about it.
>
> On these days I've tried to switch to u-boot 13.10.
>
> It seems that linux take about 10 times to complete the boot process
> if compared to old 13.04.
>
> Please can you compare 13.04 and 13.10 performance on your board as well?
>
> Tested board: vgv7519
>
> Eddi De Pieri

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [bufferbloat-fcc-discuss] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]

[Eric Schultz]

All,

Since it's relevant to this discussion, I wanted to let folks know that
I've recently joined the Software Controlled Radio sub-group of the
FCC's Technical Advisory Council in my role as prpl Community Manager. A
press release about my participation is at
https://prpl.works/2016/11/21/prpl-foundation-collaborating-with-fcc-working-group/.
 The
sub-group consists of members of industry and academia with FCC staff
observing. We've been tasked with providing background on and, if
possible, recommendations to the FCC on how to balance reducing
interference with protecting innovation and the flexible addition of
features. I'm coming into the the sub-group late in the process (the
report is supposed to be done this year) but in the first few weeks, I
think I've been able to add some important viewpoints from the open
source community.


While the final report will be public, I've been asked by the chair of
the committee to keep the draft report confidential. If anyone here is
willing to help and will keep the draft confidential, I'd welcome your
assistance.

Thanks,

Eric

On 11/17/2016 11:06 PM, Paul Gardner-Stephen wrote:
> Hello,
>
> I think the fundamental problem is that the FCC wants to:
>
> 1. Make sure no one can run non-vendor-supplied firmware (presumably
> to try to stop harmful interference);
>
> and
>
> 2. Not ban the open-source movement from innovating on wireless using
> commercial wireless routers.
>
> We can all see that using that formulation they are trying to ban and
> allow the same thing at the same time.
>
> This is not unique to the US at the moment. The EU directive
> 2014/53/EU is trying to do the same thing.
>
> I am currently working with a team here at TU-Darmstadt to put a
> submission in to the German government to make sure that their
> implementation of the EU directive doesn't ban open-source firmware
> (actually, our reading of the current draft is that it would also
> accidentally ban a lot of other things due to a couple of small
> oversights). This is also causing me to extend my German vocabulary
> with words like "Zweckbestimmungsänderung,"
> "telekommunikationsendeinrichtungen," , and
> "harmonisierungsrechtsvorschriften."
>
> This is part of a larger project to understand (and hopefully improve)
> the legal situation for wireless ad-hoc emergency and humanitarian
> telecommunications networks.  While this use-case may be rather
> specific, it touches on most of the issues that affect the open-source
> wireless community in general.
>
> In this project, we intend to understand the current regulatory
> situation in the USA, Germany/EU, Australia and a handful of other
> countries, to see how they compare, and try to propose a rational
> framework that would be acceptable to national regulators, while not
> undermining the value of the various activities of the open-source
> wireless communities around the world.  Anyone who would like to help
> with this effort, feel free to poke me.
>
> Paul.
>
> On Fri, Nov 18, 2016 at 2:26 AM, Wayne Workman
> > wrote:
>
> I don't understand how this group's efforts weren't successful
> after what TP-Link had to do.
>
> Was it TP-LINK'S choice to support open source in an effort to
> save face and get brownie points or was it mandated by court?
>
> The FCC's stance, to me at least, is even more vague now.
>
> On Nov 17, 2016 10:03 AM, "Dave Taht"  > wrote:
>
> The linked document below is the same document we attacked, I
> thought
> successfully, last year,
>
> 
> http://www.computerworld.com/article/2993112/security/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html
> 
> 
>
> with the ultimate response from the fcc being
>
> 
> https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates
> 
> 
>
> Merely being asked to describe how the regdb works is all I
> see as the
> current FCC requirement. More than one manufacturer has got
> through
> this process since. Also, the context of that whole original
> debate
> was a dispute with tp-link, which only came out after the
> legal dust
> had settled.
>
> 
> http://arstechnica.com/information-technology/2016/08/fcc-forces-tp-link-to-support-open-source-firmware-on-routers/
> 
> 
>
> On Wed, Nov 16, 2016 at 2:15 PM, Simon Wunderlich
>  

[LEDE-DEV] request testers: lantiq u-boot 13.10 performance issue

[Eddi De Pieri]

Hi to all,

I own a lantiq based router. I've self buildt u-boot 13.04 about 2
years ago and I was really satisfied about it.

On these days I've tried to switch to u-boot 13.10.

It seems that linux take about 10 times to complete the boot process
if compared to old 13.04.

Please can you compare 13.04 and 13.10 performance on your board as well?

Tested board: vgv7519

Eddi De Pieri

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

That doesn't seem related to my changes. I was building with OpenWrt
CC release I believe and a really stripped down rootfs/kernel for
bring up. Maybe look for newer GCC fixups?

-M

On Mon, Nov 21, 2016 at 7:57 AM, Christian Mehlis  wrote:
> Hi Christian,
>
> I found your repo/branch. I think you did a great job! Unfortunately I can't
> compile your staging branch:
>
> [  4%] Building C object CMakeFiles/netifd.dir/system-linux.c.o
> In file included from
> /home/cmehlis/git/source/build_dir/target-arm_cortex-a7+neon-vfpv4_musl-1.1.15_eabi/netifd-2016-10-27/system-linux.c:24:0:
> /home/cmehlis/git/source/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-5.4.0_musl-1.1.15_eabi/include/linux/if.h:79:2:
> error: expected identifier before numeric constant
>   IFF_UP= 1<<0,  /* sysfs */
>
> Do you see the same problem? Rebasing your staging branch on top of
> lede/master did not help.
>
> Best Regards,
> Christian
>
>
> Am 2016-11-14 07:04, schrieb Christian Lamparter:
>>
>> Hello,
>>
>> On Saturday, November 12, 2016 12:03:54 AM CET Christian Mehlis wrote:
>>>
>>> I took your patches to my tree. They are for Linux 4.7, so I tried to
>>> make Lede build with that Linux version.
>>> I ran into some trouble with musl+netifd (fixed it). Now compat-wireless
>>> seems to expect an older Kernel:
>>>
>>> compat-wireless-2016-10-08/backport-include/linux/netdevice.h:337:5:
>>> error: 'struct net_device' has no member named 'trans_start'
>>>dev->trans_start = jiffies;
>>>
>>> The member was kicked in 4.7.
>>>
>>> In case someone is willing to help, I'm open for code.
>>
>>
>> I also got a IPQ40XX device. It's a Asus RT-AC58U. I played around with
>> it. The kernel is 4.8.6 (Since 4.7 is EOL).
>>
>> The initramfs image boots. serial and SPI(nor and nand) is working.
>> ath10k needs caldata (I'm not familiar with the new pre-cal and cal
>> data stuff). However no ethernet, no usb3, no cpufreq, no leds,
>> no crypto, ... (yet).
>>
>> Are you still interested?
>> https://github.com/chunkeey/LEDE-AC58U
>>
>> Regards,
>> Christian
>>
>> ---
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Linux version 4.8.6 (chuck@debian64) (gcc version 5.4.0
>> (LEDE GCC 5.4.0 r2109+1) ) #0 SMP Mon Nov 14 04:32:17 2016
>> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
>> cr=10c5387d
>> [0.00] CPU: div instructions available: patching division code
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [0.00] OF: fdt:Machine model: Asus AC58U
>> [0.00] Memory policy: Data cache writealloc
>> [0.00] On node 0 totalpages: 32256
>> [0.00] free_area_init_node: node 0, pgdat c092f340,
>> node_mem_map c7cf9000
>> [0.00]   Normal zone: 256 pages used for memmap
>> [0.00]   Normal zone: 0 pages reserved
>> [0.00]   Normal zone: 32256 pages, LIFO batch:7
>> [0.00] percpu: Embedded 13 pages/cpu @c7cae000 s20608 r8192
>> d24448 u53248
>> [0.00] pcpu-alloc: s20608 r8192 d24448 u53248 alloc=13*4096
>> [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 32000
>> [0.00] Kernel command line: root_rfs=0x
>> flash_type=norplusnand
>> [0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
>> [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536
>> bytes)
>> [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768
>> bytes)
>> [0.00] Memory: 119596K/129024K available (43K kernel code,
>> 227K rwdata, 752K rodata, 2480K init, 290K bss, 9428K reserved, 0K
>> cma-reserved, 0K highmem)
>> [0.00] Virtual kernel memory layout:
>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>> [0.00] vmalloc : 0xc880 - 0xff80   ( 880 MB)
>> [0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
>> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>> [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
>> [0.00]   .text : 0xc0208000 - 0xc0213198   (  45 kB)
>> [0.00]   .init : 0xc06be000 - 0xc092a000   (2480 kB)
>> [0.00]   .data : 0xc092a000 - 0xc0962dcc   ( 228 kB)
>> [0.00].bss : 0xc0964000 - 0xc09aca7c   ( 291 kB)
>> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
>> [0.00] Hierarchical RCU implementation.
>> [0.00] NR_IRQS:16 nr_irqs:16 16
>> [0.00] arm_arch_timer: Architected cp15 timer(s) running at
>> 48.00MHz (virt).
>> [0.00] clocksource: arch_sys_counter: mask: 0xff
>> max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns
>> [0.08] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps
>> every 4398046511096ns
>> [0.22] Switching to timer-based 

[LEDE-DEV] [PATCH] odhcpd: Display infinite valid lifetime as -1

[Hans Dedecker]

Display infinite valid lifetime as -1 both in ubus
and statefile

Signed-off-by: Hans Dedecker 
---

Follow-up patch as a result of the remark given in
http://lists.infradead.org/pipermail/lede-dev/2016-November/004133.html

src/dhcpv6-ia.c | 16 
 src/ubus.c  |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c
index 852af97..8db53b9 100644
--- a/src/dhcpv6-ia.c
+++ b/src/dhcpv6-ia.c
@@ -243,12 +243,12 @@ void dhcpv6_write_statefile(void)
odhcpd_hexlify(duidbuf, c->clid_data, 
c->clid_len);
 
// iface DUID iaid hostname lifetime 
assigned length [addrs...]
-   int l = snprintf(leasebuf, 
sizeof(leasebuf), "# %s %s %x %s %u %x %u ",
+   int l = snprintf(leasebuf, 
sizeof(leasebuf), "# %s %s %x %s %ld %x %u ",
iface->ifname, duidbuf, 
ntohl(c->iaid),
(c->hostname ? 
c->hostname : "-"),
-   
(unsigned)(c->valid_until > now ?
-   
(c->valid_until - now + wall_time) :
-   
(INFINITE_VALID(c->valid_until) ? INT32_MAX: 0)),
+   (c->valid_until > now ?
+   (c->valid_until 
- now + wall_time) :
+   
(INFINITE_VALID(c->valid_until) ? -1 : 0)),
c->assigned, 
(unsigned)c->length);
 
struct in6_addr addr;
@@ -306,12 +306,12 @@ void dhcpv6_write_statefile(void)
odhcpd_hexlify(duidbuf, c->hwaddr, 
sizeof(c->hwaddr));
 
// iface DUID iaid hostname lifetime 
assigned length [addrs...]
-   int l = snprintf(leasebuf, 
sizeof(leasebuf), "# %s %s ipv4 %s %u %x 32 ",
+   int l = snprintf(leasebuf, 
sizeof(leasebuf), "# %s %s ipv4 %s %ld %x 32 ",
iface->ifname, duidbuf,
(c->hostname ? 
c->hostname : "-"),
-   
(unsigned)(c->valid_until > now ?
-   
(c->valid_until - now + wall_time) :
-   
(INFINITE_VALID(c->valid_until) ? INT32_MAX: 0)),
+   (c->valid_until > now ?
+   (c->valid_until 
- now + wall_time) :
+   
(INFINITE_VALID(c->valid_until) ? -1 : 0)),
c->addr);
 
struct in_addr addr = {htonl(c->addr)};
diff --git a/src/ubus.c b/src/ubus.c
index 425abe4..e9e2de3 100644
--- a/src/ubus.c
+++ b/src/ubus.c
@@ -51,7 +51,7 @@ static int handle_dhcpv4_leases(struct ubus_context *ctx, 
_unused struct ubus_ob
blobmsg_add_string_buffer();
 
blobmsg_add_u32(, "valid", 
INFINITE_VALID(lease->valid_until) ?
-   INT32_MAX : 
(uint32_t)(lease->valid_until - now));
+   (uint32_t)-1 : 
(uint32_t)(lease->valid_until - now));
 
blobmsg_close_table(, l);
}
@@ -117,7 +117,7 @@ static int handle_dhcpv6_leases(_unused struct ubus_context 
*ctx, _unused struct
blobmsg_close_table(, m);
 
blobmsg_add_u32(, "valid", 
INFINITE_VALID(lease->valid_until) ?
-   INT32_MAX : 
(uint32_t)(lease->valid_until - now));
+   (uint32_t)-1 : 
(uint32_t)(lease->valid_until - now));
 
blobmsg_close_table(, l);
}
-- 
1.9.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[John Crispin]

On 21/11/2016 13:56, John Crispin wrote:
> NAK, please dont fiddle with inode counts. change the blocksize or the
> default mkfs_ext4 uses.
> 
>   John


https://git.lede-project.org/?p=project/make_ext4fs.git;a=blob;f=make_ext4fs.c#l281

> 
> On 12/11/2016 09:26, Bastian Bittorf wrote:
>> A rootfs typically has lots of small files, so the default
>> counter with 1024 inodes for 16 megabytes partition size can
>> be too restrictive and leads to e.g.
>>
>> root@box:/ touch /etc/config/test
>> touch: /etc/config/test: No space left on device
>>
>> the solution is to just double the amount of inodes
>> during image creation, so a 16mb part has 2048 inodes.
>>
>> see also:
>> http://lists.infradead.org/pipermail/lede-dev/2016-November/003977.html
>>
>> Signed-off-by: Bastian Bittorf 
>> ---
>>  include/image.mk | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/image.mk b/include/image.mk
>> index 8b183ab..e74a71d 100644
>> --- a/include/image.mk
>> +++ b/include/image.mk
>> @@ -239,11 +239,13 @@ define Image/mkfs/ubifs
>>  -o $@ -d $(call mkfs_target_dir,$(1))
>>  endef
>>  
>> +# doubles the default inode amount
>> +INODES=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*64*2)))
>>  E2SIZE=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*1024*1024)))
>>  
>>  define Image/mkfs/ext4
>>  $(STAGING_DIR_HOST)/bin/make_ext4fs \
>> --l $(E2SIZE) -b $(CONFIG_TARGET_EXT4_BLOCKSIZE) \
>> +-l $(E2SIZE) -i $(INODES) -b $(CONFIG_TARGET_EXT4_BLOCKSIZE) \
>>  $(if $(CONFIG_TARGET_EXT4_RESERVED_PCT),-m 
>> $(CONFIG_TARGET_EXT4_RESERVED_PCT)) \
>>  $(if $(CONFIG_TARGET_EXT4_JOURNAL),,-J) \
>>  $(if $(SOURCE_DATE_EPOCH),-T $(SOURCE_DATE_EPOCH)) \
>>
> 
> ___
> 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] scripts/getver.sh: treat all commits as local if can't find upstream

[John Crispin]

On 17/11/2016 07:25, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> If something goes wrong and script can't find upstream revision it will
> return something like:
> r2220
> which looks like a valid upstream revision 2220. We cant' distinguish it
> from e.g. 2200 upstream commits and 20 local ones.
> 
> The new format still provides revision number but also points clearly
> that is may be not the upstream one:
> r0+2220
> 
> Signed-off-by: Rafał Miłecki 
Acked-by: John Crispin < j...@phrozen.org>

i tried to apply it but is fails. feel free to add my Acked-by and push
it once rebased

John


> ---
>  scripts/getver.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/getver.sh b/scripts/getver.sh
> index 9b84602..2fd6adb 100755
> --- a/scripts/getver.sh
> +++ b/scripts/getver.sh
> @@ -33,7 +33,7 @@ try_git() {
>   UPSTREAM_BASE="$(git merge-base $GET_REV $ORIGIN)"
>   UPSTREAM_REV="$(git rev-list --count 
> ${REBOOT}..$UPSTREAM_BASE)"
>   else
> - UPSTREAM_REV=$REV
> + UPSTREAM_REV=0
>   fi
>  
>   if [ "$REV" -gt "$UPSTREAM_REV" ]; then
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[John Crispin]

NAK, please dont fiddle with inode counts. change the blocksize or the
default mkfs_ext4 uses.

John

On 12/11/2016 09:26, Bastian Bittorf wrote:
> A rootfs typically has lots of small files, so the default
> counter with 1024 inodes for 16 megabytes partition size can
> be too restrictive and leads to e.g.
> 
> root@box:/ touch /etc/config/test
> touch: /etc/config/test: No space left on device
> 
> the solution is to just double the amount of inodes
> during image creation, so a 16mb part has 2048 inodes.
> 
> see also:
> http://lists.infradead.org/pipermail/lede-dev/2016-November/003977.html
> 
> Signed-off-by: Bastian Bittorf 
> ---
>  include/image.mk | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/image.mk b/include/image.mk
> index 8b183ab..e74a71d 100644
> --- a/include/image.mk
> +++ b/include/image.mk
> @@ -239,11 +239,13 @@ define Image/mkfs/ubifs
>   -o $@ -d $(call mkfs_target_dir,$(1))
>  endef
>  
> +# doubles the default inode amount
> +INODES=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*64*2)))
>  E2SIZE=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*1024*1024)))
>  
>  define Image/mkfs/ext4
>   $(STAGING_DIR_HOST)/bin/make_ext4fs \
> - -l $(E2SIZE) -b $(CONFIG_TARGET_EXT4_BLOCKSIZE) \
> + -l $(E2SIZE) -i $(INODES) -b $(CONFIG_TARGET_EXT4_BLOCKSIZE) \
>   $(if $(CONFIG_TARGET_EXT4_RESERVED_PCT),-m 
> $(CONFIG_TARGET_EXT4_RESERVED_PCT)) \
>   $(if $(CONFIG_TARGET_EXT4_JOURNAL),,-J) \
>   $(if $(SOURCE_DATE_EPOCH),-T $(SOURCE_DATE_EPOCH)) \
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] mvebu: Add BQL patch for mvneta driver.

[Toke Høiland-Jørgensen]

This adds the patch submitted to upstream that adds BQL to the mvneta
driver: https://patchwork.kernel.org/patch/9328413/. Helps latency under
load when the physical link is saturated.

Signed-off-by: Toke Høiland-Jørgensen 
---
 .../147-net-mvneta-add-BQL-support.patch   | 83 ++
 1 file changed, 83 insertions(+)
 create mode 100644 
target/linux/mvebu/patches-4.4/147-net-mvneta-add-BQL-support.patch

diff --git 
a/target/linux/mvebu/patches-4.4/147-net-mvneta-add-BQL-support.patch 
b/target/linux/mvebu/patches-4.4/147-net-mvneta-add-BQL-support.patch
new file mode 100644
index 000..7bd2593
--- /dev/null
+++ b/target/linux/mvebu/patches-4.4/147-net-mvneta-add-BQL-support.patch
@@ -0,0 +1,83 @@
+--- a/drivers/net/ethernet/marvell/mvneta.c
 b/drivers/net/ethernet/marvell/mvneta.c
+@@ -1695,8 +1695,10 @@ static struct mvneta_tx_queue *mvneta_tx
+ 
+ /* Free tx queue skbuffs */
+ static void mvneta_txq_bufs_free(struct mvneta_port *pp,
+-   struct mvneta_tx_queue *txq, int num)
++   struct mvneta_tx_queue *txq, int num,
++   struct netdev_queue *nq)
+ {
++  unsigned int bytes_compl = 0, pkts_compl = 0;
+   int i;
+ 
+   for (i = 0; i < num; i++) {
+@@ -1704,6 +1706,11 @@ static void mvneta_txq_bufs_free(struct
+   txq->txq_get_index;
+   struct sk_buff *skb = txq->tx_skb[txq->txq_get_index];
+ 
++  if (skb) {
++  bytes_compl += skb->len;
++  pkts_compl++;
++  }
++
+   mvneta_txq_inc_get(txq);
+ 
+   if (!IS_TSO_HEADER(txq, tx_desc->buf_phys_addr))
+@@ -1714,6 +1721,8 @@ static void mvneta_txq_bufs_free(struct
+   continue;
+   dev_kfree_skb_any(skb);
+   }
++
++  netdev_tx_completed_queue(nq, pkts_compl, bytes_compl);
+ }
+ 
+ /* Handle end of transmission */
+@@ -1727,7 +1736,7 @@ static void mvneta_txq_done(struct mvnet
+   if (!tx_done)
+   return;
+ 
+-  mvneta_txq_bufs_free(pp, txq, tx_done);
++  mvneta_txq_bufs_free(pp, txq, tx_done, nq);
+ 
+   txq->count -= tx_done;
+ 
+@@ -2334,6 +2343,8 @@ out:
+   struct mvneta_pcpu_stats *stats = this_cpu_ptr(pp->stats);
+   struct netdev_queue *nq = netdev_get_tx_queue(dev, txq_id);
+ 
++  netdev_tx_sent_queue(nq, len);
++
+   txq->count += frags;
+   mvneta_txq_pend_desc_add(pp, txq, frags);
+ 
+@@ -2358,9 +2369,10 @@ static void mvneta_txq_done_force(struct
+ struct mvneta_tx_queue *txq)
+ 
+ {
++  struct netdev_queue *nq = netdev_get_tx_queue(pp->dev, txq->id);
+   int tx_done = txq->count;
+ 
+-  mvneta_txq_bufs_free(pp, txq, tx_done);
++  mvneta_txq_bufs_free(pp, txq, tx_done, nq);
+ 
+   /* reset txq */
+   txq->count = 0;
+@@ -2841,6 +2853,8 @@ static int mvneta_txq_init(struct mvneta
+ static void mvneta_txq_deinit(struct mvneta_port *pp,
+ struct mvneta_tx_queue *txq)
+ {
++  struct netdev_queue *nq = netdev_get_tx_queue(pp->dev, txq->id);
++
+   kfree(txq->tx_skb);
+ 
+   if (txq->tso_hdrs)
+@@ -2852,6 +2866,8 @@ static void mvneta_txq_deinit(struct mvn
+ txq->size * MVNETA_DESC_ALIGNED_SIZE,
+ txq->descs, txq->descs_phys);
+ 
++  netdev_tx_reset_queue(nq);
++
+   txq->descs = NULL;
+   txq->last_desc = 0;
+   txq->next_desc_to_proc = 0;
-- 
2.10.2


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev