| Message ID | a58d42c2-84ca-1c17-8591-b20bfd91660c@dd-wrt.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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 >
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
--- 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);