* QCA988X firmware pull-push support @ 2017-01-29 23:11 Sergey Ryazanov [not found] ` <CAJ-Vmo=yD7Ct5LFXBO3qNhKsNco91VXMmZOYeBaAuw+DFGq=RQ@mail.gmail.com> 0 siblings, 1 reply; 31+ messages in thread From: Sergey Ryazanov @ 2017-01-29 23:11 UTC (permalink / raw) To: Kalle Valo; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <CAJ-Vmo=yD7Ct5LFXBO3qNhKsNco91VXMmZOYeBaAuw+DFGq=RQ@mail.gmail.com>]
* Re: QCA988X firmware pull-push support [not found] ` <CAJ-Vmo=yD7Ct5LFXBO3qNhKsNco91VXMmZOYeBaAuw+DFGq=RQ@mail.gmail.com> @ 2017-01-30 1:20 ` Sergey Ryazanov 2017-01-30 2:50 ` Adrian Chadd 0 siblings, 1 reply; 31+ messages in thread From: Sergey Ryazanov @ 2017-01-30 1:20 UTC (permalink / raw) To: Adrian Chadd; +Cc: Kalle Valo, ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: QCA988X firmware pull-push support 2017-01-30 1:20 ` Sergey Ryazanov @ 2017-01-30 2:50 ` Adrian Chadd 2017-01-30 8:13 ` Valo, Kalle 0 siblings, 1 reply; 31+ messages in thread From: Adrian Chadd @ 2017-01-30 2:50 UTC (permalink / raw) To: Sergey Ryazanov; +Cc: Kalle Valo, ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: QCA988X firmware pull-push support 2017-01-30 2:50 ` Adrian Chadd @ 2017-01-30 8:13 ` Valo, Kalle 2017-01-30 10:28 ` 9984 VHT Sebastian Gottschall 2017-02-01 8:21 ` QCA988X firmware pull-push support Sergey Ryazanov 0 siblings, 2 replies; 31+ messages in thread From: Valo, Kalle @ 2017-01-30 8:13 UTC (permalink / raw) To: Adrian Chadd; +Cc: Sergey Ryazanov, ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* 9984 VHT 2017-01-30 8:13 ` Valo, Kalle @ 2017-01-30 10:28 ` Sebastian Gottschall 2017-02-01 16:48 ` Ben Greear 2017-02-01 8:21 ` QCA988X firmware pull-push support Sergey Ryazanov 1 sibling, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-01-30 10:28 UTC (permalink / raw) To: Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-01-30 10:28 ` 9984 VHT Sebastian Gottschall @ 2017-02-01 16:48 ` Ben Greear 2017-02-01 18:45 ` Sebastian Gottschall 0 siblings, 1 reply; 31+ messages in thread From: Ben Greear @ 2017-02-01 16:48 UTC (permalink / raw) To: Sebastian Gottschall, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-01 16:48 ` Ben Greear @ 2017-02-01 18:45 ` Sebastian Gottschall 2017-02-02 16:18 ` Ben Greear 0 siblings, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-01 18:45 UTC (permalink / raw) To: Ben Greear, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-01 18:45 ` Sebastian Gottschall @ 2017-02-02 16:18 ` Ben Greear 2017-02-02 18:24 ` Ben Greear 0 siblings, 1 reply; 31+ messages in thread From: Ben Greear @ 2017-02-02 16:18 UTC (permalink / raw) To: Sebastian Gottschall, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 16:18 ` Ben Greear @ 2017-02-02 18:24 ` Ben Greear 2017-02-02 18:42 ` Sebastian Gottschall 0 siblings, 1 reply; 31+ messages in thread From: Ben Greear @ 2017-02-02 18:24 UTC (permalink / raw) To: Sebastian Gottschall, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 18:24 ` Ben Greear @ 2017-02-02 18:42 ` Sebastian Gottschall 2017-02-02 19:05 ` Ben Greear 0 siblings, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-02 18:42 UTC (permalink / raw) To: Ben Greear, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 18:42 ` Sebastian Gottschall @ 2017-02-02 19:05 ` Ben Greear 2017-02-02 19:08 ` Sebastian Gottschall 2017-02-07 12:14 ` Valo, Kalle 0 siblings, 2 replies; 31+ messages in thread From: Ben Greear @ 2017-02-02 19:05 UTC (permalink / raw) To: Sebastian Gottschall, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 19:05 ` Ben Greear @ 2017-02-02 19:08 ` Sebastian Gottschall 2017-02-02 19:18 ` Ben Greear 2017-02-07 12:14 ` Valo, Kalle 1 sibling, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-02 19:08 UTC (permalink / raw) To: Ben Greear, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 19:08 ` Sebastian Gottschall @ 2017-02-02 19:18 ` Ben Greear 2017-02-02 19:29 ` Sebastian Gottschall 0 siblings, 1 reply; 31+ messages in thread From: Ben Greear @ 2017-02-02 19:18 UTC (permalink / raw) To: Sebastian Gottschall, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 19:18 ` Ben Greear @ 2017-02-02 19:29 ` Sebastian Gottschall 2017-02-02 19:32 ` Ben Greear 0 siblings, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-02 19:29 UTC (permalink / raw) To: Ben Greear, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 19:29 ` Sebastian Gottschall @ 2017-02-02 19:32 ` Ben Greear 2017-02-02 20:28 ` Sebastian Gottschall 0 siblings, 1 reply; 31+ messages in thread From: Ben Greear @ 2017-02-02 19:32 UTC (permalink / raw) To: Sebastian Gottschall, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 19:32 ` Ben Greear @ 2017-02-02 20:28 ` Sebastian Gottschall 2017-02-02 20:37 ` Ben Greear 0 siblings, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-02 20:28 UTC (permalink / raw) To: Ben Greear, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 20:28 ` Sebastian Gottschall @ 2017-02-02 20:37 ` Ben Greear 2017-02-02 20:45 ` Sebastian Gottschall 0 siblings, 1 reply; 31+ messages in thread From: Ben Greear @ 2017-02-02 20:37 UTC (permalink / raw) To: Sebastian Gottschall, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 20:37 ` Ben Greear @ 2017-02-02 20:45 ` Sebastian Gottschall 2017-02-02 20:50 ` Ben Greear 0 siblings, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-02 20:45 UTC (permalink / raw) To: Ben Greear, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 20:45 ` Sebastian Gottschall @ 2017-02-02 20:50 ` Ben Greear 2017-02-02 21:01 ` Sebastian Gottschall 2017-02-02 21:04 ` Sebastian Gottschall 0 siblings, 2 replies; 31+ messages in thread From: Ben Greear @ 2017-02-02 20:50 UTC (permalink / raw) To: Sebastian Gottschall, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 20:50 ` Ben Greear @ 2017-02-02 21:01 ` Sebastian Gottschall 2017-02-02 21:04 ` Sebastian Gottschall 1 sibling, 0 replies; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-02 21:01 UTC (permalink / raw) To: Ben Greear, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 20:50 ` Ben Greear 2017-02-02 21:01 ` Sebastian Gottschall @ 2017-02-02 21:04 ` Sebastian Gottschall 1 sibling, 0 replies; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-02 21:04 UTC (permalink / raw) To: Ben Greear, Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-02 19:05 ` Ben Greear 2017-02-02 19:08 ` Sebastian Gottschall @ 2017-02-07 12:14 ` Valo, Kalle 2017-02-07 12:39 ` Sebastian Gottschall 1 sibling, 1 reply; 31+ messages in thread From: Valo, Kalle @ 2017-02-07 12:14 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k, Sebastian Gottschall 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-07 12:14 ` Valo, Kalle @ 2017-02-07 12:39 ` Sebastian Gottschall 2017-02-10 6:50 ` Valo, Kalle 0 siblings, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-07 12:39 UTC (permalink / raw) To: Valo, Kalle, Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-07 12:39 ` Sebastian Gottschall @ 2017-02-10 6:50 ` Valo, Kalle [not found] ` <c894f9ae-068a-eac3-16e6-c1ada4da22b9@dd-wrt.com> 0 siblings, 1 reply; 31+ messages in thread From: Valo, Kalle @ 2017-02-10 6:50 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: Ben Greear, ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <c894f9ae-068a-eac3-16e6-c1ada4da22b9@dd-wrt.com>]
* Re: 9984 VHT [not found] ` <c894f9ae-068a-eac3-16e6-c1ada4da22b9@dd-wrt.com> @ 2017-02-14 10:30 ` Valo, Kalle 2017-02-14 15:21 ` Sebastian Gottschall 0 siblings, 1 reply; 31+ messages in thread From: Valo, Kalle @ 2017-02-14 10:30 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k (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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-14 10:30 ` Valo, Kalle @ 2017-02-14 15:21 ` Sebastian Gottschall 2017-02-16 16:20 ` Adrian Chadd 2017-02-20 15:40 ` Valo, Kalle 0 siblings, 2 replies; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-14 15:21 UTC (permalink / raw) To: Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-14 15:21 ` Sebastian Gottschall @ 2017-02-16 16:20 ` Adrian Chadd 2017-02-16 16:34 ` Sebastian Gottschall 2017-02-20 15:40 ` Valo, Kalle 1 sibling, 1 reply; 31+ messages in thread From: Adrian Chadd @ 2017-02-16 16:20 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: Valo, Kalle, ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-16 16:20 ` Adrian Chadd @ 2017-02-16 16:34 ` Sebastian Gottschall 2017-02-17 5:42 ` Adrian Chadd 0 siblings, 1 reply; 31+ messages in thread From: Sebastian Gottschall @ 2017-02-16 16:34 UTC (permalink / raw) To: Adrian Chadd; +Cc: Valo, Kalle, ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-16 16:34 ` Sebastian Gottschall @ 2017-02-17 5:42 ` Adrian Chadd 0 siblings, 0 replies; 31+ messages in thread From: Adrian Chadd @ 2017-02-17 5:42 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: Valo, Kalle, ath10k ... 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 9984 VHT 2017-02-14 15:21 ` Sebastian Gottschall 2017-02-16 16:20 ` Adrian Chadd @ 2017-02-20 15:40 ` Valo, Kalle 1 sibling, 0 replies; 31+ messages in thread From: Valo, Kalle @ 2017-02-20 15:40 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: QCA988X firmware pull-push support 2017-01-30 8:13 ` Valo, Kalle 2017-01-30 10:28 ` 9984 VHT Sebastian Gottschall @ 2017-02-01 8:21 ` Sergey Ryazanov 1 sibling, 0 replies; 31+ messages in thread From: Sergey Ryazanov @ 2017-02-01 8:21 UTC (permalink / raw) To: Valo, Kalle; +Cc: Adrian Chadd, ath10k 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2017-02-20 15:41 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-29 23:11 QCA988X firmware pull-push support Sergey Ryazanov [not found] ` <CAJ-Vmo=yD7Ct5LFXBO3qNhKsNco91VXMmZOYeBaAuw+DFGq=RQ@mail.gmail.com> 2017-01-30 1:20 ` Sergey Ryazanov 2017-01-30 2:50 ` Adrian Chadd 2017-01-30 8:13 ` Valo, Kalle 2017-01-30 10:28 ` 9984 VHT Sebastian Gottschall 2017-02-01 16:48 ` Ben Greear 2017-02-01 18:45 ` Sebastian Gottschall 2017-02-02 16:18 ` Ben Greear 2017-02-02 18:24 ` Ben Greear 2017-02-02 18:42 ` Sebastian Gottschall 2017-02-02 19:05 ` Ben Greear 2017-02-02 19:08 ` Sebastian Gottschall 2017-02-02 19:18 ` Ben Greear 2017-02-02 19:29 ` Sebastian Gottschall 2017-02-02 19:32 ` Ben Greear 2017-02-02 20:28 ` Sebastian Gottschall 2017-02-02 20:37 ` Ben Greear 2017-02-02 20:45 ` Sebastian Gottschall 2017-02-02 20:50 ` Ben Greear 2017-02-02 21:01 ` Sebastian Gottschall 2017-02-02 21:04 ` Sebastian Gottschall 2017-02-07 12:14 ` Valo, Kalle 2017-02-07 12:39 ` Sebastian Gottschall 2017-02-10 6:50 ` Valo, Kalle [not found] ` <c894f9ae-068a-eac3-16e6-c1ada4da22b9@dd-wrt.com> 2017-02-14 10:30 ` Valo, Kalle 2017-02-14 15:21 ` Sebastian Gottschall 2017-02-16 16:20 ` Adrian Chadd 2017-02-16 16:34 ` Sebastian Gottschall 2017-02-17 5:42 ` Adrian Chadd 2017-02-20 15:40 ` Valo, Kalle 2017-02-01 8:21 ` QCA988X firmware pull-push support Sergey Ryazanov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.