Re: [LEDE-DEV] A request not making IRC necessary to be part of the action

2016-05-16 Thread Ben Greear 

On 05/16/2016 03:42 PM, Aaron Z wrote:

On Mon, May 16, 2016 at 5:21 PM, Ben Greear  wrote:

Maybe get an IRC bot to dump irc logs to the mailing list every few
hours?  Might be a bit spammy though

IMO, trying to follow IRC when its not realtime (ie: reading a log)
makes it somewhat difficult to follow threads of conversations (which
email does quite well) and it can be confusing unless there is some
way to put a "this post goes in this thread" for each post (and at
that point, you might as well use email).


Yes, I like email too.  But IRC has its uses, and maybe better to have it
spammed to the mailing list that just plain lost/ignored.

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: [LEDE-DEV] A request not making IRC necessary to be part of the action

2016-05-16 Thread Ben Greear 

Maybe get an IRC bot to dump irc logs to the mailing list every few
hours?  Might be a bit spammy though

Ben

On 05/16/2016 12:08 PM, Dave Taht wrote:

znc and bitlbee are godsends when using irc asynchronously.

In particular I feed all irc convos into bitlbee and then into erc on
emacs (so I am not hurt when my connection goes away).



On Mon, May 16, 2016 at 5:00 AM, David Woodhouse  wrote:

On Mon, 2016-05-16 at 12:46 +0100, Bruno Randolf wrote:

On 15/05/16 05:53, Daniel Dickinson wrote:


I'd really appreciate if we could actually use the mailing list for the
main communications venue rather than shutting out people not in the
European timezones, which is what happens if IRC is the main way to
participate in the community.

I have been told that to really be part of the OpenWrt action I should
have been on IRC; but I'm not in European timezone so that is not
actually a useful suggestion, since most of the most people most
relevant to decision-making are in Europe, and I would hope LEDE has a
more *inter-continental focus than OpenWrt had.

Agreed! I don't have time to hang out in IRC channels, usually. Or maybe
a different working style... (it distracts me too much). Anyhow I think
all important things and all things which don't need real-time
interaction should go thru the mailing list, please.


FWIW, IRC doesn't have to have real-time behaviour, and doesn't have to
be constantly distracting.

It's perfectly possible to have IRC conversations with people who are
never awake at the same time as you. You say something, they respond
when they wake up... and you respond when *you* wake up. Just like
email, in fact.

IRC gives you the *option* of real-time conversation, if you happen to
be awake at the same time.

And you don't have to pay attention to the channel all the time; an IRC
client should highlight if your nick is mentioned because someone is
talking you to specifically.

IRC is great for conversations which are more ephemeral, and don't need
to be archived for posterity.

--
dwmw2


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








--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: [LEDE-DEV] A request not making IRC necessary to be part of the action

2016-05-16 Thread Daniel Curran-Dickinson 
On 16-05-16 05:18 PM, Daniel Curran-Dickinson wrote:
> The objective is so that you don't have isolated pools of TZ's where one
> TZ has little insight into what the other TZ is doing and has no *good*
> mechanisms for communicating across timezones.
> 
> Reading IRC chat logs is an exercise is pain for many, so that's not
> really the answer for cross-timezone communication.
> 
> IRC, for many of us, is something that is only useful when it's realtime.
> 

It is also difficult to follow *threads* of conversation that are
severely time-delayed.

In addition, in order to not miss messages you really need to set up a
bouncer that is always on and keeps a unread messages even across an
unexpected reboot or logging out of your console/gui session.

Email is far superior for time-delayed threads of communication.  If
you're having problems with managing your email, it's your email
strategy that needs to change, not the use of email.

Regards,

Dan iel

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

Re: [LEDE-DEV] A request not making IRC necessary to be part of the action

2016-05-16 Thread Felix Fietkau 
On 2016-05-16 21:14, Bruno Randolf wrote:
> On 16/05/16 20:08, Dave Taht wrote:
>> znc and bitlbee are godsends when using irc asynchronously.
>> 
>> In particular I feed all irc convos into bitlbee and then into erc on
>> emacs (so I am not hurt when my connection goes away).
> 
> Well, thanks for the hints, but please just accept the fact that IRC is
> not part of everyones working mode.
One of the ideas that was tossed around was using LiquidFeedback to
replace the IRC meeting voting stuff. We're still looking into it...

- Felix

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

Re: [LEDE-DEV] Concern over kernel: backport patches improving fq_codel drop behavior

2016-05-16 Thread Kevin Darbyshire-Bryant 



On 16/05/16 11:46, Felix Fietkau wrote:

On 2016-05-13 11:57, Kevin Darbyshire-Bryant wrote:

