Re: [LEDE-DEV] QCA Dakota support

2016-11-28 Thread Alexis Green
Hi Christian,

Thank you for the usb wireless device hint! I had an ath9k-htc dongle
kicking about and I'm seeing memory wastage with that device as well
(albeit slower and only happening while I'm pumping a lot of traffic
through it), so ath10k is likely off the hook for this one. In fact, I
went even farther, checking to see if sending traffic via ethernet
port causes problems and, again, there's memory wastage. Maybe it's a
kernel bug after all. One potential thing to try is to roll kernel to
an older version.

Best regards,

Alexis

On Mon, Nov 28, 2016 at 9:37 AM, Christian Lamparter
 wrote:
> Hello Alexis,
>
> On Sunday, November 27, 2016 12:18:00 PM CET Alexis Green wrote:
>> Could you post .config for your build? I cloned your repo and
>> successfully built and installed an image, but I'm seeing some rather
>> weird behavior.
> I added it, but I don't have any magic values in the .config. I played
> around with adding LPAE for KVM but as it turns out the DMA driver doesn't
> like that.
>
> And there are definitely bugs. If you are looking for support, your best
> option is to ask: Matthew McClintock. Since developed most of the platform
> code while he was working for QCA, so he more familiar with the hardware
> and drivers as I just got this and put a port together for just my hardware...
> It's too bad that he didn't get to keep his board.
>
>> I get kernel oops (null derefrence) in bridge code when I connect a
>> client to WPA2 AP that is bridged. The oops is gone after I removed
>> the following patches (I'm sure it's just one of them, but I have not
>> had a chance  to figure out which one exactly it is).
>> target/linux/generic/patches-4.8/120-bridge_allow_receiption_on_disabled_port.patch
>> target/linux/generic/patches-4.8/640-bridge_no_eap_forward.patch
>> target/linux/generic/patches-4.8/641-bridge_always_accept_eap.patch
> I have to add Alvaro for this (I'm using his experimental 4.8-rc series
> which he is using for his raspberrypi 3 code). As for which one causes
> the issue: I think 640-bridge_no_eap_forward.patch is the one. It looks
> like the following patch in 4.8. changed the way the skb and skb2 works:
>
> commit b35c5f632b630183396a2ea2e2247ff8bbf2c94f
> Author: Nikolay Aleksandrov 
> Date:   Thu Jul 14 06:10:01 2016 +0300
>
> net: bridge: drop skb2/skb0 variables and use a local_rcv boolean [0]
>
> Looking at this commit and the original patch [1]:
> I think we can drop the skb = NULL there (and maybe put the comment
> in front of the local_rcv = true;)
>
>> I'm also seeing rather fast memory leak/wastage when wireless devices
>> are up - takes 10-15 min to run out of memory. I tried using kmemleak,
>> but it doesn't report any suspected leaks. I guess I'll try some
>> tracing next.
> I've added a few new patches to mac80211-package from the current
> wireless-testing.git. If the issue persists, can you report this to
> the ath10k-devel mailing list?
>
> Note: You should check, if it's really the ath10k driver. This can
> be done by plugging in a usb-wifi device and setting it up. If it
> also fails then there's probably another issue with the patchset.
>
> Regards,
> Christian
>
> [0] 
> 
>
> [1] 
> 

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


Re: [LEDE-DEV] [PATCH v2] ath9k: Add airtime fairness scheduler.

2016-11-28 Thread Toke Høiland-Jørgensen


On 28 November 2016 20:33:55 CET, Weedy  wrote:
>On Monday, November 28, 2016, Toke Høiland-Jørgensen 
>wrote:
>> This adds a patch that introduces airtime fairness scheduling to
>ath9k,
>> which can significantly improve network efficiency in mixed-rate
>> environments.
>>
>> Signed-off-by: Toke Høiland-Jørgensen 
>
>Changelog?

It's in the patch file. Just a minor change to get rid of a couple of function 
calls. No functional change.

-Toke


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


Re: [LEDE-DEV] Fwd: [PATCH] ath9k: Add airtime fairness scheduler

2016-11-28 Thread bart van zoest
Thanks John and Toke,

The build compiled fine however I am not able to test it (atm no
access to router).
Also saw that Toke released v2 of the patch so my box is compiling again

