If you have a current CC build tree, then use that but replace package/kernel/mwlwifi/Makefile with the current trunk version: http://git.openwrt.org/?p=openwrt.git;a … 50d2a980c5

Remove any other files in package/kernel/mwlwifi/.  They are not needed for CC.

Then build as usual:
make V=s package/mwlwifi/install

copy the resulting package from  bin/mvebu/packages/base/ or wherever your build is configured to put them, and install with opkg.

If you want to build for the official CC, then
a) download the SDK:
wget http://downloads.openwrt.org/chaos_calm … 64.tar.bz2
b) unpack SDK:
  tar jxvf OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64.tar.bz2
c) create the mwlwifi package
  cd OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64
  mkdir -p package/kernel/mwlwifi
  wget 'http://git.openwrt.org/?p=openwrt.git;a … 50d2a980c5' -O package/kernel/mwlwifi/Makefile
d) build it
make V=s package/mwlwifi/install
e) install
  scp bin/mvebu/packages/base/kmod-mwlwifi_3.18.20+10.3.0.12-20151029-1_mvebu.ipk root@yourwrt:/tmp/
  ssh root@yourwrt
  opkg install /tmp/kmod-mwlwifi_3.18.20+10.3.0.12-20151029-1_mvebu.ipk

Make sure you know how failsafe works
Reboot!

