QCA988X firmware pull-push support

QCA988X firmware pull-push support

[Sergey Ryazanov]

Hello,

I have started to play with intermediate software queues and suddenly
discovered that this code is completely disabled in ath10k for
firmware which does not support tx pull-push mode (QCA9880 in
particular).

So I would like to ask are there any plans for implementation of this
pull-push feature in QCA9880 firmware or I should consider my NIC
upgrade?

-- 
Sergey

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

Re: QCA988X firmware pull-push support

[Sergey Ryazanov]

Yep. Looks like so.

On Mon, Jan 30, 2017 at 3:08 AM, Adrian Chadd <adrian.chadd@gmail.com> wrote:
> I think it's a 10.4 feature?
>
>
> A
>
> On Jan 29, 2017 3:13 PM, "Sergey Ryazanov" <ryazanov.s.a@gmail.com> wrote:
>>
>> Hello,
>>
>> I have started to play with intermediate software queues and suddenly
>> discovered that this code is completely disabled in ath10k for
>> firmware which does not support tx pull-push mode (QCA9880 in
>> particular).
>>
>> So I would like to ask are there any plans for implementation of this
>> pull-push feature in QCA9880 firmware or I should consider my NIC
>> upgrade?

--
Sergey

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

Re: QCA988X firmware pull-push support

[Adrian Chadd]

On 29 January 2017 at 17:20, Sergey Ryazanov <ryazanov.s.a@gmail.com> wrote:
> Yep. Looks like so.

Which is good, because my FreeBSD ath10k port only works with 10.1 /
10.2 firmware on earlier chips, and I haven't figured out the
intermediate software queue support that came with 10.4. :-)

But yeah. I'll wake for Kalle to verify, but I think it's a 10.4
thing, and I don't /think/ there's an official 10.4 build for
Peregrine.



-adrian

>
> On Mon, Jan 30, 2017 at 3:08 AM, Adrian Chadd <adrian.chadd@gmail.com> wrote:
>> I think it's a 10.4 feature?
>>
>>
>> A
>>
>> On Jan 29, 2017 3:13 PM, "Sergey Ryazanov" <ryazanov.s.a@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> I have started to play with intermediate software queues and suddenly
>>> discovered that this code is completely disabled in ath10k for
>>> firmware which does not support tx pull-push mode (QCA9880 in
>>> particular).
>>>
>>> So I would like to ask are there any plans for implementation of this
>>> pull-push feature in QCA9880 firmware or I should consider my NIC
>>> upgrade?
>
> --
> Sergey

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

Re: QCA988X firmware pull-push support

[Valo, Kalle]

Adrian Chadd <adrian.chadd@gmail.com> writes:

> On 29 January 2017 at 17:20, Sergey Ryazanov <ryazanov.s.a@gmail.com> wrote:
>> Yep. Looks like so.
>
> Which is good, because my FreeBSD ath10k port only works with 10.1 /
> 10.2 firmware on earlier chips, and I haven't figured out the
> intermediate software queue support that came with 10.4. :-)
>
> But yeah. I'll wake for Kalle to verify, but I think it's a 10.4
> thing

So there are two parts here, ieee80211_ops::wake_tx_queue() support in
ath10k and ATH10K_FW_FEATURE_PEER_FLOW_CONTROL in firmware. We did have
wake_tx_queue() support enabled for all hw/fw combinations but it was
changed because some people claimed there are throughput regressions in
certain cases. So for now we only enable wake_tx_queue() support only if
firmware supports ATH10K_FW_FEATURE_PEER_FLOW_CONTROL:

	if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
		      ar->running_fw->fw_file.fw_features))
		ar->ops->wake_tx_queue = NULL;

I remember that there were some improvements with wake_tx_queue() even
if firmware didn't support ATH10K_FW_FEATURE_PEER_FLOW_CONTROL. I'm
starting to wonder should we have a module parameter to force use of
wake_tx_queue()?

And IIRC ATH10K_FW_FEATURE_PEER_FLOW_CONTROL was supported in some of
10.4 releases, but not all of them.

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

9984 VHT

[Sebastian Gottschall]

Hello

with recent 9984 firmares vht160 seem to crash the firmware itself for 
no reason i see.
is there any internal structure change in these newer firmwares we need 
to consider?
i also tested the even more recent firmware 
firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash but 
the vdev_start returns with a error

i compared the more recent wmi headers from the qca drivers, but wasnt 
able to find anything which could explain the behaviour

Sebastian


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Ben Greear]

On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
> Hello
>
> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
> is there any internal structure change in these newer firmwares we need to consider?
> i also tested the even more recent firmware firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash but the vdev_start returns with a error
>
> i compared the more recent wmi headers from the qca drivers, but wasnt able to find anything which could explain the behaviour
>
> Sebastian
>
>

Hello Sebastian,

Could you share the hostapd/supplicant config file you are using?

And, what kernel (or backports kernel) are you using?  I'd like to
see how 160Mhz works on my firmware....

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

Re: 9984 VHT

[Sebastian Gottschall]

Am 01.02.2017 um 17:48 schrieb Ben Greear:
> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>> Hello
>>
>> with recent 9984 firmares vht160 seem to crash the firmware itself 
>> for no reason i see.
>> is there any internal structure change in these newer firmwares we 
>> need to consider?
>> i also tested the even more recent firmware 
>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash 
>> but the vdev_start returns with a error
>>
>> i compared the more recent wmi headers from the qca drivers, but 
>> wasnt able to find anything which could explain the behaviour
>>
>> Sebastian
>>
>>
>
> Hello Sebastian,
>
> Could you share the hostapd/supplicant config file you are using?
>
> And, what kernel (or backports kernel) are you using?  I'd like to
> see how 160Mhz works on my firmware....
always state of art for sure

driver=nl80211
ctrl_interface=/var/run/hostapd
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5
country_code=DE
tx_queue_data2_burst=2.0
wmm_ac_be_txop_limit=64
ieee80211n=1
dynamic_ht40=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40][MAX-AMSDU-7935] 

vht_capab=[RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][RX-STBC-1][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMER][MU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7][BF-ANTENNA-2][SOUNDING-DIMENSION-2][BF-ANTENNA-3][SOUNDING-DIMENSION-3] 

ieee80211ac=1
vht_oper_chwidth=2
vht_oper_centr_freq_seg0_idx=114
hw_mode=a
channel=100
frequency=5500
beacon_int=100

dtim_period=2

interface=ath0
disassoc_low_ack=1
wds_sta=1
wmm_enabled=1
bssid=DC:EF:09:E4:CE:09
ignore_broadcast_ssid=0
max_num_sta=256
ssid=RHBRIDGE5
bridge=br0
logger_syslog=-1
logger_stdout=-1
logger_stdout_level=2
eapol_version=1
eapol_key_index_workaround=0
wpa=2
wpa_passphrase=***********
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
wpa_group_rekey=3600


bss=ath0.1
disassoc_low_ack=1
wmm_enabled=1
bssid=DE:EF:09:E4:CE:09
ignore_broadcast_ssid=0
max_num_sta=256
ssid=magrathea_5ghz
bridge=br0
logger_syslog=-1
logger_stdout=-1
logger_stdout_level=2
eapol_version=1
eapol_key_index_workaround=0
wpa=2
wpa_key_mgmt=WPA-EAP
ieee8021x=1
own_ip_addr=172.29.0.38
eap_server=0
auth_algs=1
radius_retry_primary_interval=600
auth_server_addr=172.29.0.33
auth_server_port=1812
auth_server_shared_secret=************
wpa_pairwise=CCMP
wpa_group_rekey=3600


>
> Thanks,
> Ben
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Ben Greear]

On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>> Hello
>>>
>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>> is there any internal structure change in these newer firmwares we need to consider?
>>> i also tested the even more recent firmware firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash but the vdev_start returns with a error
>>>
>>> i compared the more recent wmi headers from the qca drivers, but wasnt able to find anything which could explain the behaviour
>>>
>>> Sebastian
>>>
>>>
>>
>> Hello Sebastian,
>>
>> Could you share the hostapd/supplicant config file you are using?
>>
>> And, what kernel (or backports kernel) are you using?  I'd like to
>> see how 160Mhz works on my firmware....
> always state of art for sure

Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:

1486052184.818710: Mode: IEEE 802.11a  Channel: 100  Frequency: 5500 MHz
1486052184.818714: DFS 8 channels required radar detection
1486052184.818717: DFS all channels available, (SKIP CAC): no
1486052184.818719: DFS 0 chans unavailable - choose other channel: no
1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
1486052184.818725: DFS start CAC on 5500 MHz
1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 MHz)
1486052184.818742:   * freq=5500
1486052184.818745:   * vht_enabled=1
1486052184.818747:   * ht_enabled=1
1486052184.818749:   * bandwidth=160
1486052184.818751:   * channel_width=5
1486052184.818754:   * center_freq1=5570
1486052184.818756:   * center_freq2=0
1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
1486052184.823444: DFS start_dfs_cac() failed, -1


I'll go dig around to see if I can figure out why...

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

Re: 9984 VHT

[Ben Greear]