On Mon, Nov 28, 2016 at 3:09 PM, John Crispin  wrote:
>
>
> On 28/11/2016 14:58, bart van zoest wrote:
>> Hi Weedy and Toke,
>>
>> I am trying to apply the patch using: "curl
>> https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v". Is the
>> following output normal?
>>
>> :60: trailing whitespace.
>>  :65: trailing whitespace.
>>  :67: space before tab in indent.
>>  bool has_queued;
>> :69: trailing whitespace.
>>  :74: space before tab in indent.
>>  struct ath_softc *sc;
>> Checking patch 
>> package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch...
>> Applied patch 
>> package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
>> cleanly.
>> warning: squelched 152 whitespace errors
>> warning: 157 lines add whitespace errors.
>
> these types of messages are nortmal as you are applying a patch that
> adds a patch which will be applied during build.
>
> John
>
>>
>> On Sun, Nov 27, 2016 at 12:08 PM, Weedy  wrote:
>>>
>>> On Fri, Nov 25, 2016 at 5:16 AM, Toke Høiland-Jørgensen  
>>> wrote:
 This adds a patch that introduces airtime fairness scheduling to ath9k,
 which can significantly improve network efficiency in mixed-rate
 environments.
>>> ...
 ++  astats = >airtime_stats;
 ++
 ++  len += scnprintf(buf + len, size - len, "RX: %u us\n", 
 astats->rx_airtime);
 ++  len += scnprintf(buf + len, size - len, "TX: %u us\n", 
 astats->tx_airtime);
 ++  len += scnprintf(buf + len, size - len, "Deficit: ");
 ++  for (i = 0; i < 4; i++)
 ++  len += scnprintf(buf+len, size - len, "%s: %lld us ", 
 qname[i], an->airtime_deficit[i]);
 ++  if (len < size)
 ++  buf[len++] = '\n';
 ++
 ++  retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
 ++  kfree(buf);
 ++
 ++  return retval;
 ++}
>>>
>>> I'm supposed to have a
>>> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/something/airtime
>>> right?
>>> Should I have done anything else besides:
>>> # curl https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v
>>> # make V=s package/mac80211/{clean,install}
>>> Applying ./patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
>>> using plaintext:
>>> patching file drivers/net/wireless/ath/ath9k/ath9k.h
>>> patching file drivers/net/wireless/ath/ath9k/channel.c
>>> patching file drivers/net/wireless/ath/ath9k/debug.c
>>> patching file drivers/net/wireless/ath/ath9k/debug.h
>>> patching file drivers/net/wireless/ath/ath9k/debug_sta.c
>>> patching file drivers/net/wireless/ath/ath9k/init.c
>>> patching file drivers/net/wireless/ath/ath9k/main.c
>>> patching file drivers/net/wireless/ath/ath9k/recv.c
>>> patching file drivers/net/wireless/ath/ath9k/xmit.c
>>>
>>> # 
>>>
>>> Sat Nov 26 16:39:31 2016 kern.warn kernel: [   11.595812] PCI:
>>> Enabling device :00:11.0 ( -> 0002)
>>> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.606388] ath: phy0:
>>> Ignoring endianness difference in EEPROM magic bytes.
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614943] ath: EEPROM
>>> regdomain: 0x0
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614952] ath: EEPROM
>>> indicates default country code should be used
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614960] ath: doing
>>> EEPROM country->regdmn map search
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614975] ath:
>>> country maps to regdmn code: 0x3a
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614985] ath:
>>> Country alpha2 being used: US
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614993] ath:
>>> Regpair used: 0x3a
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.628327] ieee80211
>>> phy0: Selected rate control algorithm 'minstrel_ht'
>>> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.632241] ieee80211
>>> phy0: Atheros AR9280 Rev:2 mem=0xb000, irq=40
>>> Sat Nov 26 16:39:31 2016 kern.warn kernel: [   11.697119] PCI:
>>> Enabling device :00:12.0 ( -> 0002)
>>> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.707690] ath: phy1:
>>> Ignoring endianness difference in EEPROM magic bytes.
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716278] ath: EEPROM
>>> regdomain: 0x0
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716289] ath: EEPROM
>>> indicates default country code should be used
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716297] ath: doing
>>> EEPROM country->regdmn map search
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716313] ath:
>>> country maps to regdmn code: 0x3a
>>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716322] ath:
>>> Country alpha2 

Re: [LEDE-DEV] QCA Dakota support

2016-11-28 Thread Christian Lamparter
Hello Alexis,

On Sunday, November 27, 2016 12:18:00 PM CET Alexis Green wrote:
> Could you post .config for your build? I cloned your repo and
> successfully built and installed an image, but I'm seeing some rather
> weird behavior.
I added it, but I don't have any magic values in the .config. I played
around with adding LPAE for KVM but as it turns out the DMA driver doesn't
like that.

And there are definitely bugs. If you are looking for support, your best
option is to ask: Matthew McClintock. Since developed most of the platform
code while he was working for QCA, so he more familiar with the hardware
and drivers as I just got this and put a port together for just my hardware...
It's too bad that he didn't get to keep his board.  
 