(It should be possible to do rmmod + insmod instead of reboot, but the driver currently fails to clean up properly on rmmod so that's eventually going to crash.)

EDIT:
and since I just did that to verify my recipe, I might as well put the package up for download in case you are among those trusting random binaries from the Internet

This should work with the official CC image, but there is no guarantee.  It's completely untested:
http://openwrt.mork.no/chaos_calmer/15. … _mvebu.ipk

(Last edited by bmork on 29 Oct 2015, 15:54)

Thanks. I'm going to try that now.

Do I need to rebuild the mac80211 as well? When I try to build it I have the following error:

/home/dex/OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64/build_dir/target-arm_cortex-a9+vfpv3_uClibc-0.9.33.2_eabi/linux-mvebu/compat-wireless-2015-03-09/include/linux/ath9k_platform.h /home/dex/OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64/build_dir/target-arm_cortex-a9+vfpv3_uClibc-0.9.33.2_eabi/linux-mvebu/linux-3.18.20/include/linux/ath9k_platform.h differ: char 1349, line 44
Makefile:2031: recipe for target '/home/dex/OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64/build_dir/target-arm_cortex-a9+vfpv3_uClibc-0.9.33.2_eabi/linux-mvebu/compat-wireless-2015-03-09/.configured_yyyyyyyynyyyyyyyyyyyynyyyyyyyyyyyyyyyyyyyynyyyynnnyyyyyyyyyyynynnyyyyynnnnyyn' failed
make[2]: *** [/home/dex/OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64/build_dir/target-arm_cortex-a9+vfpv3_uClibc-0.9.33.2_eabi/linux-mvebu/compat-wireless-2015-03-09/.configured_yyyyyyyynyyyyyyyyyyyynyyyyyyyyyyyyyyyyyyyynyyyynnnyyyyyyyyyyynynnyyyyynnnnyyn] Error 1
make[2]: Leaving directory '/home/dex/OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64/package/kernel/mac80211'
package/Makefile:191: recipe for target 'package/kernel/mac80211/compile' failed
make[1]: *** [package/kernel/mac80211/compile] Error 2
make[1]: Leaving directory '/home/dex/OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64'
/home/dex/OpenWrt-SDK-15.05-mvebu_gcc-4.8-linaro_uClibc-0.9.33.2_eabi.Linux-x86_64/include/toplevel.mk:174: recipe for target 'package/mac80211/compile' failed
make: *** [package/mac80211/compile] Error 2

Any clues?

(Last edited by i.trankolov on 29 Oct 2015, 16:46)

OK, it doesn't work quite as perfect as we wished for.  I expected the 0c:8b:fd:08:09:71 client (Intel 7260ac, Linux 4.3-rc7) to get A-MSDU support, while the two others should probably not get it.  5c:0a:5b:79:ae:68 is the Galaxy S3 with problems in 10.3.0.10.  But none of them had BIT(0) set  in the addba.resp.capab:

[ 3688.592193] mwl_rx_recv: ieee80211 phy0: c4:42:02:e2:8c:f3 - addba.resp.capab=0x802
[ 8398.001127] mwl_rx_recv: ieee80211 phy0: 5c:0a:5b:79:ae:68 - addba.resp.capab=0x202
[10097.335747] mwl_rx_recv: ieee80211 phy0: 0c:8b:fd:08:09:71 - addba.resp.capab=0x1002
[11268.034546] mwl_rx_recv: ieee80211 phy0: 5c:0a:5b:79:ae:68 - addba.resp.capab=0x202
root@wrt1900ac-1:~# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/sta 

mac address: 0c:8b:fd:08:09:71
aid: 3
ampdu: true
amsdu: false
IV: 00000000541c

mac address: 5c:0a:5b:79:ae:68
aid: 2
ampdu: true
amsdu: false
IV: 0000000013a2

root@wrt1900ac-1:~# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/ampdu 

stream: 0
idx: 0
state: 3
mac address: 0c:8b:fd:08:09:71
tid: 0
stream: 1
idx: 1
state: 3
mac address: 5c:0a:5b:79:ae:68
tid: 0
stream: 2
idx: 0
state: 0
stream: 3
idx: 0
state: 0

Oh, well.  Don't have time to look into this now.  But there seems to be more work to do.

No need to worry, though.  This is just minor optimizations.  The driver still works with any client, and I believe it will be faster than any pre-amsdu version in any case.

If you are building a DD-trunk image, the wireless driver needs a patch file. it might be that is your issue.

Because of stability and ease of installation of additional packages i'd strongly recommend not to install a trunk release, but the final CC-release.

i must admit that your quick fix feels more stable and better performing than this new driver.
The quickfix also only showed ampsdu disabled where i wanted it (the 2012 mac), while now it shows disabled on about every device i have. Am a bit puzzled about it, and still doubting myself if i'm not seeing ghosts.

Still no word on a new wireless driver..?

10.3.0.12 came out 15 hours ago,

Changelog:

Haven't check if it's been updated on trunk or CC but will compile on CC branch when you edit the Makefile and remove the patch inside the mwlwifi folder. Apparently this update fixed the slows speeds seen by some people by turning off AMSDU until mac80211 on openwrt is brought up to date with a key API needed.

I assume its aimed to also fix the issue with Apple devices? I'll wait till this gets pushed to trunk. How long does that usually take, few days, hours?  thanks

10.3.0.12 is broken in my device. Soft IRQ 100% CPU usage. Hangs at 15-20 minute intervals.

(Last edited by i.trankolov on 29 Oct 2015, 22:28)

10.3.0.12 had been tested with macbook air, macbook pro and some clients without AMSDU support. Previous two will get tx AMSDU enable.  Current mac80211 only supports the way to parse AMSDU for received packets. The way done by mwlwifi is enable bit 0 of capability of ADDBA response to enable AMSDU for rx. The driver will also enable bit 0 of capability of ADDBA request to inform client we have tx AMSDU capability, if client follows specification, it will inform us it has rx AMSDU capability, so mwlwifi driver will enable tx AMSDU.

(Last edited by dlin on 29 Oct 2015, 22:50)

The router hangs every 15-20 min?

Well not hangs, but reboots. With 10.3.0.3 it was stable for the last 12 days.

did you replace the whole image, or just copied over the driver?
i'm running 13.3.0.12 for about 12 hours now, and do not see any real "hang" issues.

after tiremeats advice i do recompile the whole image every time, to minimize any chance of issues.

[offtopic to your issue]
The driver is certainly not perfect yet:
- what i see is that my iphone 5 is suddenly quicker in uploading than downloading (65mbit up, 30 mbit down on 40mbit 5ghz), and that is a bit strange.
- ssh sessions to the router freeze very often for a couple of seconds (still not sure if that is related to the driver).

speedtest from the mid 2012 macbook air however show a decent >100mbit speed when downloading things

I've managed to compile my own, but I downloaded yours just to compare the files and I found a difference. Yours is bigger in size (mwlwifi.ko). It may be because of the paths used when compiling, but I am not sure.

PS> Yep your build path is longer than mine.

(Last edited by i.trankolov on 29 Oct 2015, 22:58)

I've replaced the driver only. I don't want to replace the image, because mine has a lot of customizations and I don't want to loose them. If there is a fast way to preserve all modified files, I will recompile the whole image.

One question - you're building latest trunk, or CC-15.05 with the new driver?

The build path will be included in a numer of strings, so that will cause some difference.   I don't know anything else that should matter.   So there shouldn't be big differences.  Only a few bytes hopefully?

I have build and currently am testing with latest trunk. But now have a complete build for CC-15.05 as well.
just don't want to flash back to it already, as i first want to test the stability of the driver a bit longer.

The fix I added would not disable A-MSDU until an A-MPDU stream was started.  So that explains why you still see some clients with A-MSDU enabled with my patch.  But those clients cannot need much bandwidth, so this doesn't make any difference in practice.

As for better performing: I don't think so.  The driver has the same softirq performance issues with my patch too.  I believe it's due to mwl_tx_flush_amsdu() being called in a really tight loop.  But I don't think I fully understand the design here... Looks like the driver is constantly looping over the amsdu_frag list for every client just to check whether it's time to transmit it.  Like, what's wrong about timers?  Probably lots of stuff.  I just don't understand it, as I said..  But there must be smarter ways to do this.

FWIW, I have some experience with the cdc_ncm driver, which use timers to expire its aggregation.  Not a perfect design either, but at least it doesn't cause a gazillion softirqs

ok... maybe i do see ghosts then...
How is the wifi-performance for you, especially on the Samsung phone you where testing with?

I have no idea how to test that, and I wouldn't have anything to compare it with as I've never tested it before.  It feels "OK".

As for my Linux laptop, it's up to 150 Mbits/s up and 280 Mbits/s down.  Which probably confirms your gut feeling - I have seen better.

bjorn@nemi:~$ iperf -V -i 5 -t 60 -c canardo
------------------------------------------------------------
Client connecting to canardo, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 2001:4641:0:2:e8b:fdff:fe08:971 port 43754 connected with 2001:4641::1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  74.2 MBytes   125 Mbits/sec
[  3]  5.0-10.0 sec  66.2 MBytes   111 Mbits/sec
[  3] 10.0-15.0 sec  63.9 MBytes   107 Mbits/sec
[  3] 15.0-20.0 sec  73.4 MBytes   123 Mbits/sec
[  3] 20.0-25.0 sec  80.1 MBytes   134 Mbits/sec
[  3] 25.0-30.0 sec  79.4 MBytes   133 Mbits/sec
[  3] 30.0-35.0 sec  82.9 MBytes   139 Mbits/sec
[  3] 35.0-40.0 sec  88.6 MBytes   149 Mbits/sec
[  3] 40.0-45.0 sec  90.4 MBytes   152 Mbits/sec
[  3] 45.0-50.0 sec  80.1 MBytes   134 Mbits/sec
[  3] 50.0-55.0 sec  75.2 MBytes   126 Mbits/sec
[  3] 55.0-60.0 sec  75.8 MBytes   127 Mbits/sec
[  3]  0.0-60.0 sec   930 MBytes   130 Mbits/sec

bjorn@canardo:~$ iperf -V -t 60 -i 5 -c nemi
------------------------------------------------------------
Client connecting to nemi, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  3] local 2001:4641:0:2::1 port 52539 connected with 2001:4641:0:2:e8b:fdff:fe08:971 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec   161 MBytes   271 Mbits/sec
[  3]  5.0-10.0 sec   171 MBytes   287 Mbits/sec
[  3] 10.0-15.0 sec   164 MBytes   274 Mbits/sec
[  3] 15.0-20.0 sec   123 MBytes   206 Mbits/sec
[  3] 20.0-25.0 sec   116 MBytes   194 Mbits/sec
[  3] 25.0-30.0 sec   120 MBytes   202 Mbits/sec
[  3] 30.0-35.0 sec   126 MBytes   211 Mbits/sec
[  3] 35.0-40.0 sec  54.5 MBytes  91.4 Mbits/sec
[  3] 40.0-45.0 sec  98.6 MBytes   165 Mbits/sec
[  3] 45.0-50.0 sec   143 MBytes   240 Mbits/sec
[  3] 50.0-55.0 sec   116 MBytes   195 Mbits/sec
[  3] 55.0-60.0 sec  69.4 MBytes   116 Mbits/sec
[  3]  0.0-60.0 sec  1.43 GBytes   204 Mbits/sec

