9984 with 10.4.3.5.3-0057 crashes
diff mbox

Message ID a58d42c2-84ca-1c17-8591-b20bfd91660c@dd-wrt.com
State New
Headers show

Commit Message

Sebastian Gottschall April 24, 2018, 6:08 a.m. UTC
Am 24.04.2018 um 07:27 schrieb Kalle Valo:
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> just for your notice. 10.4.3.5.3-0057 on 9984 which was just released
>> crashes in vht160 operation mode immediatly after first station
>> associates
>> last known working stable fw so far is 10.4-3.4-00104. the whole
>> 10.4.3.5.3 series seem to be seriously broken or the api has been
>> changed in a way
>> which is unsupported by ath10k (which i think is the cause of the 
>> problem)
>> it would be good to know what has been changed.
> At least I was not informed any changes in the firmware interface. What
> version of ath10k are you using? Do you have any custom patches on
> ath10k?
i'm using latest git version for testing here
but there is one relevant patch required for more recent firmwares like 
3.4 series (see below)
i posted already a long time ago, that vht160 will not work anymore 
without that patch in newer firmwares since
qca changed the api for channel mapping in vht160. (i took this 
information from the propertiery qca driver sourcecodes)
see our discussion on 2.feb 2017 about that required change. it seems 
that you lost the path on that issue.
as far as i know this change was required because of compatiblity issues 
with vht80 clients from some other vendors.
i have seen similar changes in hostapd for mwlwifi driver

+       }
         ch->min_power = arg->min_power;
         ch->max_power = arg->max_power;
         ch->reg_power = arg->max_reg_power;

>

Comments

Kalle Valo April 25, 2018, 3:23 p.m. UTC | #1
Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> Am 24.04.2018 um 07:27 schrieb Kalle Valo:
>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>
>>> just for your notice. 10.4.3.5.3-0057 on 9984 which was just released
>>> crashes in vht160 operation mode immediatly after first station
>>> associates
>>> last known working stable fw so far is 10.4-3.4-00104. the whole
>>> 10.4.3.5.3 series seem to be seriously broken or the api has been
>>> changed in a way
>>> which is unsupported by ath10k (which i think is the cause of the
>>> problem)
>>> it would be good to know what has been changed.
>>
>> At least I was not informed any changes in the firmware interface. What
>> version of ath10k are you using? Do you have any custom patches on
>> ath10k?
>
> i'm using latest git version for testing here but there is one
> relevant patch required for more recent firmwares like 3.4 series (see
> below) i posted already a long time ago, that vht160 will not work
> anymore without that patch in newer firmwares since qca changed the api
> for channel mapping in vht160.

I don't remember what happened to that patch, but please resubmit it
with a proper commit log and S-o-b line.

I was told that the firmware crash is an assert triggered by host not
populating the parameter 'peer_bw_rxnss_override' in
WMI_PEER_ASSOC_CMDID which is needed for 160/80+80 operation.
Sebastian Gottschall April 26, 2018, 6:23 a.m. UTC | #2
Am 25.04.2018 um 17:23 schrieb Kalle Valo:
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> Am 24.04.2018 um 07:27 schrieb Kalle Valo:
>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>
>>>> just for your notice. 10.4.3.5.3-0057 on 9984 which was just released
>>>> crashes in vht160 operation mode immediatly after first station
>>>> associates
>>>> last known working stable fw so far is 10.4-3.4-00104. the whole
>>>> 10.4.3.5.3 series seem to be seriously broken or the api has been
>>>> changed in a way
>>>> which is unsupported by ath10k (which i think is the cause of the
>>>> problem)
>>>> it would be good to know what has been changed.
>>> At least I was not informed any changes in the firmware interface. What
>>> version of ath10k are you using? Do you have any custom patches on
>>> ath10k?
>> i'm using latest git version for testing here but there is one
>> relevant patch required for more recent firmwares like 3.4 series (see
>> below) i posted already a long time ago, that vht160 will not work
>> anymore without that patch in newer firmwares since qca changed the api
>> for channel mapping in vht160.
> I don't remember what happened to that patch, but please resubmit it
> with a proper commit log and S-o-b line.
will do asap.
>
> I was told that the firmware crash is an assert triggered by host not
> populating the parameter 'peer_bw_rxnss_override' in
> WMI_PEER_ASSOC_CMDID which is needed for 160/80+80 operation.
peer_bw_rxnss_override is calculated by taking peers rx_max_rate
if its 1560 peer_bw_rxnss_override will be 2
if its 780 peer_bw_rxnss_override will be 1

so for me this all looks wrong. die parameter for vht160 looks guessed 
based on the rx rate and may result in wrong values.
since the peer is also supplying the bandwidth itself, we dont need to 
guess vht160 operation.
i will try to fix this and will post a fix once its solved

Sebastian
>
Sebastian Gottschall April 26, 2018, 7:36 a.m. UTC | #3
Am 25.04.2018 um 17:23 schrieb Kalle Valo:
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> Am 24.04.2018 um 07:27 schrieb Kalle Valo:
>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>
>>>> just for your notice. 10.4.3.5.3-0057 on 9984 which was just released
>>>> crashes in vht160 operation mode immediatly after first station
>>>> associates
>>>> last known working stable fw so far is 10.4-3.4-00104. the whole
>>>> 10.4.3.5.3 series seem to be seriously broken or the api has been
>>>> changed in a way
>>>> which is unsupported by ath10k (which i think is the cause of the
>>>> problem)
>>>> it would be good to know what has been changed.
>>> At least I was not informed any changes in the firmware interface. What
>>> version of ath10k are you using? Do you have any custom patches on
>>> ath10k?
>> i'm using latest git version for testing here but there is one
>> relevant patch required for more recent firmwares like 3.4 series (see
>> below) i posted already a long time ago, that vht160 will not work
>> anymore without that patch in newer firmwares since qca changed the api
>> for channel mapping in vht160.
> I don't remember what happened to that patch, but please resubmit it
> with a proper commit log and S-o-b line.
>
> I was told that the firmware crash is an assert triggered by host not
> populating the parameter 'peer_bw_rxnss_override' in
> WMI_PEER_ASSOC_CMDID which is needed for 160/80+80 operation.
good news. your hint helped me to develop a fix. will post the patch 
soon here

Patch
diff mbox

--- wmi.c.old   2018-02-16 11:25:13.023117123 +0100
+++ wmi.c       2018-04-24 07:47:12.642395002 +0200
@@ -1661,13 +1661,18 @@  void ath10k_wmi_put_wmi_channel(struct w
                 flags |= WMI_CHAN_FLAG_HT40_PLUS;
         if (arg->chan_radar)
                 flags |= WMI_CHAN_FLAG_DFS;
-
+       ch->band_center_freq2 = 0;
         ch->mhz = __cpu_to_le32(arg->freq);
         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)  {
+               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);