> I get kernel oops (null derefrence) in bridge code when I connect a
> client to WPA2 AP that is bridged. The oops is gone after I removed
> the following patches (I'm sure it's just one of them, but I have not
> had a chance  to figure out which one exactly it is).
> target/linux/generic/patches-4.8/120-bridge_allow_receiption_on_disabled_port.patch
> target/linux/generic/patches-4.8/640-bridge_no_eap_forward.patch
> target/linux/generic/patches-4.8/641-bridge_always_accept_eap.patch
I have to add Alvaro for this (I'm using his experimental 4.8-rc series
which he is using for his raspberrypi 3 code). As for which one causes 
the issue: I think 640-bridge_no_eap_forward.patch is the one. It looks
like the following patch in 4.8. changed the way the skb and skb2 works:

commit b35c5f632b630183396a2ea2e2247ff8bbf2c94f
Author: Nikolay Aleksandrov 
Date:   Thu Jul 14 06:10:01 2016 +0300

net: bridge: drop skb2/skb0 variables and use a local_rcv boolean [0]

Looking at this commit and the original patch [1]: 
I think we can drop the skb = NULL there (and maybe put the comment
in front of the local_rcv = true;)

> I'm also seeing rather fast memory leak/wastage when wireless devices
> are up - takes 10-15 min to run out of memory. I tried using kmemleak,
> but it doesn't report any suspected leaks. I guess I'll try some
> tracing next.
I've added a few new patches to mac80211-package from the current
wireless-testing.git. If the issue persists, can you report this to
the ath10k-devel mailing list? 

Note: You should check, if it's really the ath10k driver. This can
be done by plugging in a usb-wifi device and setting it up. If it
also fails then there's probably another issue with the patchset.

Regards,
Christian

[0] 


[1] 


config-4.8.xz
Description: application/xz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] [RFC] target: armvirt: new target

2016-11-28 Thread Christian Lamparter
On Saturday, November 26, 2016 11:08:30 AM CET Yousong Zhou wrote:
> On 26/11/2016, Christian Lamparter  wrote:
> > On Saturday, November 26, 2016 12:43:38 AM CET Yousong Zhou wrote:
> > So, given that information: Selecting just neon would automatically mean:
> > neon and vfpv4... However, Since the build-script isn't that clever it
> > will make an extra target and the phase2 builder would essentially build
> > the same stuff twice.
> >
> > (the older A9 and A8 had neon-vfpv3 tops [2] - but they can be a different
> > subtarget.)
> 
> That neon in FEATURES will be used to form gcc flag -mfpu=neon which
> according to gcc doc is an alias for -mfpu=neon-vfpv3, so I guess
> that's why neon and neon-vfpv4 are built separately.
"NEON" is an alias for "Advanced SIMD". ARM updated Advanced SIMD for 
the Cortex-A7 and A15 chips called it "Advanced SIMDv2" (they added
FMA and half-precision). So from that perspective it makes sense to
map fpu=neon to neon-vfpv3... but also have the neon-vfpv4 (for 
A7, A15, +++)

> >> The allwinner-a20 soc (dual-core cortex-a7) on cubieboard2 is also
> >> capable
> >> of neon-vfpv4 and I just assembled a small binary with ".fpu neon-vfpv4"
> >> from gas testsuite and it runs to end just fine with accel=kvm.  It
> >> should
> >> also work with accel=tcg as qemu can provide the emulation.  But I am not
> >> sure how it will work out with accel=kvm on a hardware without
> >> neon-vfpv4...
> >
> > I think the best idea would to make it like the brcm2708 targets and
> > have multiple subtargets each with different CPU_TYPE and CPU_SUBTYPEs.
> >
> > This is mainly because the RPI, RPI2 and now the RPI3 had all very
> > different
> > CPUs (RPI1 had a ARMv6 with just vfp, the RPI2 had an A7 with neon-vfpv4
> > and
> > the RPI3 had A53 with everything as well).
> >
> > So looking at , There are
> > already existing targets that compile:
> > A5 (at91)
> > A7 (Mediatek ARM? - really no features?)
> > A7-neon-vfpv4 (RPI2/bcm2709, (ipq4xxx))
> > A8-vfpv3 (sunxi(Allwinner A1X/A20/A3x),
> > A9 (layerscape)
> > A9-neon (zynq,imx6)
> > A9-vfpv3 (omap,mvebu)
> > A15-neon-vfpv4 (ipq806x)
> > A53-neon-vfpv4 (RPI3/bcm2710 (in the making))
> >
> 
> This list can be compacted a liitle to lift more burden on buildbots,
> e.g. -mtune only for a7, a15, a53
I've already posted a patch to the ML that set neon-vfpv4 for the MediaTek ARM.
Another candidate should be the layerscape platform (A9-neon?). omap could be
moved to the A9-Neon too. However the mvebu can't (The old Armada-370 doesn't
support NEON, but all other do.).

