9984 VHT

[Ben Greear]

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

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

Thanks
Ben

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


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com