nl80211: Failed to set channel

All of lore.kernel.org
 help / color / mirror / Atom feed

* nl80211: Failed to set channel
       [not found]                                     ` <008c01cf012e$e59563d0$b0c02b70$@sparklan.com>
@ 2014-02-23 21:15                                       ` Bart Jooris
  2014-02-24  8:44                                         ` Sven Schnelle
  0 siblings, 1 reply; 20+ messages in thread
From: Bart Jooris @ 2014-02-23 21:15 UTC (permalink / raw)
  To: ath10k

Dear,

I'm currently experimenting with the WPEA-351AC Sparklan cards but I'm
unable to set up an 802.11 ac link.

I followed the instructions on:
http://wireless.kernel.org/en/users/Drivers/ath10k/configuration
and ended up with an "*Could not set channel for kernel driver*" when
running hostapd.

I Googled _ath10k "nl80211: Failed to set channel"_ and found this link
<http://www.google.be/url?q=http://blog.gmane.org/gmane.linux.kernel.wireless.general/page%3D73&sa=U&ei=hl4KU8meJuaBywP-hIGACA&ved=0CCAQFjAA&usg=AFQjCNF7b2XIZ8mhtPS2TY73OzgcFxlsLw>.
So it seems that at least some one else has the same problem, but
unfortunately the server above gave up :-(
I'm not sure that I am on the right list, but maybe someone can give the
right direction?

In the mean time I'm building linux-3.13.5

Thanks in advance,

Best regards,

Bart

This is my config:

hardware:
DSS-1300 <http://www.cartft.com/catalog/il/1566> - Intel(R) Core(TM)
i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB

OS:
Ubuntu 13.10 with networkmanager in off state.

some commands:

    bjooris@DSS-1300-1:~/hostap/hostapd$ sudo lspci -k | grep -A 3 -i
    "*Wireless*"
    03:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac
    Wireless Network Adapter
    Kernel driver in use: ath10k_pci


    bjooris@DSS-1300-1:~/hostap/hostapd$ modinfo *ath10k_pci*
    filename:
    /lib/modules/3.11.0-12-generic/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
    firmware: ath10k/QCA988X/hw2.0/board.bin
    firmware: ath10k/QCA988X/hw2.0/otp.bin
    firmware: ath10k/QCA988X/hw2.0/firmware.bin
    firmware: ath10k/QCA988X/hw1.0/board.bin
    firmware: ath10k/QCA988X/hw1.0/otp.bin
    firmware: ath10k/QCA988X/hw1.0/firmware.bin
    license: Dual BSD/GPL
    description: Driver support for Atheros QCA988X PCIe devices
    author: Qualcomm Atheros
    srcversion: 851066A82059149AA86F04E
    alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
    alias: pci:v0000168Cd0000ABCDsv*sd*bc*sc*i*
    depends: ath10k_core
    intree: Y
    vermagic: 3.11.0-12-generic SMP mod_unload modversions
    parm: ath10k_target_ps:Enable ath10k Target (SoC) PS option (uint)



    bjooris@DSS-1300-1:~/hostap/hostapd$ modinfo *ath10k_core*
    filename:
    /lib/modules/3.11.0-12-generic/kernel/drivers/net/wireless/ath/ath10k/ath10k_core.ko
    license: Dual BSD/GPL
    description: Core module for QCA988X PCIe devices.
    author: Qualcomm Atheros
    srcversion: 2018AB1EB57597874B1D026
    depends: cfg80211,mac80211,ath
    intree: Y
    vermagic: 3.11.0-12-generic SMP mod_unload modversions
    parm: debug_mask:Debugging mask (uint)
    parm: uart_print:Uart target debugging (bool)
    parm: p2p:Enable ath10k P2P support (uint)



    bjooris@DSS-1300-1:~/hostap/hostapd$ .*/hostapd -v*
    hostapd v2.2-devel
    User space daemon for IEEE 802.11 AP management,
    IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
    Copyright (c) 2002-2014, Jouni Malinen <j@w1.fi> and contributors


    bjooris@DSS-1300-1:~/hostap/hostapd$*cat 80211ac_test.conf *
    interface=wlan0
    driver=nl80211
    ssid=atk10k_80211AC
    hw_mode=a
    channel=44
    #country_code=FI
    #ieee80211d=1
    #ieee80211h=1
    ht_capab=[HT40+]
    ieee80211n=1
    *ieee80211ac=1*
    vht_oper_chwidth=1
    vht_oper_centr_freq_seg0_idx=42



    bjooris@DSS-1300-1:~/hostap/hostapd$ *sudo ./hostapd
    ./80211ac_test.conf -dddd*
    random: Trying to read entropy from /dev/random
    Configuration file: ./80211ac_test.conf
    nl80211: Could not add multicast membership for vendor events: -2
    (No such file or directory)
    rfkill: initial event: idx=0 type=1 op=0 soft=0 hard=0
    nl80211: Supported cipher 00-0f-ac:1
    nl80211: Supported cipher 00-0f-ac:5
    nl80211: Supported cipher 00-0f-ac:2
    nl80211: Supported cipher 00-0f-ac:4
    nl80211: Supported cipher 00-0f-ac:6
    nl80211: Using driver-based off-channel TX
    nl80211: Use separate P2P group interface (driver advertised support)
    nl80211: interface wlan0 in phy phy0
    nl80211: Set mode ifindex 4 iftype 3 (AP)
    nl80211: Setup AP(wlan0) - device_ap_sme=0 use_monitor=0
    nl80211: Subscribe to mgmt frames with AP handle 0x21d8430
    nl80211: Register frame type=0xb0 nl_handle=0x21d8430 match=
    nl80211: Register frame type=0x0 nl_handle=0x21d8430 match=
    nl80211: Register frame type=0x20 nl_handle=0x21d8430 match=
    nl80211: Register frame type=0xa0 nl_handle=0x21d8430 match=
    nl80211: Register frame type=0xc0 nl_handle=0x21d8430 match=
    nl80211: Register frame type=0xd0 nl_handle=0x21d8430 match=
    nl80211: Register frame type=0x40 nl_handle=0x21d8430 match=
    nl80211: Add own interface ifindex 4
    phy: phy0
    BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
    nl80211: Regulatory information - country=FI
    nl80211: 2402-2482 @ 40 MHz 20 mBm
    nl80211: 5170-5250 @ 40 MHz 20 mBm
    nl80211: 5250-5330 @ 40 MHz 20 mBm
    nl80211: 5490-5710 @ 40 MHz 27 mBm
    nl80211: 57240-65880 @ 2160 MHz 40 mBm
    Allowed channel: mode=2 chan=36 freq=5180 MHz max_tx_power=20 dBm
    Allowed channel: mode=2 chan=40 freq=5200 MHz max_tx_power=20 dBm
    Allowed channel: mode=2 chan=44 freq=5220 MHz max_tx_power=20 dBm
    Allowed channel: mode=2 chan=48 freq=5240 MHz max_tx_power=20 dBm
    hw vht capab: 0x338001b2, conf vht capab: 0x0
    wlan0: interface state UNINITIALIZED->HT_SCAN
    Scan for neighboring BSSes prior to enabling 40 MHz channel
    40 MHz affected channel range: [5210,5250] MHz
    wlan0: nl80211: scan request
    nl80211: Scan frequency 5220 MHz
    nl80211: Scan frequency 5240 MHz
    Scan requested (ret=0) - scan timeout 10 seconds
    Interface initialization will be completed in a callback
    ctrl_iface not configured!
    RTM_NEWLINK: ifi_index=4 ifname=wlan0 operstate=2 linkmode=0
    ifi_flags=0x1003 ([UP])
    nl80211: Event message available
    nl80211: Drv Event 33 (NL80211_CMD_TRIGGER_SCAN) received for wlan0
    wlan0: nl80211: Scan trigger
    wlan0: Event SCAN_STARTED (49) received
    Unknown event 49
    nl80211: Beacon event message available
    wlan0: Event RX_MGMT (20) received
    Unknown Broadcom information element ignored (type=52 len=26)
    unknown vendor specific information element ignored (vendor OUI
    00:13:92 len=8)
    Add randomness: count=1 entropy=0
    random pool - hexdump(len=128): [REMOVED]
    random_mix_pool - hexdump(len=16): [REMOVED]
    random_mix_pool - hexdump(len=12): [REMOVED]
    random pool - hexdump(len=128): [REMOVED]
    nl80211: Event message available
    nl80211: Drv Event 34 (NL80211_CMD_NEW_SCAN_RESULTS) received for wlan0
    wlan0: nl80211: New scan results available
    nl80211: Scan included frequencies: 5220 5240
    wlan0: Event SCAN_RESULTS (3) received
    nl80211: Received scan results (1 BSSes)
    Unknown Broadcom information element ignored (type=52 len=26)
    unknown vendor specific information element ignored (vendor OUI
    00:13:92 len=8)
    Unknown Broadcom information element ignored (type=52 len=26)
    unknown vendor specific information element ignored (vendor OUI
    00:13:92 len=8)
    HT40: control channel: 44 secondary channel: 48
    Completing interface initialization
    Mode: IEEE 802.11a Channel: 44 Frequency: 5220 MHz
    DFS 0 channels required radar detection
    nl80211: Set freq 5220 (ht_enabled=1, vht_enabled=1, bandwidth=80
    MHz, cf1=5210 MHz, cf2=0 MHz)
    nl80211: Failed to set channel (freq=5220): -22 (Invalid argument)
    *Could not set channel for kernel driver*
    RTM_NEWLINK: ifi_index=4 ifname=wlan0 wext ifi_flags=0x1003 ([UP])
    random: Got 9/20 bytes from /dev/random



_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: nl80211: Failed to set channel
  2014-02-23 21:15                                       ` nl80211: Failed to set channel Bart Jooris