Hi All,




I'm *very* much *for* the fq_codel batch drop functionality and that
ideally should be in a lede 4.4 patch, without the API change.  I attach
a patch that I think more suitable...or would form the basis of
something more suitable at least.

Apologies for the somewhat rush job on this I'm 10 minutes from
rushing out of the door for a week holiday :-)

What do you think about moving cake to the LEDE source tree instead?

- Felix



That's certainly a plan!  I'll do a PR next week :-)

Kevin

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

Re: [LEDE-DEV] ar71xx: performance decrease with kernel 4.4 (might be due to the qdisc/codel changes)

2016-05-16 Thread Dave Taht 
As a side note, you can do direct comparisons between data sets in
flent, really easily.

Load up all the data files in it, select something less noisy as a
plot type (cdf, totals, or box totals),
then select Data->Add other open data files.

I am *ALWAYS* a fan of looking at the default, detailed graph (all or
all_scaled)first, to see if there was any weirdnesses that would be
missed by the other plot types.

As an example of weirdnesses you can only detect by looking at a
string of test's long term behavior, see the current thread and
pictures on:

https://plus.google.com/u/0/107942175615993706558/posts/WA915Pt4SRN

One of the things I was concerned about going from 4.1 to 4.4 is that
there was a lot of x86_64 based optimization of the routing cache...
and I was certainly concerned about adding more variables to the
fq_codel algorithm, also. I saw pretty bad register usage in cake on
arm when I last looked, I've kind of always wanted people to try -O2
instead of -Os.