As for the armvirt target: If you only want to stick with a single target,
I think the A7 would be a better pick for the ARMv7... Not that it changes
much.
 
> >> I will provide a updated patch in the following days.
> > I very much like the idea. Getting kvm on arm and lede/openwrt is a bit
> > clunky.
> > Do you know of any qemu+kvm packages for openwrt/lede? Or should we try our
> >
> > hands at it?
> >
> 
> I opened a pr about qemu few days ago:
> https://github.com/openwrt/packages/pull/3550 .  I am going to disable
> a few features explicitly, otherwise it may fail when built by
> buildbots
Thanks, that's very useful. 

Regards,
Christian


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


Re: [LEDE-DEV] Fwd: [PATCH] ath9k: Add airtime fairness scheduler

2016-11-28 Thread John Crispin


On 28/11/2016 14:58, bart van zoest wrote:
> Hi Weedy and Toke,
> 
> I am trying to apply the patch using: "curl
> https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v". Is the
> following output normal?
> 
> :60: trailing whitespace.
>  :65: trailing whitespace.
>  :67: space before tab in indent.
>  bool has_queued;
> :69: trailing whitespace.
>  :74: space before tab in indent.
>  struct ath_softc *sc;
> Checking patch 
> package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch...
> Applied patch 
> package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
> cleanly.
> warning: squelched 152 whitespace errors
> warning: 157 lines add whitespace errors.

these types of messages are nortmal as you are applying a patch that
adds a patch which will be applied during build.

John

> 
> On Sun, Nov 27, 2016 at 12:08 PM, Weedy  wrote:
>>
>> On Fri, Nov 25, 2016 at 5:16 AM, Toke Høiland-Jørgensen  wrote:
>>> This adds a patch that introduces airtime fairness scheduling to ath9k,
>>> which can significantly improve network efficiency in mixed-rate
>>> environments.
>> ...
>>> ++  astats = >airtime_stats;
>>> ++
>>> ++  len += scnprintf(buf + len, size - len, "RX: %u us\n", 
>>> astats->rx_airtime);
>>> ++  len += scnprintf(buf + len, size - len, "TX: %u us\n", 
>>> astats->tx_airtime);
>>> ++  len += scnprintf(buf + len, size - len, "Deficit: ");
>>> ++  for (i = 0; i < 4; i++)
>>> ++  len += scnprintf(buf+len, size - len, "%s: %lld us ", 
>>> qname[i], an->airtime_deficit[i]);
>>> ++  if (len < size)
>>> ++  buf[len++] = '\n';
>>> ++
>>> ++  retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
>>> ++  kfree(buf);
>>> ++
>>> ++  return retval;
>>> ++}
>>
>> I'm supposed to have a
>> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/something/airtime
>> right?
>> Should I have done anything else besides:
>> # curl https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v
>> # make V=s package/mac80211/{clean,install}
>> Applying ./patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
>> using plaintext:
>> patching file drivers/net/wireless/ath/ath9k/ath9k.h
>> patching file drivers/net/wireless/ath/ath9k/channel.c
>> patching file drivers/net/wireless/ath/ath9k/debug.c
>> patching file drivers/net/wireless/ath/ath9k/debug.h
>> patching file drivers/net/wireless/ath/ath9k/debug_sta.c
>> patching file drivers/net/wireless/ath/ath9k/init.c
>> patching file drivers/net/wireless/ath/ath9k/main.c
>> patching file drivers/net/wireless/ath/ath9k/recv.c
>> patching file drivers/net/wireless/ath/ath9k/xmit.c
>>
>> # 
>>
>> Sat Nov 26 16:39:31 2016 kern.warn kernel: [   11.595812] PCI:
>> Enabling device :00:11.0 ( -> 0002)
>> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.606388] ath: phy0:
>> Ignoring endianness difference in EEPROM magic bytes.
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614943] ath: EEPROM
>> regdomain: 0x0
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614952] ath: EEPROM
>> indicates default country code should be used
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614960] ath: doing
>> EEPROM country->regdmn map search
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614975] ath:
>> country maps to regdmn code: 0x3a
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614985] ath:
>> Country alpha2 being used: US
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614993] ath:
>> Regpair used: 0x3a
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.628327] ieee80211
>> phy0: Selected rate control algorithm 'minstrel_ht'
>> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.632241] ieee80211
>> phy0: Atheros AR9280 Rev:2 mem=0xb000, irq=40
>> Sat Nov 26 16:39:31 2016 kern.warn kernel: [   11.697119] PCI:
>> Enabling device :00:12.0 ( -> 0002)
>> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.707690] ath: phy1:
>> Ignoring endianness difference in EEPROM magic bytes.
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716278] ath: EEPROM
>> regdomain: 0x0
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716289] ath: EEPROM
>> indicates default country code should be used
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716297] ath: doing
>> EEPROM country->regdmn map search
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716313] ath:
>> country maps to regdmn code: 0x3a
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716322] ath:
>> Country alpha2 being used: US
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716330] ath:
>> Regpair used: 0x3a
>> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.731825] ieee80211
>> phy1: Selected rate control algorithm 'minstrel_ht'
>> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.735844] ieee80211
>> phy1: Atheros AR9280 Rev:2 mem=0xb001, irq=41
>>
>> I can't 