On 02/02/2017 08:18 AM, Ben Greear wrote:
> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>> Hello
>>>>
>>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>>> is there any internal structure change in these newer firmwares we need to consider?
>>>> i also tested the even more recent firmware firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash but the vdev_start returns with a error
>>>>
>>>> i compared the more recent wmi headers from the qca drivers, but wasnt able to find anything which could explain the behaviour
>>>>
>>>> Sebastian
>>>>
>>>>
>>>
>>> Hello Sebastian,
>>>
>>> Could you share the hostapd/supplicant config file you are using?
>>>
>>> And, what kernel (or backports kernel) are you using?  I'd like to
>>> see how 160Mhz works on my firmware....
>> always state of art for sure
>
> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:
>
> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100  Frequency: 5500 MHz
> 1486052184.818714: DFS 8 channels required radar detection
> 1486052184.818717: DFS all channels available, (SKIP CAC): no
> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
> 1486052184.818725: DFS start CAC on 5500 MHz
> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 MHz)
> 1486052184.818742:   * freq=5500
> 1486052184.818745:   * vht_enabled=1
> 1486052184.818747:   * ht_enabled=1
> 1486052184.818749:   * bandwidth=160
> 1486052184.818751:   * channel_width=5
> 1486052184.818754:   * center_freq1=5570
> 1486052184.818756:   * center_freq2=0
> 1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
> 1486052184.823444: DFS start_dfs_cac() failed, -1
>
>
> I'll go dig around to see if I can figure out why...

I hacked ath10k to enable radar detection on 160Mhz bandwidths.  Now hostapd
starts.

I can reproduce the FW failure.  It is because FW 3.3-25 release started asserting
if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and freq2, and not
how the driver or linux seems to normally use them.

I think I will back out the firmware changes in my FW, if driver ever wants to be compat
with both it is going to have to have nasty hacks I suppose.

If you have recent 10.4 FW source, look for convert_160MHz_single_center_freq_to_two_center_freq
and compare it to older FW versions.

Thanks,
Ben

>
> 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

Re: 9984 VHT

[Sebastian Gottschall]

Am 02.02.2017 um 19:24 schrieb Ben Greear:
> On 02/02/2017 08:18 AM, Ben Greear wrote:
>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>> Hello
>>>>>
>>>>> with recent 9984 firmares vht160 seem to crash the firmware itself 
>>>>> for no reason i see.
>>>>> is there any internal structure change in these newer firmwares we 
>>>>> need to consider?
>>>>> i also tested the even more recent firmware 
>>>>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt 
>>>>> crash but the vdev_start returns with a error
>>>>>
>>>>> i compared the more recent wmi headers from the qca drivers, but 
>>>>> wasnt able to find anything which could explain the behaviour
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>
>>>> Hello Sebastian,
>>>>
>>>> Could you share the hostapd/supplicant config file you are using?
>>>>
>>>> And, what kernel (or backports kernel) are you using?  I'd like to
>>>> see how 160Mhz works on my firmware....
>>> always state of art for sure
>>
>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get 
>> failure to start CAC:
>>
>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100  Frequency: 5500 MHz
>> 1486052184.818714: DFS 8 channels required radar detection
>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>> 1486052184.818725: DFS start CAC on 5500 MHz
>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, 
>> width=2, seg0=114, seg1=0, cac_time=60s
>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz 
>> (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 
>> MHz)
>> 1486052184.818742:   * freq=5500
>> 1486052184.818745:   * vht_enabled=1
>> 1486052184.818747:   * ht_enabled=1
>> 1486052184.818749:   * bandwidth=160
>> 1486052184.818751:   * channel_width=5
>> 1486052184.818754:   * center_freq1=5570
>> 1486052184.818756:   * center_freq2=0
>> 1486052184.823437: nl80211: Failed to start radar detection: -16 
>> (Device or resource busy)
>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>
>>
>> I'll go dig around to see if I can figure out why...
>
> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now 
> hostapd
> starts.
>
> I can reproduce the FW failure.  It is because FW 3.3-25 release 
> started asserting
> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and 
> freq2, and not
> how the driver or linux seems to normally use them.
its even worse. starting from 3.3 it uses freq2 instead of freq1. but i 
made a patch for it. but it still wont work. vdev_start still fails
>
> I think I will back out the firmware changes in my FW, if driver ever 
> wants to be compat
> with both it is going to have to have nasty hacks I suppose.
>
> If you have recent 10.4 FW source, look for 
> convert_160MHz_single_center_freq_to_two_center_freq
> and compare it to older FW versions.
i dont have a recent source, but the qca driver source which allows me 
to see how its called

>
> Thanks,
> Ben
>
>>
>> Thanks,
>> Ben
>>
>>
>
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Ben Greear]

On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>> Hello
>>>>>>
>>>>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>>>>> is there any internal structure change in these newer firmwares we need to consider?
>>>>>> i also tested the even more recent firmware firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash but the vdev_start returns with a error
>>>>>>
>>>>>> i compared the more recent wmi headers from the qca drivers, but wasnt able to find anything which could explain the behaviour
>>>>>>
>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>
>>>>> Hello Sebastian,
>>>>>
>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>
>>>>> And, what kernel (or backports kernel) are you using?  I'd like to
>>>>> see how 160Mhz works on my firmware....
>>>> always state of art for sure
>>>
>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:
>>>
>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100  Frequency: 5500 MHz
>>> 1486052184.818714: DFS 8 channels required radar detection
>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 MHz)
>>> 1486052184.818742:   * freq=5500
>>> 1486052184.818745:   * vht_enabled=1
>>> 1486052184.818747:   * ht_enabled=1
>>> 1486052184.818749:   * bandwidth=160
>>> 1486052184.818751:   * channel_width=5
>>> 1486052184.818754:   * center_freq1=5570
>>> 1486052184.818756:   * center_freq2=0
>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>
>>>
>>> I'll go dig around to see if I can figure out why...
>>
>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>> starts.
>>
>> I can reproduce the FW failure.  It is because FW 3.3-25 release started asserting
>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and freq2, and not
>> how the driver or linux seems to normally use them.
> its even worse. starting from 3.3 it uses freq2 instead of freq1. but i made a patch for it. but it still wont work. vdev_start still fails

Well it would have been helpful from the start to have known about this patch.

Could you post it?

Kalle:  Since the firmware API changed, how do you want to handle the differences here?

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

Re: 9984 VHT

[Sebastian Gottschall]

Am 02.02.2017 um 20:05 schrieb Ben Greear:
> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>> Hello
>>>>>>>
>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware 
>>>>>>> itself for no reason i see.
>>>>>>> is there any internal structure change in these newer firmwares 
>>>>>>> we need to consider?
>>>>>>> i also tested the even more recent firmware 
>>>>>>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt 
>>>>>>> crash but the vdev_start returns with a error
>>>>>>>
>>>>>>> i compared the more recent wmi headers from the qca drivers, but 
>>>>>>> wasnt able to find anything which could explain the behaviour
>>>>>>>
>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Hello Sebastian,
>>>>>>
>>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>>
>>>>>> And, what kernel (or backports kernel) are you using? I'd like to
>>>>>> see how 160Mhz works on my firmware....
>>>>> always state of art for sure
>>>>
>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get 
>>>> failure to start CAC:
>>>>
>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100 Frequency: 5500 
>>>> MHz
>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 
>>>> sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz 
>>>> (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, 
>>>> cf2=0 MHz)
>>>> 1486052184.818742:   * freq=5500
>>>> 1486052184.818745:   * vht_enabled=1
>>>> 1486052184.818747:   * ht_enabled=1
>>>> 1486052184.818749:   * bandwidth=160
>>>> 1486052184.818751:   * channel_width=5
>>>> 1486052184.818754:   * center_freq1=5570
>>>> 1486052184.818756:   * center_freq2=0
>>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 
>>>> (Device or resource busy)
>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>
>>>>
>>>> I'll go dig around to see if I can figure out why...
>>>
>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now 
>>> hostapd
>>> starts.
>>>
>>> I can reproduce the FW failure.  It is because FW 3.3-25 release 
>>> started asserting
>>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 
>>> and freq2, and not
>>> how the driver or linux seems to normally use them.
>> its even worse. starting from 3.3 it uses freq2 instead of freq1. but 
>> i made a patch for it. but it still wont work. vdev_start still fails
>
> Well it would have been helpful from the start to have known about 
> this patch.
i wasnt sure about it at that time. since it did not work
>
> Could you post it?
--- wmi.c       (revision 3267)
+++ wmi.c       (working copy)
@@ -1637,11 +1637,12 @@
                 flags |= WMI_CHAN_FLAG_DFS;

         ch->mhz = __cpu_to_le32(arg->freq);
+       ch->band_center_freq2 = 0;
         ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
         if (arg->mode == MODE_11AC_VHT80_80)
                 ch->band_center_freq2 = 
__cpu_to_le32(arg->band_center_freq2);
-       else
-               ch->band_center_freq2 = 0;
+       if (arg->mode == MODE_11AC_VHT160)
+               ch->band_center_freq2 = 
__cpu_to_le32(arg->band_center_freq1);
         ch->min_power = arg->min_power;
         ch->max_power = arg->max_power;
         ch->reg_power = arg->max_reg_power;

>
> Kalle:  Since the firmware API changed, how do you want to handle the 
> differences here?
>
> Thanks,
> Ben
>
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Ben Greear]