On Mon, May 16, 2016 at 1:48 AM, Hannu Nyman  wrote:
> I already said to Felix yesterday that I felt that with kernel 4.4 my ar71xx
> WNDR3800 seemed somehow more sluggish. Now I tested the matter with "flent".
>
> And sadly, with kernel 4.4 my router's performance decreases significantly.
> With kernel 4.1 the router achieves about 20% higher download throughput
> than with the 4.4 build :-(
>
> I used "flent" to measure wired connection throughput with
> - two LEDE builds: r241 with kernel 4.1 and r253 with kernel 4.4
> - two separate speed limits for SQM simple fq_codel QoS: 85000/1 kb/s
> that should leave some CPU power free in the router, and 11/15000 that
> should fully utilise the router's CPU.
> - otherwise identical settings, all measurements made inside 30 minutes so
> no changes in traffic conditions
>
> The achieved speeds were:
>
> r241 kernel 4.1 - 85/10: 79 Mb/s down, 8.1 Mb/s up
> r253 kernel 4.4 - 85/10: 67 Mb/s down, 8.5 Mb/s up
>
> r241 kernel 4.1 - 110/15: 85 down, 10.5 up
> r253 kernel 4.4 - 110/15: 70 down, 10.8 up
>
> (ping latency stays at 16-17 ms with all four tries)
>
> With both SQM speed limits, the kernel 4.1 build performs significantly
> better.
>
> This performance decrease might be due to the kernel version bump to 4.4 or
> the qdisc/codel changes made to the 4.4 patches a few days earlier.
>
> This chart sums it up:
> https://www.dropbox.com/sh/89pntkzjxydnn4c/AAC4x9cScJERL9Wfxm4k43kma?dl=0=Kernel41_44_comparison.png
>
> Full flent data (summary pics & rrul data files) for all four tries is
> available in:
> https://www.dropbox.com/sh/89pntkzjxydnn4c/AAC4x9cScJERL9Wfxm4k43kma?dl=0
>
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

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

Re: [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf

2016-05-16 Thread Daniel Golle 
On Mon, May 16, 2016 at 05:42:43PM +0300, Alexey Brodkin wrote:
> If an image gets built as an Elf there's a chance
> it will be used by developers for debugging purposes.
> In that case it's very helpful to keep debugging info
> in that image.
> 
> I would think that most OWRT-powered devices in production
> will use some form of binary image for booting so Elf
> flavours could be left a bit bulkier with more debug info
> inside.

Well, some of the tiniest AR7 boxes out there come with a bootloader
expecting ELF binaries... I didn't have a close look, just assuming
that they might be affected. May Florian knows more...?

Cheers

Daniel

> 
> Signed-off-by: Alexey Brodkin 
> ---
>  include/kernel-defaults.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
> index 406fd46..0166dc5 100644
> --- a/include/kernel-defaults.mk
> +++ b/include/kernel-defaults.mk
> @@ -142,7 +142,7 @@ endif
>  define Kernel/CopyImage
>   cmp -s $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).debug || { \
>   $(KERNEL_CROSS)objcopy -O binary $(OBJCOPY_STRIP) -S 
> $(LINUX_DIR)/vmlinux $(LINUX_KERNEL)$(1); \
> - $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux 
> $(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \
> + $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) $(LINUX_DIR)/vmlinux 
> $(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \
>   $(CP) $(LINUX_DIR)/vmlinux 
> $(KERNEL_BUILD_DIR)/vmlinux$(1).debug; \
>   $(foreach k, \
>   $(if $(KERNEL_IMAGES),$(KERNEL_IMAGES),$(filter-out 
> dtbs,$(KERNELNAME))), \
> -- 
> 2.5.5
> 
> 
> ___
> 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

[LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf

2016-05-16 Thread Alexey Brodkin 
If an image gets built as an Elf there's a chance
it will be used by developers for debugging purposes.
In that case it's very helpful to keep debugging info
in that image.

I would think that most OWRT-powered devices in production
will use some form of binary image for booting so Elf
flavours could be left a bit bulkier with more debug info
inside.

Signed-off-by: Alexey Brodkin 
---
 include/kernel-defaults.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 406fd46..0166dc5 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -142,7 +142,7 @@ endif
 define Kernel/CopyImage
cmp -s $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).debug || { \
$(KERNEL_CROSS)objcopy -O binary $(OBJCOPY_STRIP) -S 
$(LINUX_DIR)/vmlinux $(LINUX_KERNEL)$(1); \
-   $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux 
$(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \
+   $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) $(LINUX_DIR)/vmlinux 
$(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \
$(CP) $(LINUX_DIR)/vmlinux 
$(KERNEL_BUILD_DIR)/vmlinux$(1).debug; \
$(foreach k, \
$(if $(KERNEL_IMAGES),$(KERNEL_IMAGES),$(filter-out 
dtbs,$(KERNELNAME))), \
-- 
2.5.5


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

[LEDE-DEV] [PATCHv2 1/1] [brcm63xx] Display the correct detected CPU ID

2016-05-16 Thread Graham Fairweather 
The following changes since commit f8abb68e3a1b78ff5a8d616994daa9721fe8fc83:

  tools/cmake: bump to 3.5.2 (2016-05-13 17:03:54 +0200)

are available in the git repository at:

  https://github.com/Xotic750/mirror-lede.git fix_cpu_id

for you to fetch changes up to 3dc3f588e333466374a688607414eb16c0bb6520:

  Fix the logged CPU variant (2016-05-14 00:35:38 +0200)


Xotic750 (1):
  Fix the logged CPU variant

 
target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
| 9 +
 
target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
| 9 +
 2 files changed, 18 insertions(+)

diff --git 
a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
index 661abf6..23491aa 100644
--- 
a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
+++ 
b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
@@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu
variant helper
  bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;

  switch (bcm63xx_cpu_id) {
+@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
+ bcm63xx_memory_size = detect_memory_size();
+
+ printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n",
+-   bcm63xx_cpu_id, bcm63xx_cpu_rev);
++   bcm63xx_cpu_variant, bcm63xx_cpu_rev);
+ printk(KERN_INFO "CPU frequency is %u MHz\n",
+   bcm63xx_cpu_freq / 100);
+ printk(KERN_INFO "%uMB of RAM installed\n",
 --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
 +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
 @@ -19,6 +19,7 @@
diff --git 
a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
index 661abf6..330a9e6 100644
--- 
a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
+++ 
b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
@@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu
variant helper
  bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;

  switch (bcm63xx_cpu_id) {
+@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
+ bcm63xx_memory_size = detect_memory_size();
+
+ pr_info("Detected Broadcom 0x%04x CPU revision %02x\n",
+- bcm63xx_cpu_id, bcm63xx_cpu_rev);
++ bcm63xx_cpu_variant, bcm63xx_cpu_rev);
+ pr_info("CPU frequency is %u MHz\n",
+ bcm63xx_cpu_freq / 100);
+ pr_info("%uMB of RAM installed\n",
 --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
 +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
 @@ -19,6 +19,7 @@

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

Re: [LEDE-DEV] A request not making IRC necessary to be part of the action

2016-05-16 Thread David Woodhouse 
On Mon, 2016-05-16 at 12:46 +0100, Bruno Randolf wrote:
> On 15/05/16 05:53, Daniel Dickinson wrote:
> > 
> > I'd really appreciate if we could actually use the mailing list for the
> > main communications venue rather than shutting out people not in the
> > European timezones, which is what happens if IRC is the main way to
> > participate in the community.
> > 
> > I have been told that to really be part of the OpenWrt action I should
> > have been on IRC; but I'm not in European timezone so that is not
> > actually a useful suggestion, since most of the most people most
> > relevant to decision-making are in Europe, and I would hope LEDE has a
> > more *inter-continental focus than OpenWrt had.
> Agreed! I don't have time to hang out in IRC channels, usually. Or maybe
> a different working style... (it distracts me too much). Anyhow I think
> all important things and all things which don't need real-time
> interaction should go thru the mailing list, please.

FWIW, IRC doesn't have to have real-time behaviour, and doesn't have to
be constantly distracting.

It's perfectly possible to have IRC conversations with people who are
never awake at the same time as you. You say something, they respond
when they wake up... and you respond when *you* wake up. Just like
email, in fact.

IRC gives you the *option* of real-time conversation, if you happen to
be awake at the same time.

And you don't have to pay attention to the channel all the time; an IRC
client should highlight if your nick is mentioned because someone is
talking you to specifically.

IRC is great for conversations which are more ephemeral, and don't need
to be archived for posterity.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] A request not making IRC necessary to be part of the action

2016-05-16 Thread Bruno Randolf 
On 15/05/16 05:53, Daniel Dickinson wrote:
> I'd really appreciate if we could actually use the mailing list for the
> main communications venue rather than shutting out people not in the
> European timezones, which is what happens if IRC is the main way to
> participate in the community.
> 
> I have been told that to really be part of the OpenWrt action I should
> have been on IRC; but I'm not in European timezone so that is not
> actually a useful suggestion, since most of the most people most
> relevant to decision-making are in Europe, and I would hope LEDE has a
> more *inter-continental focus than OpenWrt had.

Agreed! I don't have time to hang out in IRC channels, usually. Or maybe
a different working style... (it distracts me too much). Anyhow I think
all important things and all things which don't need real-time
interaction should go thru the mailing list, please.

bruno


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

Re: [LEDE-DEV] possible PPPoE fix

2016-05-16 Thread Felix Fietkau 
On 2016-05-16 12:31, Syrone Wong wrote:
> Hi everyone,
> 
> I notice that if I send SIGHUP to pppd, it works the first time, but
> if you send the second time, pppd crashes and kernel may crash as
> well. I find the musl-libc
> fixes from openembedded works well for me, but I don't know the root
> cause. I tested the fix on ar71xx/Qihoo-c301 and mvebu/wrt1900ac, the
> issue above disappears.
Did you reproduce the issue only on mvebu or also on ar71xx?

- Felix


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

Re: [LEDE-DEV] [PATCH 1/1] [brcm63xx] Add support for the NetGear EVG2000

2016-05-16 Thread Graham Fairweather 
Ok, I tried "git request-pull", I assume that it has been submitted
ok, how do I know/track it?

[graham@tyr mirror-lede]$ git request-pull
f8abb68e3a1b78ff5a8d616994daa9721fe8fc83
https://github.com/Xotic750/mirror-lede.git evg2000
The following changes since commit f8abb68e3a1b78ff5a8d616994daa9721fe8fc83:

  tools/cmake: bump to 3.5.2 (2016-05-13 17:03:54 +0200)

are available in the git repository at:

  https://github.com/Xotic750/mirror-lede.git evg2000

for you to fetch changes up to c2f97ed220ad8eeb182e80c0fc006ece966679aa:

  Ran 'make target/linux/refresh V=s' after update to kernel 4.4.10
from 4.4.8 where the initial patch was added. (2016-05-14 00:34:17
+0200)


Xotic750 (2):
  Add initial support for EVG2000
  Ran 'make target/linux/refresh V=s' after update to kernel
4.4.10 from 4.4.8 where the initial patch was added.

 target/linux/brcm63xx/base-files/etc/board.d/01_leds
   |   7 +
 target/linux/brcm63xx/base-files/etc/board.d/02_network
   |   1 +
 target/linux/brcm63xx/base-files/etc/diag.sh
   |   3 +++
 target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
   |   2 +-
 target/linux/brcm63xx/base-files/lib/brcm63xx.sh
   |   3 +++
 target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
|   1 +
 target/linux/brcm63xx/dts/evg2000.dts
   | 103
+++
 target/linux/brcm63xx/image/Makefile
   |   2 ++
 target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch
   |  62
+++
 
target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
|   2 +-
 
target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
   |   4 +--
 target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
|   2 +-
 target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch
   |  62
+++
 target/linux/brcm63xx/profiles/netgear.mk
   |  10 +++
 
target/linux/generic/patches-4.4/032-fq_codel-add-batch-ability-to-fq_codel_drop.patch
  |   4 +--
 
target/linux/generic/patches-4.4/330-MIPS-kexec-Accept-command-line-parameters-from-users.patch
 |  10 +++
 target/linux/generic/patches-4.4/531-debloat_lzma.patch
   |  33 ---
 target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch
  |   5 ++--
 target/linux/generic/patches-4.4/834-ledtrig-libata.patch
   |   4 +--
 19 files changed, 289 insertions(+), 31 deletions(-)
 create mode 100644 target/linux/brcm63xx/dts/evg2000.dts
 create mode 100644 target/linux/brcm63xx/patches-4.1/805-board_EVG2000.patch
 create mode 100644 target/linux/brcm63xx/patches-4.4/805-board_EVG2000.patch

On 16 May 2016 at 12:24, Conor O'Gorman  wrote:
> On 16/05/16 11:14, Graham Fairweather wrote:
>>
>> Everything that I read talks about creating PRs when you have forked
>> from another github repo, and I have successfully create PRs in this
>> situation in the past. I have not seen any information about how to
>> create a PR when my repo was forked from a git repo that is hosted
>> outside of github. When I go to github and choose create PR, I can
>> only create it to branches within my fork, the upstream
>> (http://git.lede-project.org/openwrt/source.git) is not listed. Is
>> there a github repo that I should have forked from instead?
>>
> If you have a publicly accessible git repository you can use "git
> request-pull"
> https://git-scm.com/docs/git-request-pull
>
> If you are using github you can fork from
> https://github.com/lede-project/source
>
>

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

Re: [LEDE-DEV] Concern over kernel: backport patches improving fq_codel drop behavior

2016-05-16 Thread Felix Fietkau 
On 2016-05-13 11:57, Kevin Darbyshire-Bryant wrote:
> Hi All,
> 
> I've just seen
> https://github.com/lede-project/source/commit/fad8bdfa40df8636a52d770bbab010086c1976ec
> go through and wish to raise a concern:
> 
> The patch introduces a kernel API change 'qdisc_tree_decrease_qlen'
> replaces 'qdisc_tree_decrease_qlen' without a corresponding kernel
> version number change.  This will cause kmod_sched_cake to fail to build
> on lede 4.4 kernels.  A patch for kmod-sched-cake could be done, however
> that would make the package incompatible with openwrt until it also
> carries the above kernel patch (it would fail the 'other way around')
> 
> Personally, I think the patch is too invasive until an official backport
> is done (with corresponding kernel revision which can be tested for by
> kmod-sched-cake)
> 
> I'm *very* much *for* the fq_codel batch drop functionality and that
> ideally should be in a lede 4.4 patch, without the API change.  I attach
> a patch that I think more suitable...or would form the basis of
> something more suitable at least.
> 
> Apologies for the somewhat rush job on this I'm 10 minutes from
> rushing out of the door for a week holiday :-)
What do you think about moving cake to the LEDE source tree instead?

- Felix

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

[LEDE-DEV] possible PPPoE fix

2016-05-16 Thread Syrone Wong 
Hi everyone,

I notice that if I send SIGHUP to pppd, it works the first time, but
if you send the second time, pppd crashes and kernel may crash as
well. I find the musl-libc
fixes from openembedded works well for me, but I don't know the root
cause. I tested the fix on ar71xx/Qihoo-c301 and mvebu/wrt1900ac, the
issue above disappears.

What I have done:

1. 
https://github.com/wongsyrone/openwrt-1/commit/25a690bb809012e5194bc87b14b8ade30bd35e57

2.https://github.com/wongsyrone/openwrt-1/commit/4c1e96e9ad2b58d50d7b6f32f7f817a357698838

3.https://github.com/wongsyrone/openwrt-1/commit/84e28c8f303d9b74b1debb9d3d0b2293c8c4a220


Some data I collected: https://github.com/wongsyrone/openwrt-1/issues/87
Related ticket: https://dev.openwrt.org/ticket/22045

It's very appreciated if someone has better solutions against this issue.


Best Regards,
Syrone Wong

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

Re: [LEDE-DEV] [PATCH 1/1] [brcm63xx] Add support for the NetGear EVG2000

2016-05-16 Thread Graham Fairweather 
Everything that I read talks about creating PRs when you have forked
from another github repo, and I have successfully create PRs in this
situation in the past. I have not seen any information about how to
create a PR when my repo was forked from a git repo that is hosted
outside of github. When I go to github and choose create PR, I can
only create it to branches within my fork, the upstream
(http://git.lede-project.org/openwrt/source.git) is not listed. Is
there a github repo that I should have forked from instead?

On 16 May 2016 at 11:29, Conor O'Gorman  wrote:
> On 16/05/16 10:26, Graham Fairweather wrote:
>>
>> How do I do that? I forked the LEDE repo
>> (http://git.lede-project.org/openwrt/source.git) to github, created a
>> branch for the work
>> (https://github.com/Xotic750/mirror-lede/tree/evg2000), the LEDE
>> document (https://www.lede-project.org/development.html) says that PRs
>> are accepted, but no detail of how to do it?
>>
> https://help.github.com/articles/using-pull-requests/

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

Re: [LEDE-DEV] [PATCH 1/1] [brcm63xx] Add support for the NetGear EVG2000

2016-05-16 Thread Conor O'Gorman 

On 16/05/16 11:14, Graham Fairweather wrote:

Everything that I read talks about creating PRs when you have forked
from another github repo, and I have successfully create PRs in this
situation in the past. I have not seen any information about how to
create a PR when my repo was forked from a git repo that is hosted
outside of github. When I go to github and choose create PR, I can
only create it to branches within my fork, the upstream
(http://git.lede-project.org/openwrt/source.git) is not listed. Is
there a github repo that I should have forked from instead?

If you have a publicly accessible git repository you can use "git 
request-pull"

https://git-scm.com/docs/git-request-pull

If you are using github you can fork from 
https://github.com/lede-project/source




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

Re: [LEDE-DEV] [PATCH 1/1] [brcm63xx] Add support for the NetGear EVG2000

2016-05-16 Thread Conor O'Gorman 

On 16/05/16 10:26, Graham Fairweather wrote:

How do I do that? I forked the LEDE repo
(http://git.lede-project.org/openwrt/source.git) to github, created a
branch for the work
(https://github.com/Xotic750/mirror-lede/tree/evg2000), the LEDE
document (https://www.lede-project.org/development.html) says that PRs
are accepted, but no detail of how to do it?


https://help.github.com/articles/using-pull-requests/

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

Re: [LEDE-DEV] [PATCH 1/1] [brcm63xx] Add support for the NetGear EVG2000

2016-05-16 Thread Graham Fairweather 
How do I do that? I forked the LEDE repo
(http://git.lede-project.org/openwrt/source.git) to github, created a
branch for the work
(https://github.com/Xotic750/mirror-lede/tree/evg2000), the LEDE
document (https://www.lede-project.org/development.html) says that PRs
are accepted, but no detail of how to do it?

On 16 May 2016 at 11:08, John Crispin  wrote:
>
>
> On 16/05/2016 11:06, Graham Fairweather wrote:
>> Ok, thanks for the feedback. I tried so hard to make sure that it was
>> correct. :(
>>
>
>
>> On 16 May 2016 at 10:17, Conor O'Gorman  wrote:
>>> You are still having line wrap issues with your patches, as Felix previously
>>> mentioned.
>
>
> you can use github to send a PR if you like. that way you dont have to
> use a mail client.
>
> ___
> 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] ar71xx: performance decrease with kernel 4.4 (might be due to the qdisc/codel changes)

2016-05-16 Thread Felix Fietkau 
On 2016-05-16 10:48, Hannu Nyman wrote:
> I already said to Felix yesterday that I felt that with kernel 4.4 my ar71xx 
> WNDR3800 seemed somehow more sluggish. Now I tested the matter with "flent".
> 
> And sadly, with kernel 4.4 my router's performance decreases significantly. 
> With kernel 4.1 the router achieves about 20% higher download throughput than 
> with the 4.4 build :-(
> 
> I used "flent" to measure wired connection throughput with
> - two LEDE builds: r241 with kernel 4.1 and r253 with kernel 4.4
> - two separate speed limits for SQM simple fq_codel QoS: 85000/1 kb/s 
> that should leave some CPU power free in the router, and 11/15000 that 
> should fully utilise the router's CPU.
> - otherwise identical settings, all measurements made inside 30 minutes so no 
> changes in traffic conditions
> 
> The achieved speeds were:
> 
> r241 kernel 4.1 - 85/10: 79 Mb/s down, 8.1 Mb/s up
> r253 kernel 4.4 - 85/10: 67 Mb/s down, 8.5 Mb/s up
> 
> r241 kernel 4.1 - 110/15: 85 down, 10.5 up
> r253 kernel 4.4 - 110/15: 70 down, 10.8 up
> 
> (ping latency stays at 16-17 ms with all four tries)
> 
> With both SQM speed limits, the kernel 4.1 build performs significantly 
> better.
> 
> This performance decrease might be due to the kernel version bump to 4.4 or 
> the qdisc/codel changes made to the 4.4 patches a few days earlier.
> 
> This chart sums it up:
> https://www.dropbox.com/sh/89pntkzjxydnn4c/AAC4x9cScJERL9Wfxm4k43kma?dl=0=Kernel41_44_comparison.png
> 
> Full flent data (summary pics & rrul data files) for all four tries is 
> available in:
> https://www.dropbox.com/sh/89pntkzjxydnn4c/AAC4x9cScJERL9Wfxm4k43kma?dl=0
I've also noticed a throughput decrease on other platforms, I don't have
any hard data on that though. I've tried tracking down the source of
this regression, but haven't gotten anywhere with that yet.

Once we're done with more urgent stuff, I plan to do some more work on
optimizing the network stack.

- Felix

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

Re: [LEDE-DEV] [PATCH 1/1] [brcm63xx] Add support for the NetGear EVG2000

2016-05-16 Thread John Crispin 


On 16/05/2016 11:06, Graham Fairweather wrote:
> Ok, thanks for the feedback. I tried so hard to make sure that it was
> correct. :(
> 


> On 16 May 2016 at 10:17, Conor O'Gorman  wrote:
>> You are still having line wrap issues with your patches, as Felix previously
>> mentioned.


you can use github to send a PR if you like. that way you dont have to
use a mail client.

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

Re: [LEDE-DEV] [PATCH 1/1] [brcm63xx] Add support for the NetGear EVG2000

2016-05-16 Thread Graham Fairweather 
Ok, thanks for the feedback. I tried so hard to make sure that it was
correct. :(

On 16 May 2016 at 10:17, Conor O'Gorman  wrote:
> You are still having line wrap issues with your patches, as Felix previously
> mentioned.

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

[LEDE-DEV] ar71xx: performance decrease with kernel 4.4 (might be due to the qdisc/codel changes)

2016-05-16 Thread Hannu Nyman 
I already said to Felix yesterday that I felt that with kernel 4.4 my ar71xx 
WNDR3800 seemed somehow more sluggish. Now I tested the matter with "flent".


And sadly, with kernel 4.4 my router's performance decreases significantly. 
With kernel 4.1 the router achieves about 20% higher download throughput than 
with the 4.4 build :-(


I used "flent" to measure wired connection throughput with
- two LEDE builds: r241 with kernel 4.1 and r253 with kernel 4.4
- two separate speed limits for SQM simple fq_codel QoS: 85000/1 kb/s 
that should leave some CPU power free in the router, and 11/15000 that 
should fully utilise the router's CPU.
- otherwise identical settings, all measurements made inside 30 minutes so no 
changes in traffic conditions


The achieved speeds were:

r241 kernel 4.1 - 85/10: 79 Mb/s down, 8.1 Mb/s up
r253 kernel 4.4 - 85/10: 67 Mb/s down, 8.5 Mb/s up

r241 kernel 4.1 - 110/15: 85 down, 10.5 up
r253 kernel 4.4 - 110/15: 70 down, 10.8 up

(ping latency stays at 16-17 ms with all four tries)

With both SQM speed limits, the kernel 4.1 build performs significantly better.

This performance decrease might be due to the kernel version bump to 4.4 or 
the qdisc/codel changes made to the 4.4 patches a few days earlier.


This chart sums it up:
https://www.dropbox.com/sh/89pntkzjxydnn4c/AAC4x9cScJERL9Wfxm4k43kma?dl=0=Kernel41_44_comparison.png

Full flent data (summary pics & rrul data files) for all four tries is 
available in:

https://www.dropbox.com/sh/89pntkzjxydnn4c/AAC4x9cScJERL9Wfxm4k43kma?dl=0



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

[LEDE-DEV] mount_root issues

2016-05-16 Thread John Crispin 
Hi,

the recent changes i made to mount_root that caused lots of carnage for
lost of people should now be fixed. if you had issues with the root not
being mounted or being mounted twice then please update to latest HEAD
and try again.

John

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

Re: [LEDE-DEV] [PATCH 1/1] [brcm63xx] Add support for the NetGear EVG2000

2016-05-16 Thread Conor O'Gorman 
You are still having line wrap issues with your patches, as Felix 
previously mentioned.


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

Re: [LEDE-DEV] [PATCH] ath25: update kernel from 3.18 to 4.4

2016-05-16 Thread Russell Senior 

I've diffed the bootlogs of 3.18 and 4.4 for my particular image, included 
below:

--- /tmp/ath25-3.18-boot.log2016-05-16 00:50:16.984951380 -0700
+++ /tmp/ath25-4.4-boot.log 2016-05-16 00:50:30.337017589 -0700
@@ -13,23 +13,23 @@
 FLASH: 0xa800 - 0xa87f, 128 blocks of 0x0001 bytes each.
 == Executing boot script in 3.000 seconds - enter ^C to abort
 RedBoot> fis load -l vmlinux.bin.l7
-Image loaded from 0x80041000-0x803af7ec
+Image loaded from 0x80041000-0x803cc014
 RedBoot> exec
 Now booting linux kernel:
  Base address 0x8003 Entry 0x80041000
  Cmdline : 
-Linux version 3.18.29 (openwrt@hawg) (gcc version 5.3.0 (LEDE GCC 5.3.0 r241) 
) #1 Mon May 16 05:25:24 UTC 2016
+Linux version 4.4.10 (openwrt@hawg) (gcc version 5.3.0 (LEDE GCC 5.3.0 r241) ) 
#1 Mon May 16 07:13:54 UTC 2016
 bootconsole [early0] enabled
 CPU0 revision is: 00019064 (MIPS 4KEc)
 Determined physical RAM map:
  memory: 0200 @  (usable)
 Initrd not found or empty - disabling initrd
 Zone ranges:
-  Normal   [mem 0x-0x01ff]
+  Normal   [mem 0x-0x01ff]
 Movable zone start for each node
 Early memory node ranges
-  node   0: [mem 0x-0x01ff]
-Initmem setup node 0 [mem 0x-0x01ff]
+  node   0: [mem 0x-0x01ff]
+Initmem setup node 0 [mem 0x-0x01ff]
 Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
 Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 16 bytes
 Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
@@ -37,18 +37,23 @@
 PID hash table entries: 128 (order: -3, 512 bytes)
 Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
 Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
-Memory: 28452K/32768K available (2666K kernel code, 107K rwdata, 596K rodata, 
136K init, 193K bss, 4316K reserved)
+Memory: 28324K/32768K available (2749K kernel code, 108K rwdata, 632K rodata, 
148K init, 192K bss, K reserved, 0K cma-reserved)
+SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
 NR_IRQS:128
+clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 
20774570075 ns
+sched_clock: 32 bits at 92MHz, resolution 10ns, wraps every 23342213114ns
 Calibrating delay loop... 183.70 BogoMIPS (lpj=918528)
 pid_max: default: 32768 minimum: 301
 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
 Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
+clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 
1911260446275 ns
 NET: Registered protocol family 16
 registering PCI controller with io_map_base unset
 ar2315-pci ar2315-pci: register PCI controller
 PCI host bridge to bus :00
 pci_bus :00: root bus resource [mem 0x8000-0xbfff]
 pci_bus :00: root bus resource [io  0x]
+pci_bus :00: root bus resource [??? 0x flags 0x0]
 pci_bus :00: No busn resource found for root bus, will use [bus 00-ff]
 pci :00:00.0: BAR 1: assigned [mem 0x8000-0x83ff]
 pci :00:01.0: BAR 1: assigned [mem 0x8400-0x87ff]
@@ -68,12 +73,11 @@
 pci :00:04.0: BAR 0: assigned [mem 0x9986-0x9987]
 pci :00:05.0: BAR 0: assigned [mem 0x9988-0x9989]
 pci :00:06.0: BAR 0: assigned [mem 0x998a-0x998b]
-Switched to clocksource MIPS
+clocksource: Switched to clocksource MIPS
 NET: Registered protocol family 2
 TCP established hash table entries: 1024 (order: 0, 4096 bytes)
 TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
 TCP: Hash tables configured (established 1024 bind 1024)
-TCP: reno registered
 UDP hash table entries: 256 (order: 0, 4096 bytes)
 UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
 NET: Registered protocol family 1
@@ -82,7 +86,6 @@
 futex hash table entries: 256 (order: -1, 3072 bytes)
 squashfs: version 4.0 (2009/01/31) Phillip Lougher
 jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 
2001-2006 Red Hat, Inc.
-msgmni has been set to 55
 io scheduler noop registered
 io scheduler deadline registered (default)
 Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
@@ -97,31 +100,30 @@
 6 RedBoot partitions found on MTD device spiflash
 Creating 6 MTD partitions on "spiflash":
 0x-0x0003 : "RedBoot"
-0x0003-0x0015 : "vmlinux.bin.l7"
-0x0015-0x007e : "rootfs"
+0x0003-0x0016 : "vmlinux.bin.l7"
+0x0016-0x007e : "rootfs"
 mtd: device 2 (rootfs) set to be root filesystem
 1 squashfs-split partitions found on MTD device rootfs
-0x0052-0x007e : "rootfs_data"
+0x0053-0x007e : "rootfs_data"
 0x007e-0x007ef000 : "FIS directory"
 0x007ef000-0x007f : "RedBoot config"
 0x007f-0x0080 : "boardconfig"
 eth0: Atheros AR231x: 00:12:cf:83:7b:08, irq 4
 libphy: ar231x_eth_mii: probed
 eth0: attached PHY driver [Generic