Re: [LEDE-DEV] [PATCH] ath9k: Add airtime fairness scheduler

2016-11-28 Thread Toke Høiland-Jørgensen
bart van zoest  writes:

> Hi Weedy and Toke,
>
> I am trying to apply the patch using: "curl 
> https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v". Is the 
> following output normal?
>
> :60: trailing whitespace.
>  :65: trailing whitespace.
>  :67: space before tab in indent.
>  bool has_queued;
> :69: trailing whitespace.
>  :74: space before tab in indent.
>  struct ath_softc *sc;
> Checking patch 
> package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch...
> Applied patch 
> package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
>  cleanly.
> warning: squelched 152 whitespace errors
> warning: 157 lines add whitespace errors.

Looks like curl is mangling the whitespace. Don't think it matters; if
the mac80211 package still compiles you are probably fine :)

-Toke

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


[LEDE-DEV] [PATCH v2] ath9k: Add airtime fairness scheduler.

2016-11-28 Thread Toke Høiland-Jørgensen
This adds a patch that introduces airtime fairness scheduling to ath9k,
which can significantly improve network efficiency in mixed-rate
environments.

Signed-off-by: Toke Høiland-Jørgensen 
---
 ...h9k-Introduce-airtime-fairness-scheduling.patch | 691 +
 1 file changed, 691 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch

diff --git 
a/package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
 
b/package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
new file mode 100644
index 000..ca5c4f3
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
@@ -0,0 +1,691 @@
+From 4c43e1f3cae4c26198a8125123c239a4cdccad3f Mon Sep 17 00:00:00 2001
+In-Reply-To: <20160617090929.31606-1-t...@toke.dk>
+References: <20160617090929.31606-1-t...@toke.dk>
+From: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= 
+Date: Wed, 22 Jun 2016 13:48:14 +0200
+Subject: [PATCH v3] ath9k: Introduce airtime fairness scheduling between
+ stations
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This reworks the ath9k driver to schedule transmissions to connected
+stations in a way that enforces airtime fairness between them. It
+accomplishes this by measuring the time spent transmitting to or
+receiving from a station at TX and RX completion, and accounting this to
+a per-station, per-QoS level airtime deficit. Then, an FQ-CoDel based
+deficit scheduler is employed at packet dequeue time, to control which
+station gets the next transmission opportunity.
+
+Airtime fairness can significantly improve the efficiency of the network
+when station rates vary. The following throughput values are from a
+simple three-station test scenario, where two stations operate at the
+highest HT20 rate, and one station at the lowest, and the scheduler is
+employed at the access point:
+
+  Before   /   After
+Fast station 1:19.17   /   25.09 Mbps
+Fast station 2:19.83   /   25.21 Mbps
+Slow station:   2.58   /1.77 Mbps
+Total: 41.58   /   52.07 Mbps
+
+The benefit of airtime fairness goes up the more stations are present.
+In a 30-station test with one station artificially limited to 1 Mbps,
+we have seen aggregate throughput go from 2.14 to 17.76 Mbps.
+
+Signed-off-by: Toke Høiland-Jørgensen 
+---
+Changes since v2:
+  - Just call spin_*lock_bh() instead of introducing ath_acq_*lock()
+functions.
+
+ drivers/net/wireless/ath/ath9k/ath9k.h |  25 +++-
+ drivers/net/wireless/ath/ath9k/channel.c   |  14 ++-
+ drivers/net/wireless/ath/ath9k/debug.c |   3 +
+ drivers/net/wireless/ath/ath9k/debug.h |  13 +++
+ drivers/net/wireless/ath/ath9k/debug_sta.c |  54 +
+ drivers/net/wireless/ath/ath9k/init.c  |   2 +
+ drivers/net/wireless/ath/ath9k/main.c  |   6 +-
+ drivers/net/wireless/ath/ath9k/recv.c  |  65 +++
+ drivers/net/wireless/ath/ath9k/xmit.c  | 177 +
+ 9 files changed, 303 insertions(+), 56 deletions(-)
+
+diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
+index 378d345..79e4b71 100644
+--- a/drivers/net/wireless/ath/ath9k/ath9k.h
 b/drivers/net/wireless/ath/ath9k/ath9k.h