@ 2014-02-24  8:44                                         ` Sven Schnelle
  2014-02-24  9:02                                           ` Kalle Valo
                                                             ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Sven Schnelle @ 2014-02-24  8:44 UTC (permalink / raw)
  To: ath10k

On 02/23/2014 10:15 PM, Bart Jooris wrote:
> nl80211: Regulatory information - country=FI
>      nl80211: 2402-2482 @ 40 MHz 20 mBm
>      nl80211: 5170-5250 @ 40 MHz 20 mBm
>      nl80211: 5250-5330 @ 40 MHz 20 mBm
>      nl80211: 5490-5710 @ 40 MHz 27 mBm
You need to update your regulatory database. Your version doesn't
allow 80MHz wide channels.

Sven.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: nl80211: Failed to set channel
  2014-02-24  8:44                                         ` Sven Schnelle
@ 2014-02-24  9:02                                           ` Kalle Valo
  2014-02-24 14:59                                           ` Bart Jooris
       [not found]                                           ` <530E5EF2.8070800@intec.ugent.be>
  2 siblings, 0 replies; 20+ messages in thread
From: Kalle Valo @ 2014-02-24  9:02 UTC (permalink / raw)
  To: Sven Schnelle; +Cc: ath10k

Sven Schnelle <svens@stackframe.org> writes:

> On 02/23/2014 10:15 PM, Bart Jooris wrote:
>> nl80211: Regulatory information - country=FI
>>      nl80211: 2402-2482 @ 40 MHz 20 mBm
>>      nl80211: 5170-5250 @ 40 MHz 20 mBm
>>      nl80211: 5250-5330 @ 40 MHz 20 mBm
>>      nl80211: 5490-5710 @ 40 MHz 27 mBm
>
> You need to update your regulatory database. Your version doesn't
> allow 80MHz wide channels.

This is a frequent problem with ath10k users. I think we need to add a
FAQ to the wiki.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: nl80211: Failed to set channel
  2014-02-24  8:44                                         ` Sven Schnelle
  2014-02-24  9:02                                           ` Kalle Valo
@ 2014-02-24 14:59                                           ` Bart Jooris
       [not found]                                           ` <530E5EF2.8070800@intec.ugent.be>
  2 siblings, 0 replies; 20+ messages in thread
From: Bart Jooris @ 2014-02-24 14:59 UTC (permalink / raw)
  To: ath10k

Hi Sven,

thanks for the quick response!


On 02/24/2014 09:44 AM, Sven Schnelle wrote:
> On 02/23/2014 10:15 PM, Bart Jooris wrote:
>> nl80211: Regulatory information - country=FI
>>      nl80211: 2402-2482 @ 40 MHz 20 mBm
>>      nl80211: 5170-5250 @ 40 MHz 20 mBm
>>      nl80211: 5250-5330 @ 40 MHz 20 mBm
>>      nl80211: 5490-5710 @ 40 MHz 27 mBm
> You need to update your regulatory database. Your version doesn't
> allow 80MHz wide channels.

I've cloned the git like described on: 
http://wireless.kernel.org/en/developers/Regulatory
and executed make install in that dir.

The debug info indeed changed to 160MHz bandwidth, see my debug output.
sudo iw reg set BE doesn't seem to work anymore... but still works from 
hostapd config.

Does this look ok to you, as I am unable to observe the AP from another 
similar machine.