On 02/02/2017 11:08 AM, Sebastian Gottschall wrote:
> Am 02.02.2017 um 20:05 schrieb Ben Greear:
>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>>>>>>> is there any internal structure change in these newer firmwares we need to consider?
>>>>>>>> i also tested the even more recent firmware firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash but the vdev_start returns with a error
>>>>>>>>
>>>>>>>> i compared the more recent wmi headers from the qca drivers, but wasnt able to find anything which could explain the behaviour
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Hello Sebastian,
>>>>>>>
>>>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>>>
>>>>>>> And, what kernel (or backports kernel) are you using? I'd like to
>>>>>>> see how 160Mhz works on my firmware....
>>>>>> always state of art for sure
>>>>>
>>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:
>>>>>
>>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100 Frequency: 5500 MHz
>>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 MHz)
>>>>> 1486052184.818742:   * freq=5500
>>>>> 1486052184.818745:   * vht_enabled=1
>>>>> 1486052184.818747:   * ht_enabled=1
>>>>> 1486052184.818749:   * bandwidth=160
>>>>> 1486052184.818751:   * channel_width=5
>>>>> 1486052184.818754:   * center_freq1=5570
>>>>> 1486052184.818756:   * center_freq2=0
>>>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
>>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>>
>>>>>
>>>>> I'll go dig around to see if I can figure out why...
>>>>
>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>> starts.
>>>>
>>>> I can reproduce the FW failure.  It is because FW 3.3-25 release started asserting
>>>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and freq2, and not
>>>> how the driver or linux seems to normally use them.
>>> its even worse. starting from 3.3 it uses freq2 instead of freq1. but i made a patch for it. but it still wont work. vdev_start still fails
>>
>> Well it would have been helpful from the start to have known about this patch.
> i wasnt sure about it at that time. since it did not work
>>
>> Could you post it?
> --- wmi.c       (revision 3267)
> +++ wmi.c       (working copy)
> @@ -1637,11 +1637,12 @@
>                 flags |= WMI_CHAN_FLAG_DFS;
>
>         ch->mhz = __cpu_to_le32(arg->freq);
> +       ch->band_center_freq2 = 0;
>         ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
>         if (arg->mode == MODE_11AC_VHT80_80)
>                 ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
> -       else
> -               ch->band_center_freq2 = 0;
> +       if (arg->mode == MODE_11AC_VHT160)
> +               ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
>         ch->min_power = arg->min_power;
>         ch->max_power = arg->max_power;
>         ch->reg_power = arg->max_reg_power;

That would not appear to work with my FW, but, my FW's comments don't seem to match
it's code, so I am not sure where all the bugs lie.  Maybe re-check the source of this
patch above to make sure you got it right?

Thanks
Ben

>
>>
>> Kalle:  Since the firmware API changed, how do you want to handle the differences here?
>>
>> 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

Re: 9984 VHT

[Sebastian Gottschall]

Am 02.02.2017 um 20:18 schrieb Ben Greear:
> On 02/02/2017 11:08 AM, Sebastian Gottschall wrote:
>> Am 02.02.2017 um 20:05 schrieb Ben Greear:
>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>>>> Hello
>>>>>>>>>
>>>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware 
>>>>>>>>> itself for no reason i see.
>>>>>>>>> is there any internal structure change in these newer 
>>>>>>>>> firmwares we need to consider?
>>>>>>>>> i also tested the even more recent firmware 
>>>>>>>>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt 
>>>>>>>>> crash but the vdev_start returns with a error
>>>>>>>>>
>>>>>>>>> i compared the more recent wmi headers from the qca drivers, 
>>>>>>>>> but wasnt able to find anything which could explain the behaviour
>>>>>>>>>
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hello Sebastian,
>>>>>>>>
>>>>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>>>>
>>>>>>>> And, what kernel (or backports kernel) are you using? I'd like to
>>>>>>>> see how 160Mhz works on my firmware....
>>>>>>> always state of art for sure
>>>>>>
>>>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get 
>>>>>> failure to start CAC:
>>>>>>
>>>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100 Frequency: 
>>>>>> 5500 MHz
>>>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>>>> 1486052184.818719: DFS 0 chans unavailable - choose other 
>>>>>> channel: no
>>>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 
>>>>>> sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz 
>>>>>> (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, 
>>>>>> cf2=0 MHz)
>>>>>> 1486052184.818742:   * freq=5500
>>>>>> 1486052184.818745:   * vht_enabled=1
>>>>>> 1486052184.818747:   * ht_enabled=1
>>>>>> 1486052184.818749:   * bandwidth=160
>>>>>> 1486052184.818751:   * channel_width=5
>>>>>> 1486052184.818754:   * center_freq1=5570
>>>>>> 1486052184.818756:   * center_freq2=0
>>>>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 
>>>>>> (Device or resource busy)
>>>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>>>
>>>>>>
>>>>>> I'll go dig around to see if I can figure out why...
>>>>>
>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. 
>>>>> Now hostapd
>>>>> starts.
>>>>>
>>>>> I can reproduce the FW failure.  It is because FW 3.3-25 release 
>>>>> started asserting
>>>>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 
>>>>> and freq2, and not
>>>>> how the driver or linux seems to normally use them.
>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1. 
>>>> but i made a patch for it. but it still wont work. vdev_start still 
>>>> fails
>>>
>>> Well it would have been helpful from the start to have known about 
>>> this patch.
>> i wasnt sure about it at that time. since it did not work
>>>
>>> Could you post it?
>> --- wmi.c       (revision 3267)
>> +++ wmi.c       (working copy)
>> @@ -1637,11 +1637,12 @@
>>                 flags |= WMI_CHAN_FLAG_DFS;
>>
>>         ch->mhz = __cpu_to_le32(arg->freq);
>> +       ch->band_center_freq2 = 0;
>>         ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
>>         if (arg->mode == MODE_11AC_VHT80_80)
>>                 ch->band_center_freq2 = 
>> __cpu_to_le32(arg->band_center_freq2);
>> -       else
>> -               ch->band_center_freq2 = 0;
>> +       if (arg->mode == MODE_11AC_VHT160)
>> +               ch->band_center_freq2 = 
>> __cpu_to_le32(arg->band_center_freq1);
>>         ch->min_power = arg->min_power;
>>         ch->max_power = arg->max_power;
>>         ch->reg_power = arg->max_reg_power;
>
> That would not appear to work with my FW, but, my FW's comments don't 
> seem to match
> it's code, so I am not sure where all the bugs lie.  Maybe re-check 
> the source of this
> patch above to make sure you got it right?
its right if you already applied the vht160 patch which is in git 
already since a while (wireless-next)
in openwrt the staging tree of nbd contains the same source which which 
fits to this patch
but if it wont apply to you you have to update your whole wireless 
source to latest version since you did not have the required vht160 patches


this is the whole function.

void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
                                 const struct wmi_channel_arg *arg)
{
         u32 flags = 0;

         memset(ch, 0, sizeof(*ch));

         if (arg->passive)
                 flags |= WMI_CHAN_FLAG_PASSIVE;
         if (arg->allow_ibss)
                 flags |= WMI_CHAN_FLAG_ADHOC_ALLOWED;
         if (arg->allow_ht)
                 flags |= WMI_CHAN_FLAG_ALLOW_HT;
         if (arg->allow_vht)
                 flags |= WMI_CHAN_FLAG_ALLOW_VHT;
         if (arg->ht40plus)
                 flags |= WMI_CHAN_FLAG_HT40_PLUS;
         if (arg->chan_radar)
                 flags |= WMI_CHAN_FLAG_DFS;

         ch->mhz = __cpu_to_le32(arg->freq);
         ch->band_center_freq2 = 0;
         ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
         if (arg->mode == MODE_11AC_VHT80_80)
                 ch->band_center_freq2 = 
__cpu_to_le32(arg->band_center_freq2);
         if (arg->mode == MODE_11AC_VHT160)
                 ch->band_center_freq2 = 
__cpu_to_le32(arg->band_center_freq1);
         ch->min_power = arg->min_power;
         ch->max_power = arg->max_power;
         ch->reg_power = arg->max_reg_power;
         ch->antenna_max = arg->max_antenna_gain;
         ch->max_tx_power = arg->max_power;

         /* mode & flags share storage */
         ch->mode = arg->mode;
         ch->flags |= __cpu_to_le32(flags);
}

>
> Thanks
> Ben
>
>>
>>>
>>> Kalle:  Since the firmware API changed, how do you want to handle 
>>> the differences here?
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>
>>
>
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Ben Greear]