+@@ -112,6 +112,8 @@ int ath_descdma_setup(struct ath_softc *sc, struct 
ath_descdma *dd,
+ #define ATH_TXFIFO_DEPTH   8
+ #define ATH_TX_ERROR   0x01
+ 
++#define ATH_AIRTIME_QUANTUM300 /* usec */
++
+ /* Stop tx traffic 1ms before the GO goes away */
+ #define ATH_P2P_PS_STOP_TIME   1000
+ 
+@@ -247,6 +249,9 @@ struct ath_atx_tid {
+   bool has_queued;
+ };
+ 
++void __ath_tx_queue_tid(struct ath_softc *sc, struct ath_atx_tid *tid);
++void ath_tx_queue_tid(struct ath_softc *sc, struct ath_atx_tid *tid);
++
+ struct ath_node {
+   struct ath_softc *sc;
+   struct ieee80211_sta *sta; /* station struct we're part of */
+@@ -258,9 +263,12 @@ struct ath_node {
+ 
+   bool sleeping;
+   bool no_ps_filter;
++  s64 airtime_deficit[IEEE80211_NUM_ACS];
++  u32 airtime_rx_start;
+ 
+ #ifdef CPTCFG_ATH9K_STATION_STATISTICS
+   struct ath_rx_rate_stats rx_rate_stats;
++  struct ath_airtime_stats airtime_stats;
+ #endif
+   u8 key_idx[4];
+ 
+@@ -317,10 +325,16 @@ struct ath_rx {
+ /* Channel Context */
+ /***/
+ 
++struct ath_acq {
++  struct list_head acq_new;
++  struct list_head acq_old;
++  spinlock_t lock;
++};
++
+ struct ath_chanctx {
+   struct cfg80211_chan_def chandef;
+   struct list_head vifs;
+-  struct list_head acq[IEEE80211_NUM_ACS];
++  struct ath_acq acq[IEEE80211_NUM_ACS];
+   int hw_queue_base;
+ 
+   /* do not dereference, use for comparison only */
+@@ -575,6 +589,8 @@ void ath_txq_schedule_all(struct 

[LEDE-DEV] Fwd: [PATCH] ath9k: Add airtime fairness scheduler

2016-11-28 Thread bart van zoest
Hi Weedy and Toke,

I am trying to apply the patch using: "curl
https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v". Is the
following output normal?

:60: trailing whitespace.
 :65: trailing whitespace.
 :67: space before tab in indent.
 bool has_queued;
:69: trailing whitespace.
 :74: space before tab in indent.
 struct ath_softc *sc;
Checking patch 
package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch...
Applied patch 
package/kernel/mac80211/patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
cleanly.
warning: squelched 152 whitespace errors
warning: 157 lines add whitespace errors.

On Sun, Nov 27, 2016 at 12:08 PM, Weedy  wrote:
>
> On Fri, Nov 25, 2016 at 5:16 AM, Toke Høiland-Jørgensen  wrote:
> > This adds a patch that introduces airtime fairness scheduling to ath9k,
> > which can significantly improve network efficiency in mixed-rate
> > environments.
> ...
> > ++  astats = >airtime_stats;
> > ++
> > ++  len += scnprintf(buf + len, size - len, "RX: %u us\n", 
> > astats->rx_airtime);
> > ++  len += scnprintf(buf + len, size - len, "TX: %u us\n", 
> > astats->tx_airtime);
> > ++  len += scnprintf(buf + len, size - len, "Deficit: ");
> > ++  for (i = 0; i < 4; i++)
> > ++  len += scnprintf(buf+len, size - len, "%s: %lld us ", 
> > qname[i], an->airtime_deficit[i]);
> > ++  if (len < size)
> > ++  buf[len++] = '\n';
> > ++
> > ++  retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
> > ++  kfree(buf);
> > ++
> > ++  return retval;
> > ++}
>
> I'm supposed to have a
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/something/airtime
> right?
> Should I have done anything else besides:
> # curl https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v
> # make V=s package/mac80211/{clean,install}
> Applying ./patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
> using plaintext:
> patching file drivers/net/wireless/ath/ath9k/ath9k.h
> patching file drivers/net/wireless/ath/ath9k/channel.c
> patching file drivers/net/wireless/ath/ath9k/debug.c
> patching file drivers/net/wireless/ath/ath9k/debug.h
> patching file drivers/net/wireless/ath/ath9k/debug_sta.c
> patching file drivers/net/wireless/ath/ath9k/init.c
> patching file drivers/net/wireless/ath/ath9k/main.c
> patching file drivers/net/wireless/ath/ath9k/recv.c
> patching file drivers/net/wireless/ath/ath9k/xmit.c
>
> # 
>
> Sat Nov 26 16:39:31 2016 kern.warn kernel: [   11.595812] PCI:
> Enabling device :00:11.0 ( -> 0002)
> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.606388] ath: phy0:
> Ignoring endianness difference in EEPROM magic bytes.
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614943] ath: EEPROM
> regdomain: 0x0
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614952] ath: EEPROM
> indicates default country code should be used
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614960] ath: doing
> EEPROM country->regdmn map search
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614975] ath:
> country maps to regdmn code: 0x3a
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614985] ath:
> Country alpha2 being used: US
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614993] ath:
> Regpair used: 0x3a
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.628327] ieee80211
> phy0: Selected rate control algorithm 'minstrel_ht'
> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.632241] ieee80211
> phy0: Atheros AR9280 Rev:2 mem=0xb000, irq=40
> Sat Nov 26 16:39:31 2016 kern.warn kernel: [   11.697119] PCI:
> Enabling device :00:12.0 ( -> 0002)
> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.707690] ath: phy1:
> Ignoring endianness difference in EEPROM magic bytes.
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716278] ath: EEPROM
> regdomain: 0x0
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716289] ath: EEPROM
> indicates default country code should be used
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716297] ath: doing
> EEPROM country->regdmn map search
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716313] ath:
> country maps to regdmn code: 0x3a
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716322] ath:
> Country alpha2 being used: US
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716330] ath:
> Regpair used: 0x3a
> Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.731825] ieee80211
> phy1: Selected rate control algorithm 'minstrel_ht'
> Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.735844] ieee80211
> phy1: Atheros AR9280 Rev:2 mem=0xb001, irq=41
>
> I can't seem to tell if I have the patched driver loaded. Unless
> rc_stats counts?
>   best   rate__
> statisticslast___
> __sum-of
> mode guard #  rate  [name   idx airtime  max_tp]  [avg(tp) avg(prob)
> sd(prob)]  

