All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
To: Ben Greear <greearb@candelatech.com>,
	"Valo, Kalle" <kvalo@qca.qualcomm.com>
Cc: "ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: 9984 VHT
Date: Thu, 2 Feb 2017 21:28:33 +0100	[thread overview]
Message-ID: <dc16858f-11f4-3aa7-01b8-4165cd1aa087@dd-wrt.com> (raw)
In-Reply-To: <941cc332-782e-897b-ba77-4e6682836f68@candelatech.com>

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
>
>
>


-- 
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@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2017-02-02 20:28 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-29 23:11 QCA988X firmware pull-push support Sergey Ryazanov
     [not found] ` <CAJ-Vmo=yD7Ct5LFXBO3qNhKsNco91VXMmZOYeBaAuw+DFGq=RQ@mail.gmail.com>
2017-01-30  1:20   ` Sergey Ryazanov
2017-01-30  2:50     ` Adrian Chadd
2017-01-30  8:13       ` Valo, Kalle
2017-01-30 10:28         ` 9984 VHT Sebastian Gottschall
2017-02-01 16:48           ` Ben Greear
2017-02-01 18:45             ` Sebastian Gottschall
2017-02-02 16:18               ` Ben Greear
2017-02-02 18:24                 ` Ben Greear
2017-02-02 18:42                   ` Sebastian Gottschall
2017-02-02 19:05                     ` Ben Greear
2017-02-02 19:08                       ` Sebastian Gottschall
2017-02-02 19:18                         ` Ben Greear
2017-02-02 19:29                           ` Sebastian Gottschall
2017-02-02 19:32                             ` Ben Greear
2017-02-02 20:28                               ` Sebastian Gottschall [this message]
2017-02-02 20:37                                 ` Ben Greear
2017-02-02 20:45                                   ` Sebastian Gottschall
2017-02-02 20:50                                     ` Ben Greear
2017-02-02 21:01                                       ` Sebastian Gottschall
2017-02-02 21:04                                       ` Sebastian Gottschall
2017-02-07 12:14                       ` Valo, Kalle
2017-02-07 12:39                         ` Sebastian Gottschall
2017-02-10  6:50                           ` Valo, Kalle
     [not found]                             ` <c894f9ae-068a-eac3-16e6-c1ada4da22b9@dd-wrt.com>
2017-02-14 10:30                               ` Valo, Kalle
2017-02-14 15:21                                 ` Sebastian Gottschall
2017-02-16 16:20                                   ` Adrian Chadd
2017-02-16 16:34                                     ` Sebastian Gottschall
2017-02-17  5:42                                       ` Adrian Chadd
2017-02-20 15:40                                   ` Valo, Kalle
2017-02-01  8:21         ` QCA988X firmware pull-push support Sergey Ryazanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc16858f-11f4-3aa7-01b8-4165cd1aa087@dd-wrt.com \
    --to=s.gottschall@dd-wrt.com \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=kvalo@qca.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.