On 02/02/2017 11:29 AM, Sebastian Gottschall wrote:
> Am 02.02.2017 um 20:18 schrieb Ben Greear:
>> On 02/02/2017 11:08 AM, Sebastian Gottschall wrote:
>>> Am 02.02.2017 um 20:05 schrieb Ben Greear:
>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>>>>> Hello
>>>>>>>>>>
>>>>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>>>>>>>>> is there any internal structure change in these newer firmwares we need to consider?
>>>>>>>>>> i also tested the even more recent firmware firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash but the vdev_start returns with a error
>>>>>>>>>>
>>>>>>>>>> i compared the more recent wmi headers from the qca drivers, but wasnt able to find anything which could explain the behaviour
>>>>>>>>>>
>>>>>>>>>> Sebastian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello Sebastian,
>>>>>>>>>
>>>>>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>>>>>
>>>>>>>>> And, what kernel (or backports kernel) are you using? I'd like to
>>>>>>>>> see how 160Mhz works on my firmware....
>>>>>>>> always state of art for sure
>>>>>>>
>>>>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:
>>>>>>>
>>>>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100 Frequency: 5500 MHz
>>>>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>>>>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>>>>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 MHz)
>>>>>>> 1486052184.818742:   * freq=5500
>>>>>>> 1486052184.818745:   * vht_enabled=1
>>>>>>> 1486052184.818747:   * ht_enabled=1
>>>>>>> 1486052184.818749:   * bandwidth=160
>>>>>>> 1486052184.818751:   * channel_width=5
>>>>>>> 1486052184.818754:   * center_freq1=5570
>>>>>>> 1486052184.818756:   * center_freq2=0
>>>>>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
>>>>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>>>>
>>>>>>>
>>>>>>> I'll go dig around to see if I can figure out why...
>>>>>>
>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>>>> starts.
>>>>>>
>>>>>> I can reproduce the FW failure.  It is because FW 3.3-25 release started asserting
>>>>>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and freq2, and not
>>>>>> how the driver or linux seems to normally use them.
>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1. but i made a patch for it. but it still wont work. vdev_start still fails
>>>>
>>>> Well it would have been helpful from the start to have known about this patch.
>>> i wasnt sure about it at that time. since it did not work
>>>>
>>>> Could you post it?
>>> --- wmi.c       (revision 3267)
>>> +++ wmi.c       (working copy)
>>> @@ -1637,11 +1637,12 @@
>>>                 flags |= WMI_CHAN_FLAG_DFS;
>>>
>>>         ch->mhz = __cpu_to_le32(arg->freq);
>>> +       ch->band_center_freq2 = 0;
>>>         ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
>>>         if (arg->mode == MODE_11AC_VHT80_80)
>>>                 ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
>>> -       else
>>> -               ch->band_center_freq2 = 0;
>>> +       if (arg->mode == MODE_11AC_VHT160)
>>> +               ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
>>>         ch->min_power = arg->min_power;
>>>         ch->max_power = arg->max_power;
>>>         ch->reg_power = arg->max_reg_power;
>>
>> That would not appear to work with my FW, but, my FW's comments don't seem to match
>> it's code, so I am not sure where all the bugs lie.  Maybe re-check the source of this
>> patch above to make sure you got it right?
> its right if you already applied the vht160 patch which is in git already since a while (wireless-next)
> in openwrt the staging tree of nbd contains the same source which which fits to this patch
> but if it wont apply to you you have to update your whole wireless source to latest version since you did not have the required vht160 patches

I mean the content of the patch is invalid, not a merge issue.

Try setting freq1 to center-freq of the primary 80Mhz channel.
And set freq2 to center-freq of the 160Mhz channel.

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

Re: 9984 VHT

[Sebastian Gottschall]

Am 02.02.2017 um 20:32 schrieb Ben Greear:
> On 02/02/2017 11:29 AM, Sebastian Gottschall wrote:
>> Am 02.02.2017 um 20:18 schrieb Ben Greear:
>>> On 02/02/2017 11:08 AM, Sebastian Gottschall wrote:
>>>> Am 02.02.2017 um 20:05 schrieb Ben Greear:
>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>>>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>>>>>> Hello
>>>>>>>>>>>
>>>>>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware 
>>>>>>>>>>> itself for no reason i see.
>>>>>>>>>>> is there any internal structure change in these newer 
>>>>>>>>>>> firmwares we need to consider?
>>>>>>>>>>> i also tested the even more recent firmware 
>>>>>>>>>>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one 
>>>>>>>>>>> doesnt crash but the vdev_start returns with a error
>>>>>>>>>>>
>>>>>>>>>>> i compared the more recent wmi headers from the qca drivers, 
>>>>>>>>>>> but wasnt able to find anything which could explain the 
>>>>>>>>>>> behaviour
>>>>>>>>>>>
>>>>>>>>>>> Sebastian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello Sebastian,
>>>>>>>>>>
>>>>>>>>>> Could you share the hostapd/supplicant config file you are 
>>>>>>>>>> using?
>>>>>>>>>>
>>>>>>>>>> And, what kernel (or backports kernel) are you using? I'd 
>>>>>>>>>> like to
>>>>>>>>>> see how 160Mhz works on my firmware....
>>>>>>>>> always state of art for sure
>>>>>>>>
>>>>>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get 
>>>>>>>> failure to start CAC:
>>>>>>>>
>>>>>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100 Frequency: 
>>>>>>>> 5500 MHz
>>>>>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>>>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>>>>>> 1486052184.818719: DFS 0 chans unavailable - choose other 
>>>>>>>> channel: no
>>>>>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>>>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>>>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 
>>>>>>>> sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>>>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 
>>>>>>>> MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 
>>>>>>>> MHz, cf2=0 MHz)
>>>>>>>> 1486052184.818742:   * freq=5500
>>>>>>>> 1486052184.818745:   * vht_enabled=1
>>>>>>>> 1486052184.818747:   * ht_enabled=1
>>>>>>>> 1486052184.818749:   * bandwidth=160
>>>>>>>> 1486052184.818751:   * channel_width=5
>>>>>>>> 1486052184.818754:   * center_freq1=5570
>>>>>>>> 1486052184.818756:   * center_freq2=0
>>>>>>>> 1486052184.823437: nl80211: Failed to start radar detection: 
>>>>>>>> -16 (Device or resource busy)
>>>>>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>>>>>
>>>>>>>>
>>>>>>>> I'll go dig around to see if I can figure out why...
>>>>>>>
>>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. 
>>>>>>> Now hostapd
>>>>>>> starts.
>>>>>>>
>>>>>>> I can reproduce the FW failure.  It is because FW 3.3-25 release 
>>>>>>> started asserting
>>>>>>> if the freq2 was zero in VHT160 mode.  It seems to use both 
>>>>>>> freq1 and freq2, and not
>>>>>>> how the driver or linux seems to normally use them.
>>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1. 
>>>>>> but i made a patch for it. but it still wont work. vdev_start 
>>>>>> still fails
>>>>>
>>>>> Well it would have been helpful from the start to have known about 
>>>>> this patch.
>>>> i wasnt sure about it at that time. since it did not work
>>>>>
>>>>> Could you post it?
>>>> --- wmi.c       (revision 3267)
>>>> +++ wmi.c       (working copy)
>>>> @@ -1637,11 +1637,12 @@
>>>>                 flags |= WMI_CHAN_FLAG_DFS;
>>>>
>>>>         ch->mhz = __cpu_to_le32(arg->freq);
>>>> +       ch->band_center_freq2 = 0;
>>>>         ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
>>>>         if (arg->mode == MODE_11AC_VHT80_80)
>>>>                 ch->band_center_freq2 = 
>>>> __cpu_to_le32(arg->band_center_freq2);
>>>> -       else
>>>> -               ch->band_center_freq2 = 0;
>>>> +       if (arg->mode == MODE_11AC_VHT160)
>>>> +               ch->band_center_freq2 = 
>>>> __cpu_to_le32(arg->band_center_freq1);
>>>>         ch->min_power = arg->min_power;
>>>>         ch->max_power = arg->max_power;
>>>>         ch->reg_power = arg->max_reg_power;
>>>
>>> That would not appear to work with my FW, but, my FW's comments 
>>> don't seem to match
>>> it's code, so I am not sure where all the bugs lie.  Maybe re-check 
>>> the source of this
>>> patch above to make sure you got it right?
>> its right if you already applied the vht160 patch which is in git 
>> already since a while (wireless-next)
>> in openwrt the staging tree of nbd contains the same source which 
>> which fits to this patch
>> but if it wont apply to you you have to update your whole wireless 
>> source to latest version since you did not have the required vht160 
>> patches
>
> I mean the content of the patch is invalid, not a merge issue.
>
> Try setting freq1 to center-freq of the primary 80Mhz channel.
> And set freq2 to center-freq of the 160Mhz channel
so something like  that?

+       if (arg->mode == MODE_11AC_VHT160)  {
+               ch->band_center_freq1 = __cpu_to_le32(arg->freq);
+               ch->band_center_freq2 = 
__cpu_to_le32(arg->band_center_freq1);
+       }



Thanks,
> Ben
>
>
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Ben Greear]