Re: [LEDE-DEV] [PATCH] ath9k: Add airtime fairness scheduler

2016-11-28 Thread Toke Høiland-Jørgensen
Weedy  writes:

> On Mon, Nov 28, 2016 at 4:49 AM, Toke Høiland-Jørgensen  wrote:
>> Right, that means that the patch was applied correctly. That you don't
>> have the per-station airtime stats file is probably a configuration
>> issue, then. Did you set CONFIG_PACKAGE_ATH_DEBUG?
>>
>> What's the output of
>>
>> grep STATION_STATISTICS 
>> build_dir/target-mips_24kc_musl-1.1.15/linux-ar71xx_generic/compat-wireless-2016-10-08/.config
>>
>>
>> (substitute the right build dir if you are building with a different
>> musl version).
>
> I didn't know I had to change anything.

You don't for the patch to function. Just for the stats.

> If this a RFC or a done deal? Should I enable more debugging a post
> results, or it the fact my WiFi still works enough to get this merged?

As far as I'm concerned, this is ready for inclusion. Though the people
with merge rights may disagree, of course. :)

I did get a minor issue pointed out to me on linux-wireless, will
re-send the LEDE patch with the fix in a bit...

-Toke

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


Re: [LEDE-DEV] [PATCH] ath9k: Add airtime fairness scheduler

2016-11-28 Thread Weedy
On Mon, Nov 28, 2016 at 4:49 AM, Toke Høiland-Jørgensen  wrote:
> Right, that means that the patch was applied correctly. That you don't
> have the per-station airtime stats file is probably a configuration
> issue, then. Did you set CONFIG_PACKAGE_ATH_DEBUG?
>
> What's the output of
>
> grep STATION_STATISTICS 
> build_dir/target-mips_24kc_musl-1.1.15/linux-ar71xx_generic/compat-wireless-2016-10-08/.config
>
>
> (substitute the right build dir if you are building with a different
> musl version).

I didn't know I had to change anything.

If this a RFC or a done deal? Should I enable more debugging a post
results, or it the fact my WiFi still works enough to get this merged?

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


Re: [LEDE-DEV] [PATCH] ath9k: Add airtime fairness scheduler

2016-11-28 Thread Toke Høiland-Jørgensen
Weedy  writes:

> On Sun, Nov 27, 2016 at 11:01 AM, Toke Høiland-Jørgensen  wrote:
>> Weedy  writes:
>>
>>> On Fri, Nov 25, 2016 at 5:16 AM, Toke Høiland-Jørgensen  
>>> wrote:
 This adds a patch that introduces airtime fairness scheduling to ath9k,
 which can significantly improve network efficiency in mixed-rate
 environments.
