9984 VHT
Sebastian Gottschall
s.gottschall at dd-wrt.com
Thu Feb 2 12:45:10 PST 2017
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 at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
More information about the ath10k
mailing list