On 02/02/2017 12:28 PM, Sebastian Gottschall wrote:
> Am 02.02.2017 um 20:32 schrieb Ben Greear:
>> On 02/02/2017 11:29 AM, Sebastian Gottschall wrote:
>>> Am 02.02.2017 um 20:18 schrieb Ben Greear:
>>>> On 02/02/2017 11:08 AM, Sebastian Gottschall wrote:
>>>>> Am 02.02.2017 um 20:05 schrieb Ben Greear:
>>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>>>>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>>>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>>>>>>> Hello
>>>>>>>>>>>>
>>>>>>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>>>>>>>>>>> is there any internal structure change in these newer firmwares we need to consider?
>>>>>>>>>>>> i also tested the even more recent firmware firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt crash but the vdev_start returns with a
>>>>>>>>>>>> error
>>>>>>>>>>>>
>>>>>>>>>>>> i compared the more recent wmi headers from the qca drivers, but wasnt able to find anything which could explain the behaviour
>>>>>>>>>>>>
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello Sebastian,
>>>>>>>>>>>
>>>>>>>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>>>>>>>
>>>>>>>>>>> And, what kernel (or backports kernel) are you using? I'd like to
>>>>>>>>>>> see how 160Mhz works on my firmware....
>>>>>>>>>> always state of art for sure
>>>>>>>>>
>>>>>>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:
>>>>>>>>>
>>>>>>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100 Frequency: 5500 MHz
>>>>>>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>>>>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>>>>>>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>>>>>>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>>>>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>>>>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>>>>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz, cf2=0 MHz)
>>>>>>>>> 1486052184.818742:   * freq=5500
>>>>>>>>> 1486052184.818745:   * vht_enabled=1
>>>>>>>>> 1486052184.818747:   * ht_enabled=1
>>>>>>>>> 1486052184.818749:   * bandwidth=160
>>>>>>>>> 1486052184.818751:   * channel_width=5
>>>>>>>>> 1486052184.818754:   * center_freq1=5570
>>>>>>>>> 1486052184.818756:   * center_freq2=0
>>>>>>>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
>>>>>>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'll go dig around to see if I can figure out why...
>>>>>>>>
>>>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>>>>>> starts.
>>>>>>>>
>>>>>>>> I can reproduce the FW failure.  It is because FW 3.3-25 release started asserting
>>>>>>>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and freq2, and not
>>>>>>>> how the driver or linux seems to normally use them.
>>>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1. but i made a patch for it. but it still wont work. vdev_start still fails
>>>>>>
>>>>>> Well it would have been helpful from the start to have known about this patch.
>>>>> i wasnt sure about it at that time. since it did not work
>>>>>>
>>>>>> Could you post it?
>>>>> --- wmi.c       (revision 3267)
>>>>> +++ wmi.c       (working copy)
>>>>> @@ -1637,11 +1637,12 @@
>>>>>                 flags |= WMI_CHAN_FLAG_DFS;
>>>>>
>>>>>         ch->mhz = __cpu_to_le32(arg->freq);
>>>>> +       ch->band_center_freq2 = 0;
>>>>>         ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
>>>>>         if (arg->mode == MODE_11AC_VHT80_80)
>>>>>                 ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
>>>>> -       else
>>>>> -               ch->band_center_freq2 = 0;
>>>>> +       if (arg->mode == MODE_11AC_VHT160)
>>>>> +               ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
>>>>>         ch->min_power = arg->min_power;
>>>>>         ch->max_power = arg->max_power;
>>>>>         ch->reg_power = arg->max_reg_power;
>>>>
>>>> That would not appear to work with my FW, but, my FW's comments don't seem to match
>>>> it's code, so I am not sure where all the bugs lie.  Maybe re-check the source of this
>>>> patch above to make sure you got it right?
>>> its right if you already applied the vht160 patch which is in git already since a while (wireless-next)
>>> in openwrt the staging tree of nbd contains the same source which which fits to this patch
>>> but if it wont apply to you you have to update your whole wireless source to latest version since you did not have the required vht160 patches
>>
>> I mean the content of the patch is invalid, not a merge issue.
>>
>> Try setting freq1 to center-freq of the primary 80Mhz channel.
>> And set freq2 to center-freq of the 160Mhz channel
> so something like  that?
>
> +       if (arg->mode == MODE_11AC_VHT160)  {
> +               ch->band_center_freq1 = __cpu_to_le32(arg->freq);
> +               ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
> +       }

No, I don't think so.  freq1 should be freq + 40 if freq < center-freq, otherwise
should be freq - 40.

freq2 settings above look correct.

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

Re: 9984 VHT

[Sebastian Gottschall]

Am 02.02.2017 um 21:37 schrieb Ben Greear:
> On 02/02/2017 12:28 PM, Sebastian Gottschall wrote:
>> Am 02.02.2017 um 20:32 schrieb Ben Greear:
>>> On 02/02/2017 11:29 AM, Sebastian Gottschall wrote:
>>>> Am 02.02.2017 um 20:18 schrieb Ben Greear:
>>>>> On 02/02/2017 11:08 AM, Sebastian Gottschall wrote:
>>>>>> Am 02.02.2017 um 20:05 schrieb Ben Greear:
>>>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>>>>>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>>>>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>>>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>>>>>>>> Hello
>>>>>>>>>>>>>
>>>>>>>>>>>>> with recent 9984 firmares vht160 seem to crash the 
>>>>>>>>>>>>> firmware itself for no reason i see.
>>>>>>>>>>>>> is there any internal structure change in these newer 
>>>>>>>>>>>>> firmwares we need to consider?
>>>>>>>>>>>>> i also tested the even more recent firmware 
>>>>>>>>>>>>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one 
>>>>>>>>>>>>> doesnt crash but the vdev_start returns with a
>>>>>>>>>>>>> error
>>>>>>>>>>>>>
>>>>>>>>>>>>> i compared the more recent wmi headers from the qca 
>>>>>>>>>>>>> drivers, but wasnt able to find anything which could 
>>>>>>>>>>>>> explain the behaviour
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hello Sebastian,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you share the hostapd/supplicant config file you are 
>>>>>>>>>>>> using?
>>>>>>>>>>>>
>>>>>>>>>>>> And, what kernel (or backports kernel) are you using? I'd 
>>>>>>>>>>>> like to
>>>>>>>>>>>> see how 160Mhz works on my firmware....
>>>>>>>>>>> always state of art for sure
>>>>>>>>>>
>>>>>>>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I 
>>>>>>>>>> get failure to start CAC:
>>>>>>>>>>
>>>>>>>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100 
>>>>>>>>>> Frequency: 5500 MHz
>>>>>>>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>>>>>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>>>>>>>> 1486052184.818719: DFS 0 chans unavailable - choose other 
>>>>>>>>>> channel: no
>>>>>>>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>>>>>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>>>>>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 
>>>>>>>>>> sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>>>>>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 
>>>>>>>>>> MHz (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 
>>>>>>>>>> MHz, cf2=0 MHz)
>>>>>>>>>> 1486052184.818742:   * freq=5500
>>>>>>>>>> 1486052184.818745:   * vht_enabled=1
>>>>>>>>>> 1486052184.818747:   * ht_enabled=1
>>>>>>>>>> 1486052184.818749:   * bandwidth=160
>>>>>>>>>> 1486052184.818751:   * channel_width=5
>>>>>>>>>> 1486052184.818754:   * center_freq1=5570
>>>>>>>>>> 1486052184.818756:   * center_freq2=0
>>>>>>>>>> 1486052184.823437: nl80211: Failed to start radar detection: 
>>>>>>>>>> -16 (Device or resource busy)
>>>>>>>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'll go dig around to see if I can figure out why...
>>>>>>>>>
>>>>>>>>> I hacked ath10k to enable radar detection on 160Mhz 
>>>>>>>>> bandwidths. Now hostapd
>>>>>>>>> starts.
>>>>>>>>>
>>>>>>>>> I can reproduce the FW failure.  It is because FW 3.3-25 
>>>>>>>>> release started asserting
>>>>>>>>> if the freq2 was zero in VHT160 mode.  It seems to use both 
>>>>>>>>> freq1 and freq2, and not
>>>>>>>>> how the driver or linux seems to normally use them.
>>>>>>>> its even worse. starting from 3.3 it uses freq2 instead of 
>>>>>>>> freq1. but i made a patch for it. but it still wont work. 
>>>>>>>> vdev_start still fails
>>>>>>>
>>>>>>> Well it would have been helpful from the start to have known 
>>>>>>> about this patch.
>>>>>> i wasnt sure about it at that time. since it did not work
>>>>>>>
>>>>>>> Could you post it?
>>>>>> --- wmi.c       (revision 3267)
>>>>>> +++ wmi.c       (working copy)
>>>>>> @@ -1637,11 +1637,12 @@
>>>>>>                 flags |= WMI_CHAN_FLAG_DFS;
>>>>>>
>>>>>>         ch->mhz = __cpu_to_le32(arg->freq);
>>>>>> +       ch->band_center_freq2 = 0;
>>>>>>         ch->band_center_freq1 = 
>>>>>> __cpu_to_le32(arg->band_center_freq1);
>>>>>>         if (arg->mode == MODE_11AC_VHT80_80)
>>>>>>                 ch->band_center_freq2 = 
>>>>>> __cpu_to_le32(arg->band_center_freq2);
>>>>>> -       else
>>>>>> -               ch->band_center_freq2 = 0;
>>>>>> +       if (arg->mode == MODE_11AC_VHT160)
>>>>>> +               ch->band_center_freq2 = 
>>>>>> __cpu_to_le32(arg->band_center_freq1);
>>>>>>         ch->min_power = arg->min_power;
>>>>>>         ch->max_power = arg->max_power;
>>>>>>         ch->reg_power = arg->max_reg_power;
>>>>>
>>>>> That would not appear to work with my FW, but, my FW's comments 
>>>>> don't seem to match
>>>>> it's code, so I am not sure where all the bugs lie.  Maybe 
>>>>> re-check the source of this
>>>>> patch above to make sure you got it right?
>>>> its right if you already applied the vht160 patch which is in git 
>>>> already since a while (wireless-next)
>>>> in openwrt the staging tree of nbd contains the same source which 
>>>> which fits to this patch
>>>> but if it wont apply to you you have to update your whole wireless 
>>>> source to latest version since you did not have the required vht160 
>>>> patches
>>>
>>> I mean the content of the patch is invalid, not a merge issue.
>>>
>>> Try setting freq1 to center-freq of the primary 80Mhz channel.
>>> And set freq2 to center-freq of the 160Mhz channel
>> so something like  that?
>>
>> +       if (arg->mode == MODE_11AC_VHT160)  {
>> +               ch->band_center_freq1 = __cpu_to_le32(arg->freq);
>> +               ch->band_center_freq2 = 
>> __cpu_to_le32(arg->band_center_freq1);
>> +       }
>
> No, I don't think so.  freq1 should be freq + 40 if freq < 
> center-freq, otherwise
> should be freq - 40.
doesnt sound very logic since 80+80 mode doesnt require that voodoo too 
since it would require another addition field. but i will try it it 
right now