bjooris@DSS-1300-1:~/hostap/hostapd$ sudo ./hostapd ./80211ac_test.conf 
-dddd
random: Trying to read entropy from /dev/random
Configuration file: ./80211ac_test.conf
nl80211: Could not add multicast membership for vendor events: -2 (No 
such file or directory)
rfkill: initial event: idx=0 type=1 op=0 soft=1 hard=0
rfkill: WLAN soft blocked
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Supported cipher 00-0f-ac:6
nl80211: Using driver-based off-channel TX
nl80211: Use separate P2P group interface (driver advertised support)
nl80211: interface wlan0 in phy phy0
nl80211: Set mode ifindex 4 iftype 3 (AP)
nl80211: Setup AP(wlan0) - device_ap_sme=0 use_monitor=0
nl80211: Subscribe to mgmt frames with AP handle 0x1d5d430
nl80211: Register frame type=0xb0 nl_handle=0x1d5d430 match=
nl80211: Register frame type=0x0 nl_handle=0x1d5d430 match=
nl80211: Register frame type=0x20 nl_handle=0x1d5d430 match=
nl80211: Register frame type=0xa0 nl_handle=0x1d5d430 match=
nl80211: Register frame type=0xc0 nl_handle=0x1d5d430 match=
nl80211: Register frame type=0xd0 nl_handle=0x1d5d430 match=
nl80211: Register frame type=0x40 nl_handle=0x1d5d430 match=
Could not set interface wlan0 flags (UP): Operation not possible due to 
RF-kill
nl80211: Could not yet enable interface 'wlan0' due to rfkill
nl80211: Add own interface ifindex 4
phy: phy0
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Previous country code 00, new country code BE
Continue interface setup after channel list update
ctrl_iface not configured!
wlan0: Event INTERFACE_DISABLED (29) received
Unknown event 29
random: Got 7/20 bytes from /dev/random
Channel list update timeout - try to continue anyway
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz 20 mBm
nl80211: 2457-2482 @ 40 MHz 20 mBm
nl80211: 2474-2494 @ 20 MHz 20 mBm
nl80211: 5170-5250 @ 160 MHz 20 mBm
nl80211: 5250-5330 @ 160 MHz 20 mBm
nl80211: 5490-5730 @ 160 MHz 20 mBm
Allowed channel: mode=2 chan=52 freq=5260 MHz max_tx_power=20 dBm (DFS 
state = usable)
Allowed channel: mode=2 chan=56 freq=5280 MHz max_tx_power=20 dBm (DFS 
state = usable)
Allowed channel: mode=2 chan=60 freq=5300 MHz max_tx_power=20 dBm (DFS 
state = usable)
Allowed channel: mode=2 chan=64 freq=5320 MHz max_tx_power=20 dBm (DFS 
state = usable)
hw vht capab: 0x338001b2, conf vht capab: 0x0
wlan0: interface state COUNTRY_UPDATE->HT_SCAN
Scan for neighboring BSSes prior to enabling 40 MHz channel
40 MHz affected channel range: [5290,5330] MHz
wlan0: nl80211: scan request
nl80211: Scan frequency 5300 MHz
nl80211: Scan frequency 5320 MHz
nl80211: Scan trigger failed: ret=-100 (Network is down)
nl80211: Set mode ifindex 4 iftype 2 (STATION)
nl80211: Teardown AP(wlan0) - device_ap_sme=0 use_monitor=0
nl80211: Unsubscribe mgmt frames handle 0x88888888895d5cb9 (AP teardown)
nl80211: Subscribe to mgmt frames with non-AP handle 0x1d5d470
nl80211: Register frame type=0xd0 nl_handle=0x1d5d470 match=0801
nl80211: Register frame type=0xd0 nl_handle=0x1d5d470 match=06
nl80211: Register frame type=0xd0 nl_handle=0x1d5d470 match=0a07
nl80211: Register frame type=0xd0 nl_handle=0x1d5d470 match=0a11


Best regards,

Bart

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

[parent not found: <530E5EF2.8070800@intec.ugent.be>]

* Running throughput tests
       [not found]                                           ` <530E5EF2.8070800@intec.ugent.be>
@ 2014-02-27 15:59                                             ` Kalle Valo
  2014-03-28 15:11                                               ` Bart Jooris
  0 siblings, 1 reply; 20+ messages in thread
From: Kalle Valo @ 2014-02-27 15:59 UTC (permalink / raw)
  To: Bart.Jooris; +Cc: ath10k

Changing subject.

Bart Jooris <Bart.Jooris@intec.ugent.be> writes:

> I have a new install with:
> -Ubuntu 12.04 LTS (no support for ath10k yet)
> -got firmware via https://github.com/kvalo/ath10k-firmware/
> -builded linux-3.13.5 to have the ath10k modules (nog atk10k from
> source see my mail of 24 Feb)
> -builded hostapd, wireless-regdb and crda from source
>
> and I have 80MHz wide channels now :-)
>
> Just got a stable 160Mbps (iperf udp, tweeking the distance and ended
> up around 50cm) on a Ubuntu 13.10 client (regulatory.bin still not
> ok).
> Not yet the 300Mbps as I read earlier on the thread.
> What could be the next steps to speed up the link?

First I would use the full hostapd configuration which I just added to
the wiki:

http://wireless.kernel.org/en/users/Drivers/ath10k/configuration#Full_hostapd_configuration

Next I would disable all possible debug features from kernel and make
sure that they are not included in the build. And last try to find a
free channel with little interference as possible.

I'm sure others have better ideas.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-02-27 15:59                                             ` Running throughput tests Kalle Valo
@ 2014-03-28 15:11                                               ` Bart Jooris
  2014-03-28 15:31                                                 ` Kalle Valo
  0 siblings, 1 reply; 20+ messages in thread
From: Bart Jooris @ 2014-03-28 15:11 UTC (permalink / raw)
  To: ath10k

Dear Kalle,

On 02/27/2014 04:59 PM, Kalle Valo wrote:
> Changing subject.
>
> Bart Jooris<Bart.Jooris@intec.ugent.be>  writes:
>
>> Just got a stable 160Mbps (iperf udp, tweeking the distance and ended
>> up around 50cm) on a Ubuntu 13.10 client (regulatory.bin still not
>> ok).
>> Not yet the 300Mbps as I read earlier on the thread.
>> What could be the next steps to speed up the link?
> First I would use the full hostapd configuration which I just added to
> the wiki:
>
> http://wireless.kernel.org/en/users/Drivers/ath10k/configuration#Full_hostapd_configuration
>
> Next I would disable all possible debug features from kernel and make
> sure that they are not included in the build. And last try to find a
> free channel with little interference as possible.
>
> I'm sure others have better ideas.
>
No luck for now. 160Mbps seems to be the limit using the mentioned 
configuration (I had to fix the channel to 36 and add 
vht_oper_centr_freq_seg0_idx=42 again to bring up the AP)
I'm using sparkLAN WPEA-351AC cards with QCA9880 chip set.
I' ve got this info from SparkLAN:

On 03/03/2014 11:35 AM, (SparkLAN) wrote:
> It seems like you are trying to test on AP mode with DFS band, but 
> unfortunately Ath9K and 10K does not support that so far. 

You are probably using Compex cards with the same chip set?
Based on the chip set, I should be able to get higher bitrates or is it 
possbile that the WPEA-351AC card needs another configuration?

Thanks a lot,