>>> ...
 ++  astats = >airtime_stats;
 ++
 ++  len += scnprintf(buf + len, size - len, "RX: %u us\n", 
 astats->rx_airtime);
 ++  len += scnprintf(buf + len, size - len, "TX: %u us\n", 
 astats->tx_airtime);
 ++  len += scnprintf(buf + len, size - len, "Deficit: ");
 ++  for (i = 0; i < 4; i++)
 ++  len += scnprintf(buf+len, size - len, "%s: %lld us ", 
 qname[i], an->airtime_deficit[i]);
 ++  if (len < size)
 ++  buf[len++] = '\n';
 ++
 ++  retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
 ++  kfree(buf);
 ++
 ++  return retval;
 ++}
>>>
>>> I'm supposed to have a
>>> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/something/airtime
>>> right?
>>
>> Yeah, you should. Do you have
>> /sys/kernel/debug/ieee80211/phy0/ath9k/airtime_flags ?
>
> Yes I do. It's set to 7

Right, that means that the patch was applied correctly. That you don't
have the per-station airtime stats file is probably a configuration
issue, then. Did you set CONFIG_PACKAGE_ATH_DEBUG?

What's the output of

grep STATION_STATISTICS 
build_dir/target-mips_24kc_musl-1.1.15/linux-ar71xx_generic/compat-wireless-2016-10-08/.config


(substitute the right build dir if you are building with a different
musl version).

-Toke

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


Re: [LEDE-DEV] replacing files in base system from a package?

2016-11-28 Thread Zefir Kurtisi
On 11/25/2016 08:14 AM, Rafał Miłecki wrote:
> On 16 October 2016 at 01:04, Jo-Philipp Wich  wrote:
>> let me introduce a not strictly new way but another heavily under
>> documented buildroot feature which you can use to implement custom
>> modifications to packages which do not require source code edits.
>>
>> For every processed package Makefile, the buildroot tries to include a a
>> Makefile fragment in $(TOPDIR)/overlay/*/$(PKG_DIR_NAME).mk which one
>> can use to monkey-patch internals without directly touching the package
>> recipes.
>>
>> For example to amend "base-files" to include a custom banner and
>> inittab, you could create an overlay file called
>>
>>   "overlay/my-example-organization/base-files.mk"
>>
>> which extends the default Package/base-files/install recipe to copy your
>> custom files in the end.
> 
> I'm not exactly sure what's the gain from using this method. Normally
> I need to fork LEDE repo and modify package/base-files/Makefile. With
> your solution I need to fork LEDE repo and add
> overlay/my-example-organization/base-files.mk. Both cases require
> forking LEDE, maybe with overlay it's just easier to track
> my-example-organization changes if you can't use git.
> 
> I think a perfect model for organization/company that wants to be LEDE
> friendly would be to:
> 1) Ask them for complete LEDE-upstream support for their device
> 2) Handle all modifications using an own feed with their packages
> 
> This is a pretty clean situation when we know no extra
> kernel/main-packages modifications are needed to get device working.
> I'd expect overwriting e.g. banner to happen withing sth like
> my-example-organization-base-files package.
> 
> 
We had the approach you describe for a long time (company-basefiles adding to 
and
overwriting files in base-files package), but this does not work any more. With
recent build-system changes you can't have the same rootfs file in two different
packages (build step fails). Which is good and sane - otherwise you run into
inconsistencies when base-files is installed after company-basefiles.

This overlay approach makes sense for our case, where the things we overwrite 
are
not common (or good) enough to get them upstream.

Ideally the build-system would also support per-package overlay patches to keep
upstream packages completely untouched - something I looked into but did not get
working so far.


Cheers,
Zefir


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


Re: [LEDE-DEV] enhanced 3G support

2016-11-28 Thread Matti Laakso
Hi,

> Dear All,
> I currently add supprt for the dwr-512 device on LEDE.
> This device have a 3G modem embedded.
> The current available configuration uses the usb-option to establish the 3G
> connection over ppp.
> Nevertheless the modem offer one cdc-ether interface with better
> performance.
>
> It seems to me that currently this kind of "protocol" is not supported in
> LEDE.
> In particular I'm unable to found an interface type in the
> /etc/config/network to setup this kind of connection.
>
> Currently I'm able to establish a connection setting the interface in
> "manual" mode.
>
> To do this I setup an usb interface
>
> config interface 'wan3g'
> option ifname 'usb0'
> option proto 'dhcp'
>
> then I need to send manually the following command to the /dev/ttyUSB0 to
> establish the 3G connection:

Please use the existing ncm protocol for this. It shouldn't matter that the 
actual module used is cdc_ether instead of cdc_ncm. You just need to add the 
correct commands to the ncm.json file under a new object with the manufacturer 
name that is taken from the output of the ATI-command. I can help you with the 
details if needed. I would assume that the AT-commands with the question mark 
at the end are not actually needed to bring this online?

Best regards,
Matti

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