>
> freq2 settings above look correct.
>
> Thanks,
> Ben
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Ben Greear]

On 02/02/2017 12:45 PM, Sebastian Gottschall wrote:

>>> +       if (arg->mode == MODE_11AC_VHT160)  {
>>> +               ch->band_center_freq1 = __cpu_to_le32(arg->freq);
>>> +               ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
>>> +       }
>>
>> No, I don't think so.  freq1 should be freq + 40 if freq < center-freq, otherwise
>> should be freq - 40.
> doesnt sound very logic since 80+80 mode doesnt require that voodoo too since it would require another addition field. but i will try it it right now

The firmware change looks pretty lame to me...it was easy for me to make my FW backwards compat
to the old way of just passing in the mhz and the freq1 160mhz center-freq, so really I do not know why
the FW was changed.

I am testing my FW fixes now...

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

Re: 9984 VHT

[Sebastian Gottschall]

even if hostapd starts now and ath10 doesnt brings any error. the 
interface does not broadcast any beacons nor can i scan for networks 
with it. all results are zero

Am 02.02.2017 um 21:50 schrieb Ben Greear:
> On 02/02/2017 12:45 PM, Sebastian Gottschall wrote:
>
>>>> +       if (arg->mode == MODE_11AC_VHT160)  {
>>>> +               ch->band_center_freq1 = __cpu_to_le32(arg->freq);
>>>> +               ch->band_center_freq2 = 
>>>> __cpu_to_le32(arg->band_center_freq1);
>>>> +       }
>>>
>>> No, I don't think so.  freq1 should be freq + 40 if freq < 
>>> center-freq, otherwise
>>> should be freq - 40.
>> doesnt sound very logic since 80+80 mode doesnt require that voodoo 
>> too since it would require another addition field. but i will try it 
>> it right now
>
> The firmware change looks pretty lame to me...it was easy for me to 
> make my FW backwards compat
> to the old way of just passing in the mhz and the freq1 160mhz 
> center-freq, so really I do not know why
> the FW was changed.
>
> I am testing my FW fixes now...
>
> Thanks,
> Ben
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Sebastian Gottschall]

this code here has been used

         if (arg->mode == MODE_11AC_VHT160)  {
                 if (arg->freq < arg->band_center_freq1)
                         ch->band_center_freq1 = __cpu_to_le32(arg->freq 
+ 40);
                 else
                         ch->band_center_freq1 = __cpu_to_le32(arg->freq 
- 40);
                 ch->band_center_freq2 = 
__cpu_to_le32(arg->band_center_freq1);
         }


Am 02.02.2017 um 21:50 schrieb Ben Greear:
> On 02/02/2017 12:45 PM, Sebastian Gottschall wrote:
>
>>>> +       if (arg->mode == MODE_11AC_VHT160)  {
>>>> +               ch->band_center_freq1 = __cpu_to_le32(arg->freq);
>>>> +               ch->band_center_freq2 = 
>>>> __cpu_to_le32(arg->band_center_freq1);
>>>> +       }
>>>
>>> No, I don't think so.  freq1 should be freq + 40 if freq < 
>>> center-freq, otherwise
>>> should be freq - 40.
>> doesnt sound very logic since 80+80 mode doesnt require that voodoo 
>> too since it would require another addition field. but i will try it 
>> it right now
>
> The firmware change looks pretty lame to me...it was easy for me to 
> make my FW backwards compat
> to the old way of just passing in the mhz and the freq1 160mhz 
> center-freq, so really I do not know why
> the FW was changed.
>
> I am testing my FW fixes now...
>
> Thanks,
> Ben
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Valo, Kalle]

Ben Greear <greearb@candelatech.com> writes:

> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>> Hello
>>>>>>>
>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>>>>>> is there any internal structure change in these newer firmwares we need to consider?
>>>>>>> i also tested the even more recent firmware
>>>>>>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt
>>>>>>> crash but the vdev_start returns with a error
>>>>>>>
>>>>>>> i compared the more recent wmi headers from the qca drivers,
>>>>>>> but wasnt able to find anything which could explain the
>>>>>>> behaviour
>>>>>>>
>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Hello Sebastian,
>>>>>>
>>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>>
>>>>>> And, what kernel (or backports kernel) are you using?  I'd like to
>>>>>> see how 160Mhz works on my firmware....
>>>>> always state of art for sure
>>>>
>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:
>>>>
>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100  Frequency: 5500 MHz
>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz
>>>> (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz,
>>>> cf2=0 MHz)
>>>> 1486052184.818742:   * freq=5500
>>>> 1486052184.818745:   * vht_enabled=1
>>>> 1486052184.818747:   * ht_enabled=1
>>>> 1486052184.818749:   * bandwidth=160
>>>> 1486052184.818751:   * channel_width=5
>>>> 1486052184.818754:   * center_freq1=5570
>>>> 1486052184.818756:   * center_freq2=0
>>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>
>>>>
>>>> I'll go dig around to see if I can figure out why...
>>>
>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>> starts.
>>>
>>> I can reproduce the FW failure.  It is because FW 3.3-25 release started asserting
>>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and freq2, and not
>>> how the driver or linux seems to normally use them.
>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>> but i made a patch for it. but it still wont work. vdev_start still
>> fails
>
> Well it would have been helpful from the start to have known about this patch.
>
> Could you post it?
>
> Kalle:  Since the firmware API changed, how do you want to handle the differences here?

The firmware API shouldn't change like that, but if it has I guess a
firmware feature flag to enable a workaround in ath10k sounds like the
easiest solution.

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

Re: 9984 VHT

[Sebastian Gottschall]

Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>>>>>>> is there any internal structure change in these newer firmwares we need to consider?
>>>>>>>> i also tested the even more recent firmware
>>>>>>>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt
>>>>>>>> crash but the vdev_start returns with a error
>>>>>>>>
>>>>>>>> i compared the more recent wmi headers from the qca drivers,
>>>>>>>> but wasnt able to find anything which could explain the
>>>>>>>> behaviour
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>>
>>>>>>> Hello Sebastian,
>>>>>>>
>>>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>>>
>>>>>>> And, what kernel (or backports kernel) are you using?  I'd like to
>>>>>>> see how 160Mhz works on my firmware....
>>>>>> always state of art for sure
>>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:
>>>>>
>>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100  Frequency: 5500 MHz
>>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz
>>>>> (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz,
>>>>> cf2=0 MHz)
>>>>> 1486052184.818742:   * freq=5500
>>>>> 1486052184.818745:   * vht_enabled=1
>>>>> 1486052184.818747:   * ht_enabled=1
>>>>> 1486052184.818749:   * bandwidth=160
>>>>> 1486052184.818751:   * channel_width=5
>>>>> 1486052184.818754:   * center_freq1=5570
>>>>> 1486052184.818756:   * center_freq2=0
>>>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
>>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>>
>>>>>
>>>>> I'll go dig around to see if I can figure out why...
>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>> starts.
>>>>
>>>> I can reproduce the FW failure.  It is because FW 3.3-25 release started asserting
>>>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and freq2, and not
>>>> how the driver or linux seems to normally use them.
>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>> but i made a patch for it. but it still wont work. vdev_start still
>>> fails
>> Well it would have been helpful from the start to have known about this patch.
>>
>> Could you post it?
>>
>> Kalle:  Since the firmware API changed, how do you want to handle the differences here?
> The firmware API shouldn't change like that, but if it has I guess a
> firmware feature flag to enable a workaround in ath10k sounds like the
> easiest solution.
the more recent firmware have some new wmi services enabled which can be 
used as indicator as well.
right now i'm able to run it in vht160 mode enabled. my problem is just 
that the station which uses 9984 as well does only show vht80 in assoc 
state, but interface status shows vht160.
still inclear what has been changed. i just know that the new handling 
in the firmware has something todo with a workaround for buggy vht80 
clients for backward compatiblity. a similar change has been made
in hostapd. its not clear why qca moved this workaround to the firmware 
code itself, since hostapd can manage this too
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Valo, Kalle]

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
>> Ben Greear <greearb@candelatech.com> writes:
>>
>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>
>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>>> starts.
>>>>>
>>>>> I can reproduce the FW failure. It is because FW 3.3-25 release
>>>>> started asserting
>>>>> if the freq2 was zero in VHT160 mode. It seems to use both freq1
>>>>> and freq2, and not
>>>>> how the driver or linux seems to normally use them.
>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>>> but i made a patch for it. but it still wont work. vdev_start still
>>>> fails
>>> Well it would have been helpful from the start to have known about this patch.
>>>
>>> Could you post it?
>>>
>>> Kalle: Since the firmware API changed, how do you want to handle
>>> the differences here?
>>
>> The firmware API shouldn't change like that, but if it has I guess a
>> firmware feature flag to enable a workaround in ath10k sounds like the
>> easiest solution.
>
> the more recent firmware have some new wmi services enabled which can
> be used as indicator as well.

I don't know what flag exactly you are referring to, but using a WMI
service flag to detect this is not really reliable. They can be enabled
or disabled between branches, or even between builds.

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

Re: 9984 VHT

[Valo, Kalle]