Bart


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-03-28 15:11                                               ` Bart Jooris
@ 2014-03-28 15:31                                                 ` Kalle Valo
  2014-03-29 19:42                                                   ` Bart Jooris
  0 siblings, 1 reply; 20+ messages in thread
From: Kalle Valo @ 2014-03-28 15:31 UTC (permalink / raw)
  To: Bart.Jooris; +Cc: ath10k

Bart Jooris <Bart.Jooris@intec.ugent.be> writes:

> On 02/27/2014 04:59 PM, Kalle Valo wrote:
>> Changing subject.
>>
>> Bart Jooris<Bart.Jooris@intec.ugent.be>  writes:
>>
>>> Just got a stable 160Mbps (iperf udp, tweeking the distance and ended
>>> up around 50cm) on a Ubuntu 13.10 client (regulatory.bin still not
>>> ok).
>>> Not yet the 300Mbps as I read earlier on the thread.
>>> What could be the next steps to speed up the link?
>> First I would use the full hostapd configuration which I just added to
>> the wiki:
>>
>> http://wireless.kernel.org/en/users/Drivers/ath10k/configuration#Full_hostapd_configuration
>>
>> Next I would disable all possible debug features from kernel and make
>> sure that they are not included in the build. And last try to find a
>> free channel with little interference as possible.
>>
>> I'm sure others have better ideas.
>>
> No luck for now. 160Mbps seems to be the limit using the mentioned
> configuration (I had to fix the channel to 36 and add
> vht_oper_centr_freq_seg0_idx=42 again to bring up the AP)
> I'm using sparkLAN WPEA-351AC cards with QCA9880 chip set.

You are providing very little information which makes it difficult to
help. For starters:

* What firmware version?

* What version of ath10k are you using?

* Are you sure that the host is not limiting the throughput in any way?
  Try to disable _all_ kernel debug options.

* Also describe your test setup in detail.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-03-28 15:31                                                 ` Kalle Valo
@ 2014-03-29 19:42                                                   ` Bart Jooris
  2014-03-29 20:18                                                     ` Ben Greear
                                                                       ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Bart Jooris @ 2014-03-29 19:42 UTC (permalink / raw)
  To: Kalle Valo; +Cc: ath10k

Dear Kalle,

On 03/28/2014 04:31 PM, Kalle Valo wrote:
> Bart Jooris <Bart.Jooris@intec.ugent.be> writes:
>
>> On 02/27/2014 04:59 PM, Kalle Valo wrote:
>>> Bart Jooris<Bart.Jooris@intec.ugent.be>  writes:
>>>
>>>> Just got a stable 160Mbps
>>>> What could be the next steps to speed up the link?
>>> First I would use the full hostapd configuration which I just added to
>>> the wiki:
>>>
>>> http://wireless.kernel.org/en/users/Drivers/ath10k/configuration#Full_hostapd_configuration
>>>
>>> Next I would disable all possible debug features from kernel and make
>>> sure that they are not included in the build. And last try to find a
>>> free channel with little interference as possible.
>> No luck for now. 160Mbps seems to be the limit using the mentioned
>> configuration (I had to fix the channel to 36 and add
>> vht_oper_centr_freq_seg0_idx=42 again to bring up the AP)
>> I'm using sparkLAN WPEA-351AC cards with QCA9880 chip set.
> You are providing very little information which makes it difficult to
> help. For starters:
>
> * What firmware version?
I've cloned 'recently' https://github.com/kvalo/ath10k-firmware/

tree -D /lib/firmware/ath10k/QCA988X
└── [Mar 29 10:46] hw2.0
├── [Feb 26 19:39] board.bin
├── [Feb 26 19:39] firmware-2.bin
└── [Feb 26 19:39] otp.bin

>
> * What version of ath10k are you using?
I compiled kernel 3.13.5.

bjooris@DSS-1300-2:~/hostap/hostapd$ modinfo ath10k_core
filename: 
/lib/modules/3.13.5/kernel/drivers/net/wireless/ath/ath10k/ath10k_core.ko
license: Dual BSD/GPL
description: Core module for QCA988X PCIe devices.
author: Qualcomm Atheros
srcversion: DA55C25E71B79D3290536E8
depends: cfg80211,mac80211,ath
intree: Y
vermagic: 3.13.5 SMP mod_unload modversions
parm: debug_mask:Debugging mask (uint)
parm: uart_print:Uart target debugging (bool)
parm: p2p:Enable ath10k P2P support (uint)

bjooris@DSS-1300-2:~/hostap/hostapd$ modinfo ath10k_pci
filename: 
/lib/modules/3.13.5/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
firmware: ath10k/QCA988X/hw2.0/board.bin
firmware: ath10k/QCA988X/hw2.0/otp.bin
firmware: ath10k/QCA988X/hw2.0/firmware.bin
license: Dual BSD/GPL
description: Driver support for Atheros QCA988X PCIe devices
author: Qualcomm Atheros
srcversion: 5F60FB9DB0EE6DA2012D4DB
alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
depends: ath10k_core,mac80211
intree: Y
vermagic: 3.13.5 SMP mod_unload modversions
parm: ath10k_target_ps:Enable ath10k Target (SoC) PS option (uint)

>
> * Are you sure that the host is not limiting the throughput in any way?
>    Try to disable _all_ kernel debug options.
/var/log/syslog and dmesg doesn't to be packed with messages related to 
the throughput test. I don't think to have seen the CPU being overloaded 
during the test.
I'm planning to go back to the office tomorrow to verify this.

Further I have these in my kernel config
CONFIG_ATH10K=m
CONFIG_ATH10K_PCI=m
# CONFIG_ATH10K_DEBUG is not set
CONFIG_ATH10K_DEBUGFS=y
CONFIG_ATH10K_TRACING=y

I will disable the last two too.

>
> * Also describe your test setup in detail.
>
Common for AP and STA:

-DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
-1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band antenna's.
-Kernel 3.13.5 containing the ath10k modules
-firmwares cloned end of February
-iperf in udp mode used for the  throughput test

AP only:
-ubuntu 12.04 LTS as crda wouldn't build on ubuntu 13.10 (libgcrypt issue).
-hostapd v2.2-devel
-modified regulatory database and crda build
-your Full_hostapd_configuration + channel=36 and vht_oper_centr_freq_seg0_idx=42

STA only:
-ubuntu 13.10
-nmcli is used to connect to the AP

Distance between AP and STA: 60 cm. Antenna's are now directed orthogonal per device, antennaX (X=1..3) on both devices are pointing in the same direction.
Although I've played a lot with the antenna's directions already and I can't remember one run where it had a lot of impact...

The spectrum analyser measured a band of almost 80MHz being used.


Thanks a lot,

Bart



