| Message ID | 14bd9f40-a79c-5032-778f-2f2ae92afccc@dd-wrt.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Kalle Valo |
| Headers | show |
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 >> >> > >
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 >>> >>> >> >> > >
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. Thanks, Ben
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); + } Thanks, > Ben > > >
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. freq2 settings above look correct. Thanks, Ben
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 >
On 02/02/2017 12:45 PM, Sebastian Gottschall wrote: >>> + 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 The firmware change looks pretty lame to me...it was easy for me to make my FW backwards compat to the old way of just passing in the mhz and the freq1 160mhz center-freq, so really I do not know why the FW was changed. I am testing my FW fixes now... Thanks, Ben
even if hostapd starts now and ath10 doesnt brings any error. the interface does not broadcast any beacons nor can i scan for networks with it. all results are zero Am 02.02.2017 um 21:50 schrieb Ben Greear: > On 02/02/2017 12:45 PM, Sebastian Gottschall wrote: > >>>> + 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 > > The firmware change looks pretty lame to me...it was easy for me to > make my FW backwards compat > to the old way of just passing in the mhz and the freq1 160mhz > center-freq, so really I do not know why > the FW was changed. > > I am testing my FW fixes now... > > Thanks, > Ben >
this code here has been used
if (arg->mode == MODE_11AC_VHT160) {
if (arg->freq < arg->band_center_freq1)
ch->band_center_freq1 = __cpu_to_le32(arg->freq
+ 40);
else
ch->band_center_freq1 = __cpu_to_le32(arg->freq
- 40);
ch->band_center_freq2 =
__cpu_to_le32(arg->band_center_freq1);
}
Am 02.02.2017 um 21:50 schrieb Ben Greear:
> On 02/02/2017 12:45 PM, Sebastian Gottschall wrote:
>
>>>> + 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
>
> The firmware change looks pretty lame to me...it was easy for me to
> make my FW backwards compat
> to the old way of just passing in the mhz and the freq1 160mhz
> center-freq, so really I do not know why
> the FW was changed.
>
> I am testing my FW fixes now...
>
> Thanks,
> Ben
>
--- 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;