(you forgot to CC ath10k list, adding it back)

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> Am 10.02.2017 um 07:50 schrieb Valo, Kalle:
>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>
>>> Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
>>>> Ben Greear <greearb@candelatech.com> writes:
>>>>
>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>
>>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>>>>> starts.
>>>>>>>
>>>>>>> I can reproduce the FW failure. It is because FW 3.3-25 release
>>>>>>> started asserting
>>>>>>> if the freq2 was zero in VHT160 mode. It seems to use both freq1
>>>>>>> and freq2, and not
>>>>>>> how the driver or linux seems to normally use them.
>>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>>>>> but i made a patch for it. but it still wont work. vdev_start still
>>>>>> fails
>>>>> Well it would have been helpful from the start to have known about this patch.
>>>>>
>>>>> Could you post it?
>>>>>
>>>>> Kalle: Since the firmware API changed, how do you want to handle
>>>>> the differences here?
>>>> The firmware API shouldn't change like that, but if it has I guess a
>>>> firmware feature flag to enable a workaround in ath10k sounds like the
>>>> easiest solution.
>>> the more recent firmware have some new wmi services enabled which can
>>> be used as indicator as well.
>> I don't know what flag exactly you are referring to, but using a WMI
>> service flag to detect this is not really reliable. They can be enabled
>> or disabled between branches, or even between builds.
>
> valid argument. but these flags should than be also introduced in
> codeaurora images

I'm not involved with codeaurora images so I can't help with that.

But the firmware is not supposed to break the firmware interface like
this. Can someone please write a detailed bug report as a reply to this
mail (what version, from which location, how exactly the interface is
broken) and I'll try to report the issue internally.

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

Re: 9984 VHT

[Sebastian Gottschall]

Am 14.02.2017 um 11:30 schrieb Valo, Kalle:
> (you forgot to CC ath10k list, adding it back)
>
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> Am 10.02.2017 um 07:50 schrieb Valo, Kalle:
>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>
>>>> Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
>>>>> Ben Greear <greearb@candelatech.com> writes:
>>>>>
>>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>>
>>>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>>>>>> starts.
>>>>>>>>
>>>>>>>> I can reproduce the FW failure. It is because FW 3.3-25 release
>>>>>>>> started asserting
>>>>>>>> if the freq2 was zero in VHT160 mode. It seems to use both freq1
>>>>>>>> and freq2, and not
>>>>>>>> how the driver or linux seems to normally use them.
>>>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>>>>>> but i made a patch for it. but it still wont work. vdev_start still
>>>>>>> fails
>>>>>> Well it would have been helpful from the start to have known about this patch.
>>>>>>
>>>>>> Could you post it?
>>>>>>
>>>>>> Kalle: Since the firmware API changed, how do you want to handle
>>>>>> the differences here?
>>>>> The firmware API shouldn't change like that, but if it has I guess a
>>>>> firmware feature flag to enable a workaround in ath10k sounds like the
>>>>> easiest solution.
>>>> the more recent firmware have some new wmi services enabled which can
>>>> be used as indicator as well.
>>> I don't know what flag exactly you are referring to, but using a WMI
>>> service flag to detect this is not really reliable. They can be enabled
>>> or disabled between branches, or even between builds.
>> valid argument. but these flags should than be also introduced in
>> codeaurora images
> I'm not involved with codeaurora images so I can't help with that.
>
> But the firmware is not supposed to break the firmware interface like
> this. Can someone please write a detailed bug report as a reply to this
> mail (what version, from which location, how exactly the interface is
> broken) and I'll try to report the issue internally.
i'm not good in this. but let me try to describe whats wrong
all the current firmware images including your latest 3.3 based suffer 
from this issue.
old behaviour with 
https://github.com/kvalo/ath10k-firmware/raw/master/QCA9984/hw1.0/firmware-5.bin_10.4-3.2-00072
center freq is stored in band_center_freq1

new behaviour with 
https://github.com/kvalo/ath10k-firmware/raw/master/QCA9984/hw1.0/3.3/firmware-5.bin_10.4-3.3-00092 
and all other newers including 3.4 series
center freq is stored in band_center_freq2. where center_freq1 must 
contain the lower or upper side channel depending on the setting

example for new firmware in  ath10k_wmi_put_wmi_channel
         if (arg->mode == MODE_11AC_VHT160)  {
                 if (arg->freq < arg->band_center_freq1)
                         ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 - 40);
                 else
                         ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 + 40);
                 ch->band_center_freq2 = 
__cpu_to_le32(arg->band_center_freq1);
         }

according to some code i found in hostapd this has been made to 
workaround a issue with vht80 capable client who arent able to associate 
with vht160 networks.
the same workaround has been implemented in recent hostapd versions. so 
solving this on firmware side isnt neccessary, but qca was going this way

see also this patch which is now in mainline of hostapd

https://github.com/kaloz/mwlwifi/blob/master/hostapd/700-interoperability-workaround-for-80%2B80-and-160-MHz-channels

you will clearly see that it is related to the new behaviour of the 
qca9984 firmware (and likelly other vht160mhz capable chipset firmware, 
but i can't check them without having the devices)


>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Adrian Chadd]

aiee, some clients messed up freq1/freq2 handling in this way?



-adrian

On 14 February 2017 at 07:21, Sebastian Gottschall
<s.gottschall@dd-wrt.com> wrote:
> Am 14.02.2017 um 11:30 schrieb Valo, Kalle:
>>
>> (you forgot to CC ath10k list, adding it back)
>>
>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>
>>> Am 10.02.2017 um 07:50 schrieb Valo, Kalle:
>>>>
>>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>>
>>>>> Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
>>>>>>
>>>>>> Ben Greear <greearb@candelatech.com> writes:
>>>>>>
>>>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>>>>
>>>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>>>
>>>>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now
>>>>>>>>> hostapd
>>>>>>>>> starts.
>>>>>>>>>
>>>>>>>>> I can reproduce the FW failure. It is because FW 3.3-25 release
>>>>>>>>> started asserting
>>>>>>>>> if the freq2 was zero in VHT160 mode. It seems to use both freq1
>>>>>>>>> and freq2, and not
>>>>>>>>> how the driver or linux seems to normally use them.
>>>>>>>>
>>>>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>>>>>>> but i made a patch for it. but it still wont work. vdev_start still
>>>>>>>> fails
>>>>>>>
>>>>>>> Well it would have been helpful from the start to have known about
>>>>>>> this patch.
>>>>>>>
>>>>>>> Could you post it?
>>>>>>>
>>>>>>> Kalle: Since the firmware API changed, how do you want to handle
>>>>>>> the differences here?
>>>>>>
>>>>>> The firmware API shouldn't change like that, but if it has I guess a
>>>>>> firmware feature flag to enable a workaround in ath10k sounds like the
>>>>>> easiest solution.
>>>>>
>>>>> the more recent firmware have some new wmi services enabled which can
>>>>> be used as indicator as well.
>>>>
>>>> I don't know what flag exactly you are referring to, but using a WMI
>>>> service flag to detect this is not really reliable. They can be enabled
>>>> or disabled between branches, or even between builds.
>>>
>>> valid argument. but these flags should than be also introduced in
>>> codeaurora images
>>
>> I'm not involved with codeaurora images so I can't help with that.
>>
>> But the firmware is not supposed to break the firmware interface like
>> this. Can someone please write a detailed bug report as a reply to this
>> mail (what version, from which location, how exactly the interface is
>> broken) and I'll try to report the issue internally.
>
> i'm not good in this. but let me try to describe whats wrong
> all the current firmware images including your latest 3.3 based suffer from
> this issue.
> old behaviour with
> https://github.com/kvalo/ath10k-firmware/raw/master/QCA9984/hw1.0/firmware-5.bin_10.4-3.2-00072
> center freq is stored in band_center_freq1
>
> new behaviour with
> https://github.com/kvalo/ath10k-firmware/raw/master/QCA9984/hw1.0/3.3/firmware-5.bin_10.4-3.3-00092
> and all other newers including 3.4 series
> center freq is stored in band_center_freq2. where center_freq1 must contain
> the lower or upper side channel depending on the setting
>
> example for new firmware in  ath10k_wmi_put_wmi_channel
>         if (arg->mode == MODE_11AC_VHT160)  {
>                 if (arg->freq < arg->band_center_freq1)
>                         ch->band_center_freq1 =
> __cpu_to_le32(arg->band_center_freq1 - 40);
>                 else
>                         ch->band_center_freq1 =
> __cpu_to_le32(arg->band_center_freq1 + 40);
>                 ch->band_center_freq2 =
> __cpu_to_le32(arg->band_center_freq1);
>         }
>
> according to some code i found in hostapd this has been made to workaround a
> issue with vht80 capable client who arent able to associate with vht160
> networks.
> the same workaround has been implemented in recent hostapd versions. so
> solving this on firmware side isnt neccessary, but qca was going this way
>
> see also this patch which is now in mainline of hostapd
>
> https://github.com/kaloz/mwlwifi/blob/master/hostapd/700-interoperability-workaround-for-80%2B80-and-160-MHz-channels
>
> you will clearly see that it is related to the new behaviour of the qca9984
> firmware (and likelly other vht160mhz capable chipset firmware, but i can't
> check them without having the devices)
>
>
>>
>
>
> --
> Mit freundlichen Grüssen / Regards
>
> Sebastian Gottschall / CTO
>
> NewMedia-NET GmbH - DD-WRT
> Firmensitz:  Berliner Ring 101, 64625 Bensheim
> Registergericht: Amtsgericht Darmstadt, HRB 25473
> Geschäftsführer: Peter Steinhäuser, Christian Scheele
> http://www.dd-wrt.com
> email: s.gottschall@dd-wrt.com
> Tel.: +496251-582650 / Fax: +496251-5826565
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

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

Re: 9984 VHT