-- 
Bart Jooris
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
E-mail: bart.jooris@intec.UGent.be
M: +32 474 59 53 42
Tel. +32 9 33 14900
Fax +32 9 33 14899


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-03-29 19:42                                                   ` Bart Jooris
@ 2014-03-29 20:18                                                     ` Ben Greear
  2014-03-30  7:31                                                       ` Bart Jooris
  2014-03-30  9:36                                                     ` Bart Jooris
  2014-04-08 12:42                                                     ` Kalle Valo
  2 siblings, 1 reply; 20+ messages in thread
From: Ben Greear @ 2014-03-29 20:18 UTC (permalink / raw)
  To: Bart.Jooris, Kalle Valo; +Cc: ath10k

On 03/29/2014 12:42 PM, Bart Jooris wrote:

> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band antenna's.
> -Kernel 3.13.5 containing the ath10k modules
> -firmwares cloned end of February
> -iperf in udp mode used for the  throughput test

I get 500+Mbps on some other NICs with same chipset...  I'll get some
WPEA-351AC as soon as I can find someone willing to sell them and will
do some tests on those as well...

With very latest ath10k tree and firmware, you can cat out the
debug stats and see your station tx/rx train rates..that might
be interesting information...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-03-29 20:18                                                     ` Ben Greear
@ 2014-03-30  7:31                                                       ` Bart Jooris
  2014-03-30 17:06                                                         ` Ben Greear
  2014-04-08 12:45                                                         ` Kalle Valo
  0 siblings, 2 replies; 20+ messages in thread
From: Bart Jooris @ 2014-03-30  7:31 UTC (permalink / raw)
  To: Ben Greear, Kalle Valo; +Cc: ath10k

Dear Ben,

On 03/29/2014 09:18 PM, Ben Greear wrote:
> On 03/29/2014 12:42 PM, Bart Jooris wrote:
>
>> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
>> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band 
>> antenna's.
>> -Kernel 3.13.5 containing the ath10k modules
>> -firmwares cloned end of February
>> -iperf in udp mode used for the  throughput test
>
> I get 500+Mbps on some other NICs with same chipset... 
:-) Which cards are you using?
> I'll get some
> WPEA-351AC as soon as I can find someone willing to sell them and will
> do some tests on those as well...
>
I have 8 of those, I can lend you 2.
> With very latest ath10k tree and firmware, you can cat out the
> debug stats and see your station tx/rx train rates..that might
> be interesting information...
I will give it another try to compile the latest ath10k.

Thanks,

Bart

-- 
Bart Jooris
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
E-mail: bart.jooris@intec.UGent.be
M: +32 474 59 53 42
Tel. +32 9 33 14900
Fax +32 9 33 14899


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-03-30  7:31                                                       ` Bart Jooris
@ 2014-03-30 17:06                                                         ` Ben Greear
  2014-04-08 12:45                                                         ` Kalle Valo
  1 sibling, 0 replies; 20+ messages in thread
From: Ben Greear @ 2014-03-30 17:06 UTC (permalink / raw)
  To: Bart.Jooris, Kalle Valo; +Cc: ath10k

On 03/30/2014 12:31 AM, Bart Jooris wrote:
> Dear Ben,
>
> On 03/29/2014 09:18 PM, Ben Greear wrote:
>> On 03/29/2014 12:42 PM, Bart Jooris wrote:
>>
>>> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
>>> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band antenna's.
>>> -Kernel 3.13.5 containing the ath10k modules
>>> -firmwares cloned end of February
>>> -iperf in udp mode used for the  throughput test
>>
>> I get 500+Mbps on some other NICs with same chipset...
> :-) Which cards are you using?

I get same general throughput with CUS223 and WLE900VX.

>> I'll get some
>> WPEA-351AC as soon as I can find someone willing to sell them and will
>> do some tests on those as well...
>>
> I have 8 of those, I can lend you 2.

I'll contact you off list about this.

Thanks,
Ben

>> With very latest ath10k tree and firmware, you can cat out the
>> debug stats and see your station tx/rx train rates..that might
>> be interesting information...
> I will give it another try to compile the latest ath10k.
>
> Thanks,
>
> Bart
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-03-30  7:31                                                       ` Bart Jooris
  2014-03-30 17:06                                                         ` Ben Greear
@ 2014-04-08 12:45                                                         ` Kalle Valo
  1 sibling, 0 replies; 20+ messages in thread
From: Kalle Valo @ 2014-04-08 12:45 UTC (permalink / raw)
  To: Bart.Jooris; +Cc: Ben Greear, ath10k

Bart Jooris <bart.jooris@gmail.com> writes:

> Dear Ben,
>
> On 03/29/2014 09:18 PM, Ben Greear wrote:
>> On 03/29/2014 12:42 PM, Bart Jooris wrote:
>>
>>> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
>>> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band
>>> antenna's.
>>> -Kernel 3.13.5 containing the ath10k modules
>>> -firmwares cloned end of February
>>> -iperf in udp mode used for the  throughput test
>>
>> I get 500+Mbps on some other NICs with same chipset... 
>
> :-) Which cards are you using?
>
>> I'll get some
>> WPEA-351AC as soon as I can find someone willing to sell them and will
>> do some tests on those as well...
>
> I have 8 of those, I can lend you 2.

Can you setup a third board as a sniffer and see what's happening on the
air? But it's still more important to get ath10k and hostapd debug logs,
try to take those first.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-03-29 19:42                                                   ` Bart Jooris
  2014-03-29 20:18                                                     ` Ben Greear
@ 2014-03-30  9:36                                                     ` Bart Jooris
  2014-04-08 12:42                                                     ` Kalle Valo
  2 siblings, 0 replies; 20+ messages in thread
From: Bart Jooris @ 2014-03-30  9:36 UTC (permalink / raw)
  To: ath10k, Kalle Valo

Dear Kalle,

On 03/29/2014 08:42 PM, Bart Jooris wrote:
> On 03/28/2014 04:31 PM, Kalle Valo wrote:
>
>>
>> * Are you sure that the host is not limiting the throughput in any way?
>>    Try to disable _all_ kernel debug options.
> /var/log/syslog and dmesg doesn't to be packed with messages related 
> to the throughput test. I don't think to have seen the CPU being 
> overloaded during the test.
> I'm planning to go back to the office tomorrow to verify this.
>

I just ran a new test to verify if the AP or the STA are under stress.
What you can see here is dstat, hostapd and iperf running on the AP.
After +-8 seconds I've started iperf on the STA.

bjooris@DSS-1300-2:~$ dstat -c -n -N wlan0 -d -D sda1
----total-cpu-usage---- -net/wlan0- --dsk/sda1-
usr sys idl wai hiq siq| recv  send| read  writ
   0   0 100   0   0   0|   0     0 | 228k 9002B
   0   0 100   0   0   0|   0     0 |   0     0
   0   0 100   0   0   0|   0     0 |   0     0
   0   0 100   0   0   0|   0     0 |   0     0
   0   0 100   0   0   0|   0     0 |   0     0
   0   0 100   0   0   0|   0     0 |   0     0
   0   0 100   0   0   0|   0     0 |   0     0
   0   0 100   0   0   0|   0     0 |   0     0
   0   0 100   0   0   0|4710k    0 |   0     0
   0   0  99   0   0   0|  16M    0 |   0     0
   0   0  99   0   0   0|  17M    0 |   0     0
   0   1  99   0   0   0|  17M    0 |   0     0
   0   0  99   0   0   0|  17M    0 |   0     0
   0   0  99   0   0   0|  17M    0 |   0     0
   1   0  99   0   0   0|  17M   62B|   0     0
   0   1  99   0   0   0|  17M    0 |   0     0
   0   0  99   0   0   0|  16M    0 |   0     0
   0   0  99   0   0   0|  17M    0 |   0     0
   0   1  99   0   0   0|  17M    0 |   0     0
   0   0 100   0   0   0|  17M    0 |   0     0

Same info on the STA with iperf already running.

----total-cpu-usage---- -net/wlan0- --dsk/sda1-
usr sys idl wai hiq siq| recv  send| read  writ
   0   3  97   0   0   0|   0    17M|   0     0
   0   3  97   0   0   0|   0    17M|   0     0
   0   3  97   0   0   0|   0    17M|   0     0
   0   3  97   0   0   0|   0    17M|   0     0
   0   2  98   0   0   0|   0    18M|   0     0
   1   4  95   0   0   0|   0    17M|   0     0
   0   3  97   0   0   0|   0    18M|   0     0
   1   3  96   0   0   0|   0    17M|   0     0
   0   3  96   0   0   0|   0    18M|   0     0
   1   4  96   0   0   0|   0    18M|   0     0
   0   4  96   0   0   0|   0    17M|   0     0
   1   4  95   0   0   0|   0    17M|   0     0
   0   3  97   0   0   0|   0    17M|   0     0
   0   3  97   0   0   0|   0    17M|   0     0

I will now try to build the latest ath10k.

Thanks a lot,

Bart


-- 
Bart Jooris
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
E-mail: bart.jooris@intec.UGent.be
M: +32 474 59 53 42
Tel. +32 9 33 14900
Fax +32 9 33 14899


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-03-29 19:42                                                   ` Bart Jooris
  2014-03-29 20:18                                                     ` Ben Greear
  2014-03-30  9:36                                                     ` Bart Jooris