... which isn't that surprising if you bother to look at the Intel driver. Again: Emmanuel is working on this, and it looks like Linux 4.4 is the earliest we'll have this in mainline.  I'm guessing it'll be a Christmas present

The driver flag indicating support for receiving A-MSDU in A-MPDU, and related code setting the capability bit, was added to net-next a month ago.  Around the same time the tx supporting code was added:
https://git.kernel.org/cgit/linux/kerne … ca44bb910f

But the driver parts are not in yet, and my 4.3-rc7 driver is of course completely outdated

(Last edited by bmork on 29 Oct 2015, 23:54)

@bmork I see you are sporting an Intel 7260 like me. Does this card currently support AC? I tried (Ubuntu Wily)

 lshw | grep -i 'wireless'

and only get IEEE 802.11abgn with 10.3.0.3. I'm about to upgrade to 10.3.0.12.

Compiled new image against trunk earlier today softirq @34% still to high for no real load. Will have to test usb speed when I get more time.
root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy1/mwlwifi/sta

mac address: 40:e2:30:42:1c:b9
aid: 1
ampdu: true
amsdu: true
amsdu cap: 0x00
IV: 000000000532

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy1/mwlwifi/sta

mac address: 40:e2:30:42:1c:b9
aid: 1
ampdu: true
amsdu: true
amsdu cap: 0x00
IV: 000000000b34

If you see room for optimization, open an issue on the github page

Ok, the following day wifi on my Ipad air2 (802.1ac capable) was still associated with the 5ghz network, but no dataflow possible. I switched it over to the 2.4ghz side, and then it works again.

How do i debug/troubleshoot that?
Nothing is logged in the kernel or systemlog that is out of the ordinary.