[Sebastian Gottschall]

Am 16.02.2017 um 17:20 schrieb Adrian Chadd:
> aiee, some clients messed up freq1/freq2 handling in this way?
as it seems. but i have no proof for this. i just readed the comment of 
the hostapd patch
but what i know is that breaking the api by handling this within the 
firmware itself instead of handling it in the accessible driver or 
hostapd is a bad decision
>
>
>
> -adrian
>
> On 14 February 2017 at 07:21, Sebastian Gottschall
> <s.gottschall@dd-wrt.com> wrote:
>> Am 14.02.2017 um 11:30 schrieb Valo, Kalle:
>>> (you forgot to CC ath10k list, adding it back)
>>>
>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>
>>>> Am 10.02.2017 um 07:50 schrieb Valo, Kalle:
>>>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>>>
>>>>>> Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
>>>>>>> Ben Greear <greearb@candelatech.com> writes:
>>>>>>>
>>>>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>>>>
>>>>>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now
>>>>>>>>>> hostapd
>>>>>>>>>> starts.
>>>>>>>>>>
>>>>>>>>>> I can reproduce the FW failure. It is because FW 3.3-25 release
>>>>>>>>>> started asserting
>>>>>>>>>> if the freq2 was zero in VHT160 mode. It seems to use both freq1
>>>>>>>>>> and freq2, and not
>>>>>>>>>> how the driver or linux seems to normally use them.
>>>>>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>>>>>>>> but i made a patch for it. but it still wont work. vdev_start still
>>>>>>>>> fails
>>>>>>>> Well it would have been helpful from the start to have known about
>>>>>>>> this patch.
>>>>>>>>
>>>>>>>> Could you post it?
>>>>>>>>
>>>>>>>> Kalle: Since the firmware API changed, how do you want to handle
>>>>>>>> the differences here?
>>>>>>> The firmware API shouldn't change like that, but if it has I guess a
>>>>>>> firmware feature flag to enable a workaround in ath10k sounds like the
>>>>>>> easiest solution.
>>>>>> the more recent firmware have some new wmi services enabled which can
>>>>>> be used as indicator as well.
>>>>> I don't know what flag exactly you are referring to, but using a WMI
>>>>> service flag to detect this is not really reliable. They can be enabled
>>>>> or disabled between branches, or even between builds.
>>>> valid argument. but these flags should than be also introduced in
>>>> codeaurora images
>>> I'm not involved with codeaurora images so I can't help with that.
>>>
>>> But the firmware is not supposed to break the firmware interface like
>>> this. Can someone please write a detailed bug report as a reply to this
>>> mail (what version, from which location, how exactly the interface is
>>> broken) and I'll try to report the issue internally.
>> i'm not good in this. but let me try to describe whats wrong
>> all the current firmware images including your latest 3.3 based suffer from
>> this issue.
>> old behaviour with
>> https://github.com/kvalo/ath10k-firmware/raw/master/QCA9984/hw1.0/firmware-5.bin_10.4-3.2-00072
>> center freq is stored in band_center_freq1
>>
>> new behaviour with
>> https://github.com/kvalo/ath10k-firmware/raw/master/QCA9984/hw1.0/3.3/firmware-5.bin_10.4-3.3-00092
>> and all other newers including 3.4 series
>> center freq is stored in band_center_freq2. where center_freq1 must contain
>> the lower or upper side channel depending on the setting
>>
>> example for new firmware in  ath10k_wmi_put_wmi_channel
>>          if (arg->mode == MODE_11AC_VHT160)  {
>>                  if (arg->freq < arg->band_center_freq1)
>>                          ch->band_center_freq1 =
>> __cpu_to_le32(arg->band_center_freq1 - 40);
>>                  else
>>                          ch->band_center_freq1 =
>> __cpu_to_le32(arg->band_center_freq1 + 40);
>>                  ch->band_center_freq2 =
>> __cpu_to_le32(arg->band_center_freq1);
>>          }
>>
>> according to some code i found in hostapd this has been made to workaround a
>> issue with vht80 capable client who arent able to associate with vht160
>> networks.
>> the same workaround has been implemented in recent hostapd versions. so
>> solving this on firmware side isnt neccessary, but qca was going this way
>>
>> see also this patch which is now in mainline of hostapd
>>
>> https://github.com/kaloz/mwlwifi/blob/master/hostapd/700-interoperability-workaround-for-80%2B80-and-160-MHz-channels
>>
>> you will clearly see that it is related to the new behaviour of the qca9984
>> firmware (and likelly other vht160mhz capable chipset firmware, but i can't
>> check them without having the devices)
>>
>>
>>
>> --
>> Mit freundlichen Grüssen / Regards
>>
>> Sebastian Gottschall / CTO
>>
>> NewMedia-NET GmbH - DD-WRT
>> Firmensitz:  Berliner Ring 101, 64625 Bensheim
>> Registergericht: Amtsgericht Darmstadt, HRB 25473
>> Geschäftsführer: Peter Steinhäuser, Christian Scheele
>> http://www.dd-wrt.com
>> email: s.gottschall@dd-wrt.com
>> Tel.: +496251-582650 / Fax: +496251-5826565
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


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

Re: 9984 VHT

[Adrian Chadd]

... looks like some changes for 802.11-2016 because yeah, some clients
don't handle 80+80/160MHz right...


-a

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

Re: 9984 VHT

[Valo, Kalle]

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> Am 14.02.2017 um 11:30 schrieb Valo, Kalle:
>> (you forgot to CC ath10k list, adding it back)
>>
>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>
>>> Am 10.02.2017 um 07:50 schrieb Valo, Kalle:
>>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>>
>>>>> Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
>>>>>> Ben Greear <greearb@candelatech.com> writes:
>>>>>>
>>>>>>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>>>>>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>>>>>>
>>>>>>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>>>>>>> starts.
>>>>>>>>>
>>>>>>>>> I can reproduce the FW failure. It is because FW 3.3-25 release
>>>>>>>>> started asserting
>>>>>>>>> if the freq2 was zero in VHT160 mode. It seems to use both freq1
>>>>>>>>> and freq2, and not
>>>>>>>>> how the driver or linux seems to normally use them.
>>>>>>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>>>>>>> but i made a patch for it. but it still wont work. vdev_start still
>>>>>>>> fails
>>>>>>> Well it would have been helpful from the start to have known about this patch.
>>>>>>>
>>>>>>> Could you post it?
>>>>>>>
>>>>>>> Kalle: Since the firmware API changed, how do you want to handle
>>>>>>> the differences here?
>>>>>> The firmware API shouldn't change like that, but if it has I guess a
>>>>>> firmware feature flag to enable a workaround in ath10k sounds like the
>>>>>> easiest solution.
>>>>> the more recent firmware have some new wmi services enabled which can
>>>>> be used as indicator as well.
>>>> I don't know what flag exactly you are referring to, but using a WMI
>>>> service flag to detect this is not really reliable. They can be enabled
>>>> or disabled between branches, or even between builds.
>>> valid argument. but these flags should than be also introduced in
>>> codeaurora images
>> I'm not involved with codeaurora images so I can't help with that.
>>
>> But the firmware is not supposed to break the firmware interface like
>> this. Can someone please write a detailed bug report as a reply to this
>> mail (what version, from which location, how exactly the interface is
>> broken) and I'll try to report the issue internally.
>
> i'm not good in this. but let me try to describe whats wrong

Thanks, this was good. I sent this forward now.

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

Re: QCA988X firmware pull-push support

[Sergey Ryazanov]

On Mon, Jan 30, 2017 at 11:13 AM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
> Adrian Chadd <adrian.chadd@gmail.com> writes:
>
>> On 29 January 2017 at 17:20, Sergey Ryazanov <ryazanov.s.a@gmail.com> wrote:
>>> Yep. Looks like so.
>>
>> Which is good, because my FreeBSD ath10k port only works with 10.1 /
>> 10.2 firmware on earlier chips, and I haven't figured out the
>> intermediate software queue support that came with 10.4. :-)
>>
>> But yeah. I'll wake for Kalle to verify, but I think it's a 10.4
>> thing
>
> So there are two parts here, ieee80211_ops::wake_tx_queue() support in
> ath10k and ATH10K_FW_FEATURE_PEER_FLOW_CONTROL in firmware. We did have
> wake_tx_queue() support enabled for all hw/fw combinations but it was
> changed because some people claimed there are throughput regressions in
> certain cases. So for now we only enable wake_tx_queue() support only if
> firmware supports ATH10K_FW_FEATURE_PEER_FLOW_CONTROL:
>
>         if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
>                       ar->running_fw->fw_file.fw_features))
>                 ar->ops->wake_tx_queue = NULL;
>
> I remember that there were some improvements with wake_tx_queue() even
> if firmware didn't support ATH10K_FW_FEATURE_PEER_FLOW_CONTROL.

Yes, Rajkumar Manoharan made some fix for wake_tx_queue (). I think
that I could test this fix with QCA988x in the couple of weeks. May be
we could return to total intermediate queues support.

> I'm
> starting to wonder should we have a module parameter to force use of
> wake_tx_queue()?

Maybe. This could be useful at stage of final testing, if the last fix
for wake_tx_queue() really solves the performance issues. Before we
returning to total support of intermediate queues.

> And IIRC ATH10K_FW_FEATURE_PEER_FLOW_CONTROL was supported in some of
> 10.4 releases, but not all of them.

Yep, only few of 10.4 firmware have support of tx pull-push mode.

-- 
Sergey

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