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