@ 2014-04-08 12:42                                                     ` Kalle Valo
  2014-04-19 19:48                                                       ` Bart Jooris
  2 siblings, 1 reply; 20+ messages in thread
From: Kalle Valo @ 2014-04-08 12:42 UTC (permalink / raw)
  To: Bart.Jooris; +Cc: ath10k

Hi Bart,

Bart Jooris <bart.jooris@gmail.com> writes:

> On 03/28/2014 04:31 PM, Kalle Valo wrote:
>
>> You are providing very little information which makes it difficult to
>> help. For starters:
>>
>> * What firmware version?
> I've cloned 'recently' https://github.com/kvalo/ath10k-firmware/
>
> tree -D /lib/firmware/ath10k/QCA988X
> └── [Mar 29 10:46] hw2.0
> ├── [Feb 26 19:39] board.bin
> ├── [Feb 26 19:39] firmware-2.bin
> └── [Feb 26 19:39] otp.bin

That doesn't tell anything about the firmware version. Please read this:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Firmware_version

You should use 10.1.467.2-1 and see this in dmesg:

[ 2651.506691] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.2-1 api 2 htt 2.1

(Please note that the info print was changed few weeks back, so it won't
look exactly same on 3.13.)

>> * What version of ath10k are you using?
>
> I compiled kernel 3.13.5.

Ok, that's a relatively old as the version of ath10k in that release is
from last October. We have had quite a few optimisations and fixes since
then but you should still easily get 400 Mbps, especially on your fast
x86 cpus.

>> * Are you sure that the host is not limiting the throughput in any way?
>>    Try to disable _all_ kernel debug options.

> /var/log/syslog and dmesg doesn't to be packed with messages related
> to the throughput test. I don't think to have seen the CPU being
> overloaded during the test.
> I'm planning to go back to the office tomorrow to verify this.
>
> Further I have these in my kernel config
> CONFIG_ATH10K=m
> CONFIG_ATH10K_PCI=m
> # CONFIG_ATH10K_DEBUG is not set
> CONFIG_ATH10K_DEBUGFS=y
> CONFIG_ATH10K_TRACING=y
>
> I will disable the last two too.

Ok, this looks good. But just to confirm, can you send the full kernel
config file as well?

>> * Also describe your test setup in detail.
>>
> Common for AP and STA:
>
> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band antenna's.
> -Kernel 3.13.5 containing the ath10k modules
> -firmwares cloned end of February
> -iperf in udp mode used for the  throughput test
>
> AP only:
> -ubuntu 12.04 LTS as crda wouldn't build on ubuntu 13.10 (libgcrypt issue).
> -hostapd v2.2-devel
> -modified regulatory database and crda build
> -your Full_hostapd_configuration + channel=36 and vht_oper_centr_freq_seg0_idx=42
>
> STA only:
> -ubuntu 13.10
> -nmcli is used to connect to the AP
>
> Distance between AP and STA: 60 cm. Antenna's are now directed
> orthogonal per device, antennaX (X=1..3) on both devices are pointing
> in the same direction. Although I've played a lot with the antenna's
> directions already and I can't remember one run where it had a lot of
> impact...
>
> The spectrum analyser measured a band of almost 80MHz being used.

This looks good as well. Is it possible for you take debug logs? First
enable these ath10k options:

CONFIG_ATH10K_DEBUG=y
CONFIG_ATH10K_DEBUGFS=y
CONFIG_ATH10K_TRACING=y

And start ath10k with debug mask 0x432, which prints info related to
firmware configuration:

modprobe ath10k_core.ko debug_mask=0x432

Also start hostapd with -dddt and connect the ath10k STA to the AP. Then
send here both the full dmesg output, preferably starting from kernel
boot, and hostapd debug logs here from the AP. No need to run any
throughput tests in this case, I just want to see how we configure the
firmware when the STA associates.

And even better if you could use trace-cmd, we get more logs that way:

http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Tracing

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-04-08 12:42                                                     ` Kalle Valo
@ 2014-04-19 19:48                                                       ` Bart Jooris
  2014-04-24  6:44                                                         ` Kalle Valo
  0 siblings, 1 reply; 20+ messages in thread
From: Bart Jooris @ 2014-04-19 19:48 UTC (permalink / raw)
  To: Kalle Valo; +Cc: Ben Greear, ath10k

Hi Kalle,

I also have a stable 500Mbps ++ link now :-) with peaks up to 520Mbps 
(measured with iperf UDP).
I've  made a second AP and STA with the WLE900VX cards I've exchanged 
with Ben (Thanks again!). Both have Ubuntu 12.04, ath10k from backports 
release and modified  regulatory.bin.
The AP has now 10.1.467.2-1 like you suggested and STA has still 
999.999.0.636.
In combination with, the lowest txPower and  the dipole antennas 
configured like this
"\    | /"  (same plane)
we measured 500Mbps++ in a anechoic chamber (ranged AP<->STA 20cm .. 270cm).
We observed the same speeds  at our offices now and even when we replace 
the  antennas with 1:1 coax + 20db attenuation we 've got 500Mbps++.

Sometime It can take up to 20 seconds before the link maximises, but 
once it gets there it is extremely stable :-).
I will take a look at the ath10k_core.ko debug_mask and HTT statistics 
first to see what happens.
Should I still be able to build a sniffer with the interface in monitor 
mode in combination Wireshark?

Thanks a lot,

Bart


p.s. The configuration with the sparkLAN WPEA-351AC cards still doesn't 
give the same results. Probably my bad, I will double check it again.



On 04/08/2014 02:42 PM, Kalle Valo wrote:
> Hi Bart,
>
> Bart Jooris <bart.jooris@gmail.com> writes:
>
>> On 03/28/2014 04:31 PM, Kalle Valo wrote:
>>
>>> You are providing very little information which makes it difficult to
>>> help. For starters:
>>>
>>> * What firmware version?
>> I've cloned 'recently' https://github.com/kvalo/ath10k-firmware/
>>
>> tree -D /lib/firmware/ath10k/QCA988X
>> └── [Mar 29 10:46] hw2.0
>> ├── [Feb 26 19:39] board.bin
>> ├── [Feb 26 19:39] firmware-2.bin
>> └── [Feb 26 19:39] otp.bin
> That doesn't tell anything about the firmware version. Please read this:
>
> http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Firmware_version
>
> You should use 10.1.467.2-1 and see this in dmesg:
>
> [ 2651.506691] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.2-1 api 2 htt 2.1
>
> (Please note that the info print was changed few weeks back, so it won't
> look exactly same on 3.13.)
>
>>> * What version of ath10k are you using?
>> I compiled kernel 3.13.5.
> Ok, that's a relatively old as the version of ath10k in that release is
> from last October. We have had quite a few optimisations and fixes since
> then but you should still easily get 400 Mbps, especially on your fast
> x86 cpus.
>
>>> * Are you sure that the host is not limiting the throughput in any way?
>>>     Try to disable _all_ kernel debug options.
>> /var/log/syslog and dmesg doesn't to be packed with messages related
>> to the throughput test. I don't think to have seen the CPU being
>> overloaded during the test.
>> I'm planning to go back to the office tomorrow to verify this.
>>
>> Further I have these in my kernel config
>> CONFIG_ATH10K=m
>> CONFIG_ATH10K_PCI=m
>> # CONFIG_ATH10K_DEBUG is not set
>> CONFIG_ATH10K_DEBUGFS=y
>> CONFIG_ATH10K_TRACING=y
>>
>> I will disable the last two too.
> Ok, this looks good. But just to confirm, can you send the full kernel
> config file as well?
>
>>> * Also describe your test setup in detail.
>>>
>> Common for AP and STA:
>>
>> -DSS-1300 with i5-2540M CPU @ 2.60GHz - 8GB RAM - SSD 64GB.
>> -1 sparkLAN WPEA-351AC card with QCA9880 chip set and 3 dual band antenna's.
>> -Kernel 3.13.5 containing the ath10k modules
>> -firmwares cloned end of February
>> -iperf in udp mode used for the  throughput test
>>
>> AP only:
>> -ubuntu 12.04 LTS as crda wouldn't build on ubuntu 13.10 (libgcrypt issue).
>> -hostapd v2.2-devel
>> -modified regulatory database and crda build
>> -your Full_hostapd_configuration + channel=36 and vht_oper_centr_freq_seg0_idx=42
>>
>> STA only:
>> -ubuntu 13.10
>> -nmcli is used to connect to the AP
>>
>> Distance between AP and STA: 60 cm. Antenna's are now directed
>> orthogonal per device, antennaX (X=1..3) on both devices are pointing
>> in the same direction. Although I've played a lot with the antenna's
>> directions already and I can't remember one run where it had a lot of
>> impact...
>>
>> The spectrum analyser measured a band of almost 80MHz being used.
> This looks good as well. Is it possible for you take debug logs? First
> enable these ath10k options:
>
> CONFIG_ATH10K_DEBUG=y
> CONFIG_ATH10K_DEBUGFS=y
> CONFIG_ATH10K_TRACING=y
>
> And start ath10k with debug mask 0x432, which prints info related to
> firmware configuration:
>
> modprobe ath10k_core.ko debug_mask=0x432
>
> Also start hostapd with -dddt and connect the ath10k STA to the AP. Then
> send here both the full dmesg output, preferably starting from kernel
> boot, and hostapd debug logs here from the AP. No need to run any
> throughput tests in this case, I just want to see how we configure the
> firmware when the STA associates.
>
> And even better if you could use trace-cmd, we get more logs that way:
>
> http://wireless.kernel.org/en/users/Drivers/ath10k/debug#Tracing
>


-- 
Bart Jooris
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
E-mail: bart.jooris@intec.UGent.be
M: +32 474 59 53 42
Tel. +32 9 33 14900
Fax +32 9 33 14899


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-04-19 19:48                                                       ` Bart Jooris
@ 2014-04-24  6:44                                                         ` Kalle Valo
  2014-04-29  3:55                                                           ` Ben Greear
  0 siblings, 1 reply; 20+ messages in thread
From: Kalle Valo @ 2014-04-24  6:44 UTC (permalink / raw)
  To: Bart.Jooris; +Cc: Ben Greear, ath10k

Bart Jooris <bart.jooris@gmail.com> writes:

> I also have a stable 500Mbps ++ link now :-) with peaks up to 520Mbps
> (measured with iperf UDP).
> I've  made a second AP and STA with the WLE900VX cards I've exchanged
> with Ben (Thanks again!).

Good!

> p.s. The configuration with the sparkLAN WPEA-351AC cards still
> doesn't give the same results. Probably my bad, I will double check it
> again.

This is CUS223 based design, right? If you see the problem still try to
get debug logs. For example, debug_mask=0x432 might give some hints.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-04-24  6:44                                                         ` Kalle Valo
@ 2014-04-29  3:55                                                           ` Ben Greear
  2014-05-12  4:37                                                             ` Kalle Valo
  0 siblings, 1 reply; 20+ messages in thread
From: Ben Greear @ 2014-04-29  3:55 UTC (permalink / raw)
  To: Kalle Valo, Bart.Jooris; +Cc: ath10k

On 04/23/2014 11:44 PM, Kalle Valo wrote:
> Bart Jooris <bart.jooris@gmail.com> writes:
>
>> I also have a stable 500Mbps ++ link now :-) with peaks up to 520Mbps
>> (measured with iperf UDP).
>> I've  made a second AP and STA with the WLE900VX cards I've exchanged
>> with Ben (Thanks again!).
>
> Good!
>
>> p.s. The configuration with the sparkLAN WPEA-351AC cards still
>> doesn't give the same results. Probably my bad, I will double check it
>> again.
>
> This is CUS223 based design, right? If you see the problem still try to
> get debug logs. For example, debug_mask=0x432 might give some hints.
>

We tried with the Sparklan today, and it locks up the system soon after we
start hostapd, so we just removed it from the system.  The WLE900VX in same
machine and same config works fine.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-04-29  3:55                                                           ` Ben Greear
@ 2014-05-12  4:37                                                             ` Kalle Valo
  2014-05-12  4:44                                                               ` Ben Greear
  0 siblings, 1 reply; 20+ messages in thread
From: Kalle Valo @ 2014-05-12  4:37 UTC (permalink / raw)
  To: Ben Greear; +Cc: Bart.Jooris, ath10k

Ben Greear <greearb@candelatech.com> writes:

> On 04/23/2014 11:44 PM, Kalle Valo wrote:
>> Bart Jooris <bart.jooris@gmail.com> writes:
>>
>>> I also have a stable 500Mbps ++ link now :-) with peaks up to 520Mbps
>>> (measured with iperf UDP).
>>> I've  made a second AP and STA with the WLE900VX cards I've exchanged
>>> with Ben (Thanks again!).
>>
>> Good!
>>
>>> p.s. The configuration with the sparkLAN WPEA-351AC cards still
>>> doesn't give the same results. Probably my bad, I will double check it
>>> again.
>>
>> This is CUS223 based design, right? If you see the problem still try to
>> get debug logs. For example, debug_mask=0x432 might give some hints.
>>
>
> We tried with the Sparklan today, and it locks up the system soon after we
> start hostapd, so we just removed it from the system.  The WLE900VX in same
> machine and same config works fine.

Odd. From the website[1] it looks like a normal CUS233 to me. Can you
get any more info? For example, where does it exactly lock up? Enabling
also all kernel debugging (lock debugging etc) might be also useful.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-05-12  4:37                                                             ` Kalle Valo
@ 2014-05-12  4:44                                                               ` Ben Greear
  2014-05-12  5:14                                                                 ` Kalle Valo
  0 siblings, 1 reply; 20+ messages in thread
From: Ben Greear @ 2014-05-12  4:44 UTC (permalink / raw)
  To: Kalle Valo; +Cc: Bart.Jooris, ath10k



On 05/11/2014 09:37 PM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 04/23/2014 11:44 PM, Kalle Valo wrote:
>>> Bart Jooris <bart.jooris@gmail.com> writes:
>>>
>>>> I also have a stable 500Mbps ++ link now :-) with peaks up to 520Mbps
>>>> (measured with iperf UDP).
>>>> I've  made a second AP and STA with the WLE900VX cards I've exchanged
>>>> with Ben (Thanks again!).
>>>
>>> Good!
>>>
>>>> p.s. The configuration with the sparkLAN WPEA-351AC cards still
>>>> doesn't give the same results. Probably my bad, I will double check it
>>>> again.
>>>
>>> This is CUS223 based design, right? If you see the problem still try to
>>> get debug logs. For example, debug_mask=0x432 might give some hints.
>>>
>>
>> We tried with the Sparklan today, and it locks up the system soon after we
>> start hostapd, so we just removed it from the system.  The WLE900VX in same
>> machine and same config works fine.
>
> Odd. From the website[1] it looks like a normal CUS233 to me. Can you
> get any more info? For example, where does it exactly lock up? Enabling
> also all kernel debugging (lock debugging etc) might be also useful.

Seems like the bad old days when we saw lots of total host lockups on
cold resets, etc.  I didn't see anything useful in the logs, and I was
running lockdep enabled kernel.

Since WLE900VX works for me, I've little interest in hacking on the
Sparklan NIC.  Possibly it's just a bad beta hardware or something like that.

If you have trouble getting a hold of this NIC, I'll be happy to mail
it to you.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Running throughput tests
  2014-05-12  4:44                                                               ` Ben Greear
@ 2014-05-12  5:14                                                                 ` Kalle Valo
  0 siblings, 0 replies; 20+ messages in thread
From: Kalle Valo @ 2014-05-12  5:14 UTC (permalink / raw)
  To: Ben Greear; +Cc: Bart.Jooris, ath10k

Ben Greear <greearb@candelatech.com> writes:

> On 05/11/2014 09:37 PM, Kalle Valo wrote:
>> Ben Greear <greearb@candelatech.com> writes:
>>
>>> We tried with the Sparklan today, and it locks up the system soon after we
>>> start hostapd, so we just removed it from the system.  The WLE900VX in same
>>> machine and same config works fine.
>>
>> Odd. From the website[1] it looks like a normal CUS233 to me. Can you
>> get any more info? For example, where does it exactly lock up? Enabling
>> also all kernel debugging (lock debugging etc) might be also useful.
>
> Seems like the bad old days when we saw lots of total host lockups on
> cold resets, etc.  I didn't see anything useful in the logs, and I was
> running lockdep enabled kernel.
>
> Since WLE900VX works for me, I've little interest in hacking on the
> Sparklan NIC.  Possibly it's just a bad beta hardware or something like that.

Yeah, might be.

> If you have trouble getting a hold of this NIC, I'll be happy to mail
> it to you.

Damn, I just arrived back from US. It would have been easier to ship it
to our San Jose office.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2014-05-12  5:14 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <00ea01cee403$5331f1e0$f995d5a0$@sparklan.com>
     [not found] ` <00d101cee597$e8c57480$ba505d80$@sparklan.com>
     [not found]   ` <52A592B7.9000806@intec.ugent.be>
     [not found]     ` <006301cef71c$d850ec10$88f2c430$@sparklan.com>
     [not found]       ` <52A98706.7080907@intec.ugent.be>
     [not found]         ` <008d01cef722$2a9c05e0$7fd411a0$@sparklan.com>
     [not found]           ` <52A9DEF9.8080305@intec.ugent.be>
     [not found]             ` <012e01cef7e0$99017e70$cb047b50$@sparklan.com>
     [not found]               ` <52AACFB9.8080901@intec.ugent.be>
     [not found]                 ` <006301cefa3c$44c07b50$ce4171f0$@sparklan.com>
     [not found]                   ` <52AEC26B.2060400@intec.ugent.be>
     [not found]                     ` <007f01cefa41$8a940de0$9fbc29a0$@sparklan.com>
     [not found]                       ` <52AEE61F.5030505@intec.ugent.be>
     [not found]                         ` <006b01cefacb$6c0b2d60$44218820$@sparklan.com>
     [not found]                           ` <52B00B10.3050300@intec.ugent.be>
     [not found]                             ` <004b01cefb9d$04a543e0$0defcba0$@sparklan.com>
     [not found]                               ` <52B2AE75.9050206@intec.ugent.be>
     [not found]                                 ` <00df01cf0090$05944f10$10bced30$@sparklan.com>
     [not found]                                   ` <52B9672E.9000701@intec.ugent.be>
     [not found]                                     ` <008c01cf012e$e59563d0$b0c02b70$@sparklan.com>
2014-02-23 21:15                                       ` nl80211: Failed to set channel Bart Jooris
2014-02-24  8:44                                         ` Sven Schnelle
2014-02-24  9:02                                           ` Kalle Valo
2014-02-24 14:59                                           ` Bart Jooris
     [not found]                                           ` <530E5EF2.8070800@intec.ugent.be>
2014-02-27 15:59                                             ` Running throughput tests Kalle Valo
2014-03-28 15:11                                               ` Bart Jooris
2014-03-28 15:31                                                 ` Kalle Valo
2014-03-29 19:42                                                   ` Bart Jooris
2014-03-29 20:18                                                     ` Ben Greear
2014-03-30  7:31                                                       ` Bart Jooris
2014-03-30 17:06                                                         ` Ben Greear
2014-04-08 12:45                                                         ` Kalle Valo
2014-03-30  9:36                                                     ` Bart Jooris
2014-04-08 12:42                                                     ` Kalle Valo
2014-04-19 19:48                                                       ` Bart Jooris
2014-04-24  6:44                                                         ` Kalle Valo
2014-04-29  3:55                                                           ` Ben Greear
2014-05-12  4:37                                                             ` Kalle Valo
2014-05-12  4:44                                                               ` Ben Greear
2014-05-12  5:14                                                                 ` Kalle Valo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.