* Re: [RFC v2 05/11] ath10k: htc: refactorization
From: Valo, Kalle @ 2016-12-14 13:49 UTC (permalink / raw)
To: michal.kazior@tieto.com
Cc: Erik Stromdahl, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQmRV59imnmSykjs=ym0qut9akUHzFKfAMioK=MT8my98A@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
>> I have made a few updates since I submitted the original RFC and created
>> a repo on github:
>>
>> https://github.com/erstrom/linux-ath
>>
>> I have a bunch of branches that are all based on the tags on the ath mas=
ter.
>>
>> As of this moment the latest version is:
>>
>> ath-201612131156-ath10k-sdio
>>
>> This branch contains the original RFC patches plus some addons/fixes.
>>
>> In the above mentioned branch there are a few commits related to this
>> race condition. Perhaps you can have a look at them?
>>
>> The commits are:
>> 821672913328cf737c9616786dc28d2e4e8a4a90
>
> I would avoid if(bus=3D=3Dxx) checks.
Very much agreed. For example to enable HTT high latency support you
could add an enum to ath10k_core_create() with values for both high and
low latency. This way sdio.c and pci.c can enable the correct mode
during initialisation.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [RFC v2 05/11] ath10k: htc: refactorization
From: Valo, Kalle @ 2016-12-14 13:46 UTC (permalink / raw)
To: Erik Stromdahl
Cc: michal.kazior@tieto.com, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> I have made a few updates since I submitted the original RFC and created
> a repo on github:
>
> https://github.com/erstrom/linux-ath
>
> I have a bunch of branches that are all based on the tags on the ath mast=
er.
>
> As of this moment the latest version is:
>
> ath-201612131156-ath10k-sdio
>
> This branch contains the original RFC patches plus some addons/fixes.
Good, this makes it easier to follow the development. So what's the
current status with this branch? What works and what doesn't?
Especially I'm interested about the state of the HTT high latency
support. How much work is to add that? It would also make it easier to
add USB support to ath10k.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications
From: Arend Van Spriel @ 2016-12-14 10:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1481646049.20412.43.camel@sipsolutions.net>
On 13-12-2016 17:20, Johannes Berg wrote:
> On Mon, 2016-12-12 at 11:59 +0000, Arend van Spriel wrote:
>> The driver can indicate gscan results are available or gscan
>> operation has stopped.
>
> This patch is renumbering the previous patches' nl80211 API, which is
> best avoided, even if I do realize it doesn't matter now. :)
Indeed. Will be more careful in upcoming revision(s).
> Even here it's not clear how things are reported though. Somehow I
> thought that gscan was reporting only partial information through the
> buckets, or is that not true?
Not sure what is meant by "through the buckets". Referring to your
remark/question in the "Unversal scan proposal" thread:
"""
I'm much more worried about the "bucket reporting" since that doesn't
fit into the current full BSS reporting model at all. What's your
suggestion for this?
"""
So this is exactly the dilemma I considered so I decided to stick with
the full BSS reporting model for gscan as well merely to get it
discussed so glad you brought it up ;-). The problem here is that
gscan is a vehicle that serves a number of use-cases. So ignoring
hotlists, ePNO, etc. the gscan configuration still hold several
notification types:
- report after completing M scans capturing N best APs or a
percentage of (M * N).
- report after completing a scan include a specific bucket.
- report full scan results.
The first two notification trigger retrieval of gscan results which are
historic, ie. partial scan results for max M scans.
As said earlier the universal scan proposal has some similarities to
gscan. Guess you share that as you are using the term "bucket reporting"
in that discussion ;-). The historic results are needed for location (if
I am not mistaken) so the full BSS reporting model does not fit that.
Question is what particular attribute in the historic results is needed
for location (suspecting only rssi and possibly the timestamp, but would
like to see that confirmed). I was thinking about have historic storage
in cfg80211 so we do not need a per-driver solution.
Regards,
Arend
^ permalink raw reply
* Re: [RFC V3 03/11] nl80211: add support for gscan
From: Arend Van Spriel @ 2016-12-14 9:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1481668194.22319.0.camel@sipsolutions.net>
On 13-12-2016 23:29, Johannes Berg wrote:
> On Tue, 2016-12-13 at 21:09 +0100, Arend Van Spriel wrote:
>>
>>> There's a bit of a weird hard-coded restriction to 16 channels too,
>>> that's due to the bucket map?
>>
>> Uhm. Is there? I will check, but if you can give me a pointer where
>> to look it is appreciated.
>
> Just look for "< 16" or "<= 16" or so in the patch. I do think that's
> because the channel map is a u16 though, not sure we'd want to change
> that.
Had to look for "> 16" ;-)
> + /* ignore channels if band is specified */
> + if (band_select)
> + return 0;
> +
> + nla_for_each_nested(chan,
tb[NL80211_GSCAN_BUCKET_ATTR_CHANNELS], rem) {
> + num_chans++;
> + }
Here an instance of the tab vs. space issue you mentioned. Will go over
the patch and fix that.
> + if (num_chans > 16)
> + return -EINVAL;
I suspect this is the restriction you were referring to. There is no
reason for this although the android wifi hal has max 16 channels in a
bucket so I might have picked that up. So could a driver have a similar
limit and should we add such to the gscan capabilities? For instance our
firmware api has a nasty restriction of 64 channels for all buckets
together, eg. can do 4 buckets of 16 channels each.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics
From: Mohammed Shafi Shajakhan @ 2016-12-14 7:33 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <2870294.lMmxz9iPmq@debian64>
On Tue, Dec 13, 2016 at 01:41:33PM +0100, Christian Lamparter wrote:
> Hello,
>
> It looks like google put your mail into the spam-can.
> I'm sorry for not answering sooner.
[shafi] np, thanks for your reply !
>
> On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > The 10.4 firmware adds extended peer information to the
> > > firmware's statistics payload. This additional info is
> > > stored as a separate data field and the elements are
> > > stored in their own "peers_extd" list.
> > >
> > > These elements can pile up in the same way as the peer
> > > information elements. This is because the
> > > ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> > > pull the same amount (num_peer_stats) for every statistic
> > > data unit.
> > >
> > > Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > ---
> > > drivers/net/wireless/ath/ath10k/debug.c | 7 +++++--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > index 82a4c67f3672..4acd9eb65910 100644
> > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > @@ -399,6 +399,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > * prevent firmware from DoS-ing the host.
> > > */
> > > ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
> > > + ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
> >
> > [shafi] thanks for fixing this !
> >
> > > ath10k_warn(ar, "dropping fw peer stats\n");
> > > goto free;
> > > }
> > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > goto free;
> > > }
> > >
> > > + if (!list_empty(&stats.peers))
> >
> > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> > for normal 'peer stats' ? Is this the fix intended, i had started a build to
> > check your change and we will keep you posted, does this fix displaying
> > 'rx_duration' in ath10k fw_stats.
> The idea is not to queue any "extended peer stats" when there where no "peer stats" to
> begin with. Because otherwise, the function is still vulnerable to OOM since the
> extended peers stats will be queued unchecked (not that this is currently a problem).
[shafi] list_splice_tail_init should still check for non-empty 'peers_extd' list
and append if required ? please let me know if i am still missing something
>
> > > + list_splice_tail_init(&stats.peers_extd,
> > > + &ar->debug.fw_stats.peers_extd);
> > > +
> > > list_splice_tail_init(&stats.peers, &ar->debug.fw_stats.peers);
> > > list_splice_tail_init(&stats.vdevs, &ar->debug.fw_stats.vdevs);
> > > - list_splice_tail_init(&stats.peers_extd,
> > > - &ar->debug.fw_stats.peers_extd);
> > > }
> > >
> > > complete(&ar->debug.fw_stats_complete);
>
> Regards,
> Christian
>
>
^ permalink raw reply
* RE: ATH9 driver issues on ARM64
From: Bharat Kumar Gogada @ 2016-12-14 5:09 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tobias Klausmann, Kalle Valo, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, rmanohar@qti.qualcomm.com,
ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org
In-Reply-To: <20161212163114.GA32712@bhelgaas-glaptop.roam.corp.google.com>
> On Sat, Dec 10, 2016 at 02:40:48PM +0000, Bharat Kumar Gogada wrote:
> > Hi,
> >
> > After taking some more lecroy traces, we see that after 2nd ASSERT from=
EP
> on ARM64 we see continuous data movement of 32 dwords or 12 dwords and
> never sign of DEASSERT.
> > Comparatively on working traces (x86) after 2nd assert there are only B=
AR
> register reads and writes and then DEASSERT, for almost most of the inter=
rupts
> and we haven't seen 12 or 32 dwords data movement on this trace.
> >
> > I did not work on EP wifi/network drivers, any help why EP needs those =
many
> number of data at scan time ?
>=20
> The device doesn't know whether it's in an x86 or an arm64 system. If it=
works
> differently, it must be because the PCI core or the driver is programming=
the
> device differently.
>=20
> You should be able to match up Memory transactions from the host in the t=
race
> with things the driver does. For example, if you see an Assert_INTx mess=
age
> from the device, you should eventually see a Memory Read from the host to=
get
> the ISR, i.e., some read done in the bowels of ath9k_hw_getisr().
>=20
> I don't know how the ath9k device works, but there must be some Memory Re=
ad
> or Write done by the driver that tells the device "we've handled this int=
errupt".
> The device should then send a Deassert_INTx; of course, if the device sti=
ll
> requires service, e.g., because it has received more packets, it might le=
ave the
> INTx asserted.
>=20
> I doubt you'd see exactly the same traces on x86 and arm64 because they a=
ren't
> seeing the same network packets and the driver is executing at different =
rates.
> But you should at least be able to identify interrupt assertion and the a=
ctions of
> the driver's interrupt service routine.
Thanks Bjorn.
As you mentioned we did try to debug in that path. After we start scan afte=
r 2nd ASSERT we see lots of 32 and 12 dword
data, and in function
void ath9k_hw_enable_interrupts(struct ath_hw *ah)=20
{
...
..
REG_WRITE(ah, AR_IER, AR_IER_ENABLE);
// EP driver hangs at this position after 2nd ASSERT
// The following writes are not happening
if (!AR_SREV_9100(ah)) { =09
REG_WRITE(ah, AR_INTR_ASYNC_ENABLE, async_mask);
REG_WRITE(ah, AR_INTR_ASYNC_MASK, async_mask);
REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
REG_WRITE(ah, AR_INTR_SYNC_MASK, sync_default);
} =20
ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER));
}
The above funtion is invoked from tasklet.
I tried several boots every it stops here. The condition (!AR_SREV_9100(ah)=
) is true as per before 1st ASSERT handling.
Regards,
Bharat
>=20
> > > Hello there,
> > >
> > > as this is a thread about ath9k and ARM64, i'm not sure if i should
> > > answer here or not, but i have similar "stalls" with ath9k on x86_64
> > > (starting with 4.9rc), stack trace is posted down below where the ori=
ginal
> ARM64 stall traces are.
> > >
> > > Greetings,
> > >
> > > Tobias
> > >
> > >
> > > On 08.12.2016 18:36, Kalle Valo wrote:
> > > > Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> writes:
> > > >
> > > >> > [+cc Kalle, ath9k list]
> > > > Thanks, but please also CC linux-wireless. Full thread below for
> > > > the folks there.
> > > >
> > > >>> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada
> wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> Did anyone test Atheros ATH9
> > > >>>> driver(drivers/net/wireless/ath/ath9k/)
> > > >>>> on ARM64. The end point is TP link wifi card with which
> > > >>>> supports only legacy interrupts.
> > > >>> If it works on other arches and the arm64 PCI enumeration works,
> > > >>> my first guess would be an INTx issue, e.g., maybe the driver is
> > > >>> waiting for an interrupt that never arrives.
> > > >> We are not sure for now.
> > > >>>> We are trying to test it on ARM64 with
> > > >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> > > >>>>
> > > >>>> EP is getting enumerated and able to link up.
> > > >>>>
> > > >>>> But when we start scan system gets hanged.
> > > >>> When you say the system hangs when you start a scan, I assume
> > > >>> you mean a wifi scan, not the PCI enumeration. A problem with a
> > > >>> wifi scan might cause a *process* to hang, but it shouldn't hang
> > > >>> the entire system.
> > > >>>
> > > >> Yes wifi scan.
> > > >>>> When we took trace we see that after we start scan assert
> > > >>>> message is sent but there is no de assert from end point.
> > > >>> Are you talking about a trace from a PCIe analyzer? Do you see
> > > >>> an Assert_INTx PCIe message on the link?
> > > >>>
> > > >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx
> > > >> happening
> > > when we do interface link up.
> > > >> When we have less debug prints in Atheros driver, and do wifi
> > > >> scan we see Assert_INTx but never Deassert_INTx,
> > > >>>> What might cause end point not sending de assert ?
> > > >>> If the endpoint doesn't send a Deassert_INTx message, I expect
> > > >>> that would mean the driver didn't service the interrupt and
> > > >>> remove the condition that caused the device to assert the
> > > >>> interrupt in the first place.
> > > >>>
> > > >>> If the driver didn't receive the interrupt, it couldn't service
> > > >>> it, of course. You could add a printk in the ath9k interrupt
> > > >>> service routine to see if you ever get there.
> > > >>>
> > > >> The interrupt behavior is changing w.r.t amount of debug prints
> > > >> we add. (I kept many prints to aid debug)
> > > >> root@Xilinx-ZCU102-2016_3:~# iw dev
> > > wlan0 scan
> > > >> [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.074257] ath9k_hw_kill_interrupts 793
> > > >> [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.087882] ath9k_hw_kill_interrupts 793
> > > >> [ 83.095450] ath9k_hw_enable_interrupts 821
> > > >> [ 83.099557] ath9k_hw_enable_interrupts 825
> > > >> [ 83.103721] ath9k_hw_enable_interrupts 832
> > > >> [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.112748] AR_SREV_9100 0
> > > >> [ 83.115438] ath9k_hw_enable_interrupts 848
> > > >> [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.124389] ath9k_hw_intrpend 762
> > > >> [ 83.127761] (AR_SREV_9340(ah) val 0
> > > >> [ 83.131234] ath9k_hw_intrpend 767
> > > >> [ 83.134628] ath_isr 603
> > > >> [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.146771] ath9k_hw_kill_interrupts 793
> > > >> [ 83.150864] ath9k_hw_enable_interrupts 821
> > > >> [ 83.154971] ath9k_hw_enable_interrupts 825
> > > >> [ 83.159135] ath9k_hw_enable_interrupts 832
> > > >> [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.168161] AR_SREV_9100 0
> > > >> [ 83.170852] ath9k_hw_enable_interrupts 848
> > > >> [ 83.170855] ath9k_hw_intrpend 762
> > > >> [ 83.178398] (AR_SREV_9340(ah) val 0
> > > >> [ 83.181873] ath9k_hw_intrpend 767
> > > >> [ 83.185265] ath_isr 603
> > > >> [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.197411] ath9k_hw_kill_interrupts 793
> > > >> [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.206258] ath9k_hw_enable_interrupts 821
> > > >> [ 83.210368] ath9k_hw_enable_interrupts 825
> > > >> [ 83.214531] ath9k_hw_enable_interrupts 832
> > > >> [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.223558] AR_SREV_9100 0
> > > >> [ 83.226243] ath9k_hw_enable_interrupts 848
> > > >> [ 83.226246] ath9k_hw_intrpend 762
> > > >> [ 83.233794] (AR_SREV_9340(ah) val 0
> > > >> [ 83.237268] ath9k_hw_intrpend 767
> > > >> [ 83.240661] ath_isr 603
> > > >> [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.252806] ath9k_hw_kill_interrupts 793
> > > >> [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.261651] ath9k_hw_enable_interrupts 821
> > > >> [ 83.265753] ath9k_hw_enable_interrupts 825
> > > >> [ 83.269919] ath9k_hw_enable_interrupts 832
> > > >> [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.278945] AR_SREV_9100 0
> > > >> [ 83.281630] ath9k_hw_enable_interrupts 848
> > > >> [ 83.281633] ath9k_hw_intrpend 762
> > > >> [ 83.281634] (AR_SREV_9340(ah) val 0
> > > >> [ 83.281637] ath9k_hw_intrpend 767
> > > >> [ 83.281648] ath_isr 603
> > > >> [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.281654] ath9k_hw_kill_interrupts 793
> > > >> [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> > > >> [ 83.317030] ath9k_hw_enable_interrupts 821
> > > >> [ 83.321132] ath9k_hw_enable_interrupts 825
> > > >> [ 83.325297] ath9k_hw_enable_interrupts 832
> > > >> [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> > > >> [ 83.334324] AR_SREV_9100 0
> > > >> [ 83.337014] ath9k_hw_enable_interrupts 848
> > > >> ..
> > > >> ..
> > > >> This log continues until I turn off board without obtaining scanni=
ng result.
> > > >>
> > > >> In between I get following cpu stall outputs :
> > > >> 230.457179] INFO: rcu_sched self-detected stall on CPU
> > > >> [ 230.457185] 2-...: (31314 ticks this GP)
> > > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D36713
> > > >> [ 230.457189] (t=3D36756 jiffies g=3D161 c=3D160 q=3D16169)
> > > >> [ 230.457191] Task dump for CPU 2:
> > > >> [ 230.457196] kworker/u8:4 R running task 0 1342 =
2
> 0x00000002
> > > >> [ 230.457207] Workqueue: phy0 ieee80211_scan_work [ 230.457208]
> > > >> Call trace:
> > > >> [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198 [
> > > >> 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20 [
> > > >> 230.457224] [<ffffff80080c0930>] sched_show_task+0x98/0xf8 [
> > > >> 230.457228] [<ffffff80080c2628>] dump_cpu_task+0x40/0x50 [
> > > >> 230.457233] [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0 [
> > > >> 230.457239] [<ffffff80080e4cd8>] rcu_check_callbacks+0x468/0x748
> > > >> [ 230.457243] [<ffffff80080e7cfc>]
> > > >> update_process_times+0x3c/0x68 [ 230.457249]
> > > >> [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> > > >> [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90 [
> > > >> 230.457257] [<ffffff80080e86b0>] __hrtimer_run_queues+0xf0/0x178
> > > >> ** 10 printk messages dropped ** [ 230.457302] f8c0:
> > > >> 0000000000000000 0000000005f5e0ff 000000000001379a
> > > 3866666666666620 [
> > > >> 230.457306] f8e0: ffffff800a1b4065 0000000000000006
> > > >> ffffff800a129000
> > > >> ffffffc87b8010a8 [ 230.457310] f900: ffffff808a1b4057
> > > >> ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000 [ 230.457314]
> > > >> f920: 0000000000000140 0000000000000006 ffffff800a1b3b10
> > > >> ffffff800a1c39e8 [ 230.457318] f940: 000000000000002f
> > > >> ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990 [ 230.457322]
> > > >> f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234
> > > >> 0000000060000145
> > > >> ** 1 printk messages dropped ** [ 230.457329]
> > > >> [<ffffff8008085720>]
> > > >> el1_irq+0xa0/0x100
> > > >> ** 9 printk messages dropped ** [ 230.457373]
> > > >> [<ffffff800885ad60>]
> > > >> ieee80211_hw_config+0x50/0x290 [ 230.457377]
> > > >> [<ffffff8008863690>]
> > > >> ieee80211_scan_work+0x1f8/0x480 [ 230.457383]
> > > >> [<ffffff80080b15d0>]
> > > >> process_one_work+0x120/0x378 [ 230.457386] [<ffffff80080b1870>]
> > > >> worker_thread+0x48/0x4b0 [ 230.457391] [<ffffff80080b7108>]
> > > >> kthread+0xd0/0xe8 [ 230.457395] [<ffffff8008085dd0>]
> > > ret_from_fork+0x10/0x40
> > > >> [ 230.480389] ath9k_hw_intrpend 762
> > > >>
> > > >>
> > > >> [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024 [
> > > >> 545.526189]
> > > >> INFO: rcu_sched self-detected stall on CPU
> > > >> [ 545.526195] 2-...: (97636 ticks this GP)
> > > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D115374
> > > >> [ 545.526199] (t=3D115523 jiffies g=3D161 c=3D160 q=3D51066)
> > > >> [ 545.526201] Task dump for CPU 2:
> > > >> [ 545.526206] kworker/u8:4 R running task 0 1342 =
2
> 0x00000002
> > > >> ** 3 printk messages dropped ** [ 545.526231]
> > > >> [<ffffff8008089a0c>]
> > > >> show_stack+0x14/0x20
> > > >> ** 9 printk messages dropped ** [ 545.526280]
> > > >> [<ffffff80086a71e8>]
> > > >> arch_timer_handler_phys+0x30/0x40 [ 545.526284]
> > > >> [<ffffff80080dbe18>]
> > > >> handle_percpu_devid_irq+0x78/0xa0 [ 545.526291]
> > > >> [<ffffff80080d760c>]
> > > >> generic_handle_irq+0x24/0x38 [ 545.526296] [<ffffff80080d7944>]
> > > >> __handle_domain_irq+0x5c/0xb8 [ 545.526299] [<ffffff80080824bc>]
> > > >> gic_handle_irq+0x64/0xc0 [ 545.526302] Exception
> > > >> stack(0xffffffc87b07f870
> > > to 0xffffffc87b07f990)
> > > >> [ 545.526306] f860: 00000000000=
09732
> ffffff800a1eaaa8
> > > >> ** 8 printk messages dropped ** [ 545.526341] f980:
> > > >> ffffff800a1c39e8
> > > >> 0000000000000036 [ 545.526345] [<ffffff8008085720>]
> > > >> el1_irq+0xa0/0x100 [ 545.526349] [<ffffff80080d6234>]
> > > >> console_unlock+0x384/0x5b0 [ 545.526353] [<ffffff80080d673c>]
> > > >> vprintk_emit+0x2dc/0x4b0 [ 545.526357] [<ffffff80080d6a50>]
> > > >> vprintk_default+0x38/0x40 [ 545.526362] [<ffffff8008129704>]
> > > >> printk+0x58/0x60 [ 545.526366] [<ffffff800859e3e4>]
> > > >> ath9k_iowrite32+0x9c/0xa8 [ 545.526372] [<ffffff80085c7ca8>]
> > > >> ath9k_hw_kill_interrupts+0x28/0xf0
> > > >> [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> > > >> ** 2 printk messages dropped ** [ 545.526391]
> > > >> [<ffffff800885ad60>]
> > > ieee80211_hw_config+0x50/0x290
> > > >> ** 11 printk messages dropped ** [ 545.532834]
> > > >> ath9k_hw_kill_interrupts
> > > 793
> > > >> [ 545.532890] ath9k_hw_enable_interrupts 821
> > >
> > > [ 81.876902] INFO: rcu_preempt detected stalls on CPUs/tasks:
> > > [ 81.876912] Tasks blocked on level-0 rcu_node (CPUs 0-7): P0
> > > [ 81.876932] (detected by 4, t=3D60002 jiffies, g=3D1873, c=3D1=
872, q=3D4967)
> > > [ 81.876936] swapper/4 R running task 0 0 1
> > > 0x00000000
> > > [ 81.876941] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> > > ffffffff81a3dc40
> > > [ 81.876945] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> > > ffffffff81a3dc40
> > > [ 81.876948] 00000000ffffffff ffffffff810a7333 ffff88017ecee698
> > > ffff88017edbc240
> > > [ 81.876951] Call Trace:
> > > [ 81.876970] <IRQ>
> > > [ 81.876979] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> > > [ 81.876983] [<ffffffff81101e46>] ?
> > > rcu_print_detail_task_stall_rnp+0x40/0x61
> > > [ 81.876989] [<ffffffff810a7333>] ? rcu_check_callbacks+0x6b3/0x8c=
0
> > > [ 81.876993] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40=
/0x40
> > > [ 81.876996] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
> > > [ 81.876999] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> > > [ 81.877002] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x15=
0
> > > [ 81.877004] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> > > [ 81.877008] [<ffffffff81031b1e>] ?
> > > smp_trace_apic_timer_interrupt+0x5e/0x90
> > > [ 81.877012] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
> > > [ 81.877013] <EOI>
> > > [ 81.877017] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f=
0
> > > [ 81.877019] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f=
0
> > > [ 81.877021] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
> > > [ 81.877027] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> > > [ 81.877029] swapper/4 R running task 0 0 1
> > > 0x00000000
> > > [ 81.877032] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> > > ffffffff81a3dc40
> > > [ 81.877035] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> > > ffffffff81a3dc40
> > > [ 81.877038] 00000000ffffffff ffffffff810a7368 ffff88017ecee698
> > > ffff88017edbc240
> > > [ 81.877041] Call Trace:
> > > [ 81.877045] <IRQ>
> > > [ 81.877049] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> > > [ 81.877051] [<ffffffff81101e46>] ?
> > > rcu_print_detail_task_stall_rnp+0x40/0x61
> > > [ 81.877055] [<ffffffff810a7368>] ? rcu_check_callbacks+0x6e8/0x8c=
0
> > > [ 81.877058] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40=
/0x40
> > > [ 81.877060] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
> > > [ 81.877063] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> > > [ 81.877065] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x15=
0
> > > [ 81.877068] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> > > [ 81.877070] [<ffffffff81031b1e>] ?
> > > smp_trace_apic_timer_interrupt+0x5e/0x90
> > > [ 81.877073] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
> > > [ 81.877074] <EOI>
> > > [ 81.877076] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f=
0
> > > [ 81.877078] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f=
0
> > > [ 81.877080] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
> > > [ 81.877084] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> > > [ 91.132787] INFO: rcu_preempt detected expedited stalls on
> > > CPUs/tasks: { P0 } 63785 jiffies s: 505 root: 0x0/T
> > > [ 91.132796] blocking rcu_node structures:
> > >
> > > >>
> > > >>
> > > >> But if we have less debug prints it does not reach EP handler
> > > >> sometimes, due to following Condition in "kernel/irq/chip.c" in
> > > >> function handle_simple_irq
> > > >>
> > > >> if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data)))=
{
> > > >> desc->istate |=3D IRQS_PENDING;
> > > >> goto out_unlock;
> > > >> }
> > > >> Here irqd_irq_disabled is being set to 1.
> > > >>
> > > >> With lesser debug prints it stops after following prints:
> > > >> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> > > >> [ 54.781045] ath9k_hw_kill_interrupts 793
> > > >> [ 54.785007] ath9k_hw_kill_interrupts 793
> > > >> [ 54.792535] ath9k_hw_enable_interrupts 821
> > > >> [ 54.796642] ath9k_hw_enable_interrupts 825
> > > >> [ 54.800807] ath9k_hw_enable_interrupts 832
> > > >> [ 54.804973] AR_SREV_9100 0
> > > >> [ 54.807663] ath9k_hw_enable_interrupts 848
> > > >> [ 54.811843] ath9k_hw_intrpend 762
> > > >> [ 54.815211] (AR_SREV_9340(ah) val 0
> > > >> [ 54.818684] ath9k_hw_intrpend 767
> > > >> [ 54.822078] ath_isr 603
> > > >> [ 54.824587] ath9k_hw_kill_interrupts 793
> > > >> [ 54.828601] ath9k_hw_enable_interrupts 821
> > > >> [ 54.832750] ath9k_hw_enable_interrupts 825
> > > >> [ 54.836916] ath9k_hw_enable_interrupts 832
> > > >> [ 54.841082] AR_SREV_9100 0
> > > >> [ 54.843772] ath9k_hw_enable_interrupts 848
> > > >> [ 54.843775] ath9k_hw_intrpend 762
> > > >> [ 54.851319] (AR_SREV_9340(ah) val 0
> > > >> [ 54.854793] ath9k_hw_intrpend 767
> > > >> [ 54.858185] ath_isr 603
> > > >> [ 54.860696] ath9k_hw_kill_interrupts 793
> > > >> [ 54.864776] ath9k_hw_enable_interrupts 821
> > > >> [ 54.867061] ath9k_hw_kill_interrupts 793
> > > >> [ 54.872870] ath9k_hw_enable_interrupts 825
> > > >> [ 54.877036] ath9k_hw_enable_interrupts 832
> > > >> [ 54.881202] AR_SREV_9100 0
> > > >> [ 54.883892] ath9k_hw_enable_interrupts 848
> > > >> [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > >> [ 75.968602] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> > > softirq=3D1103/1109 fqs=3D519
> > > >> [ 75.976675] (detected by 2, t=3D5274 jiffies, g=3D64, c=3D63, =
q=3D11)
> > > >> [ 75.982485] Task dump for CPU 0:
> > > >> [ 75.985696] ksoftirqd/0 R running task 0 3 =
2 0x00000002
> > > >> [ 75.992726] Call trace:
> > > >> [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> > > >> [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> > > >> [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > >> [ 139.064430] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> > > softirq=3D1103/1109 fqs=3D2097
> > > >> [ 139.072593] (detected by 2, t=3D21049 jiffies, g=3D64, c=3D63,=
q=3D11)
> > > >> [ 139.078489] Task dump for CPU 0:
> > > >> [ 139.081700] ksoftirqd/0 R running task 0 3 =
2 0x00000002
> > > >> [ 139.088731] Call trace:
> > > >> [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0 [
> > > >> 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
> > > >>
> > > >>
> > > >>>> We are not seeing any issues on 32-bit ARM platform and X86
> > > >>>> platform.
> > > >>> Can you collect a dmesg log (or, if the system hang means you
> > > >>> can't collect that, a console log with "ignore_loglevel"), and "l=
spci -vv"
> > > >>> output as root? That should have clues about whether the INTx
> > > >>> got routed correctly. /proc/interrupts should also show whether
> > > >>> we're receiving interrupts from the device.
> > > >> Here is the lspci output:
> > > >> 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00
> > > >> [Normal
> > > decode])
> > > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > >> Latency: 0
> > > >> Interrupt: pin A routed to IRQ 224
> > > >> Bus: primary=3D00, secondary=3D01, subordinate=3D0c, sec-latency=
=3D0
> > > >> I/O behind bridge: 00000000-00000fff
> > > >> Memory behind bridge: e0000000-e00fffff
> > > >> Prefetchable memory behind bridge: 00000000fff00000-
> > > 00000000000fffff
> > > >> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > > <TAbort- <MAbort- <SERR- <PERR-
> > > >> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> > > >> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> > > >> Capabilities: [40] Power Management version 3
> > > >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA
> > > PME(D0+,D1+,D2+,D3hot+,D3cold-)
> > > >> Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
> > > >> Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> > > >> DevCap: MaxPayload 256 bytes, PhantFunc 0
> > > >> ExtTag- RBE+
> > > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > > Unsupported-
> > > >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> > > >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> > > TransPend+
> > > >> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not supported,
> > > Exit Latency L0s unlimited, L1 unlimited
> > > >> ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
> > > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > > >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > > >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > > DLActive- BWMgmt- ABWMgmt-
> > > >> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
> > > CRSVisible+
> > > >> RootCap: CRSVisible+
> > > >> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> > > >> DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-,
> > > OBFF Not Supported ARIFwd-
> > > >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> > > OBFF Disabled ARIFwd-
> > > >> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> > > >> Transmit Margin: Normal Operating Range,
> > > EnterModifiedCompliance- ComplianceSOS-
> > > >> Compliance De-emphasis: -6dB
> > > >> LnkSta2: Current De-emphasis Level: -3.5dB,
> > > EqualizationComplete-, EqualizationPhase1-
> > > >> EqualizationPhase2-, EqualizationPhase3-,
> > > LinkEqualizationRequest-
> > > >> Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-=
00
> > > >> Capabilities: [10c v1] Virtual Channel
> > > >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> > > >> Ctrl: ArbSelect=3DFixed
> > > >> Status: InProgress-
> > > >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> > > >> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> > > WRR256-
> > > >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > >> Status: NegoPending- InProgress-
> > > >> Capabilities: [128 v1] Vendor Specific Information: ID=3D1234
> > > >> Rev=3D1
> > > >> Len=3D018 <?>
> > > >>
> > > >> 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless
> > > >> Network
> > > Adapter (rev 01)
> > > >> Subsystem: Qualcomm Atheros Device 3112
> > > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > >> Latency: 0, Cache Line Size: 128 bytes
> > > >> Interrupt: pin A routed to IRQ 224
> > > >> Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=3D1=
28K]
> > > >> [virtual] Expansion ROM at e0020000 [disabled] [size=3D64K]
> > > >> Capabilities: [40] Power Management version 3
> > > >> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA
> > > PME(D0+,D1+,D2-,D3hot+,D3cold-)
> > > >> Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
> > > >> Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> > > >> Address: 0000000000000000 Data: 0000
> > > >> Masking: 00000000 Pending: 00000000
> > > >> Capabilities: [70] Express (v2) Endpoint, MSI 00
> > > >> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency
> > > L0s <1us, L1 <8us
> > > >> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> > > SlotPowerLimit 0.000W
> > > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > > Unsupported-
> > > >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> > > >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> > > TransPend-
> > > >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
> > > Latency L0s <2us, L1 <64us
> > > >> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> > > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > > >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > > >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > > DLActive- BWMgmt- ABWMgmt-
> > > >> DevCap2: Completion Timeout: Not Supported, TimeoutDis+,
> > > LTR-, OBFF Not Supported
> > > >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> > > OBFF Disabled
> > > >> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> > > SpeedDis-
> > > >> Transmit Margin: Normal Operating Range,
> > > EnterModifiedCompliance- ComplianceSOS-
> > > >> Compliance De-emphasis: -6dB
> > > >> LnkSta2: Current De-emphasis Level: -6dB,
> > > EqualizationComplete-, EqualizationPhase1-
> > > >> EqualizationPhase2-, EqualizationPhase3-,
> > > LinkEqualizationRequest-
> > > >> Capabilities: [100 v1] Advanced Error Reporting
> > > >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> > > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> > > >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > > NonFatalErr-
> > > >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > > NonFatalErr+
> > > >> AERCap: First Error Pointer: 00, GenCap- CGenEn-
> > > ChkCap- ChkEn-
> > > >> Capabilities: [140 v1] Virtual Channel
> > > >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> > > >> Ctrl: ArbSelect=3DFixed
> > > >> Status: InProgress-
> > > >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> > > >> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> > > WRR256-
> > > >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > >> Status: NegoPending- InProgress-
> > > >> Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-=
00
> > > >> Kernel driver in use: ath9k
> > > >>
> > > >> Here is the cat /proc/interrupts (after we do interface up):
> > > >>
> > > >> root@:~# ifconfig wlan0 up
> > > >> [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not
> > > >> ready root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> > > >> CPU0 CPU1 CPU2 CPU3
> > > >> 1: 0 0 0 0 GICv2 29 Ed=
ge arch_timer
> > > >> 2: 19873 20058 19089 17435 GICv2 30 Ed=
ge arch_timer
> > > >> 12: 0 0 0 0 GICv2 156 Le=
vel zynqmp-dma
> > > >> 13: 0 0 0 0 GICv2 157 Le=
vel zynqmp-dma
> > > >> 14: 0 0 0 0 GICv2 158 Le=
vel zynqmp-dma
> > > >> 15: 0 0 0 0 GICv2 159 Le=
vel zynqmp-dma
> > > >> 16: 0 0 0 0 GICv2 160 Le=
vel zynqmp-dma
> > > >> 17: 0 0 0 0 GICv2 161 Le=
vel zynqmp-dma
> > > >> 18: 0 0 0 0 GICv2 162 Le=
vel zynqmp-dma
> > > >> 19: 0 0 0 0 GICv2 163 Le=
vel zynqmp-dma
> > > >> 20: 0 0 0 0 GICv2 164 Le=
vel Mali_GP_MMU,
> > > Mali_GP, Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> > > >> 30: 0 0 0 0 GICv2 95 Le=
vel eth0, eth0
> > > >> 206: 314 0 0 0 GICv2 49 Lev=
el cdns-i2c
> > > >> 207: 40 0 0 0 GICv2 50 Lev=
el cdns-i2c
> > > >> 209: 0 0 0 0 GICv2 150 Lev=
el nwl_pcie:misc
> > > >> 214: 12 0 0 0 GICv2 47 Lev=
el ff0f0000.spi
> > > >> 215: 0 0 0 0 GICv2 58 Lev=
el ffa60000.rtc
> > > >> 216: 0 0 0 0 GICv2 59 Lev=
el ffa60000.rtc
> > > >> 217: 0 0 0 0 GICv2 165 Lev=
el ahci-
> > > ceva[fd0c0000.ahci]
> > > >> 218: 61 0 0 0 GICv2 81 Lev=
el mmc0
> > > >> 219: 0 0 0 0 GICv2 187 Lev=
el arm-smmu global
> fault
> > > >> 220: 471 0 0 0 GICv2 53 Lev=
el xuartps
> > > >> 223: 0 0 0 0 GICv2 154 Lev=
el fd4c0000.dma
> > > >> 224: 3 0 0 0 dummy 1 Edg=
e ath9k
> > > >> 225: 0 0 0 0 GICv2 97 Lev=
el xhci-hcd:usb1
> > > >>
> > > >> Regards,
> > > >> Bharat
> >
^ permalink raw reply
* Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements
From: Adrian Chadd @ 2016-12-14 6:45 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Valo, Kalle, ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, devicetree@vger.kernel.org,
arnd@arndb.de, chunkeey@googlemail.com, nbd@nbd.name
In-Reply-To: <CAFBinCC6JWBhZwma=66fBi3_to2SaHOMNDQS23jHNhcc+RUcYQ@mail.gmail.com>
hi,
On 12 December 2016 at 12:05, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> It seems that there are a few devices out there where the whole EEPROM
> is swab16'ed which switches the position of the 1-byte fields
> opCapFlags and eepMisc.
> those still work fine with the new code, however I had a second patch
> in LEDE [0] which results in ath9k_platform_data.endian_check NOT
> being set anymore.
> that endian_check flag was used before to swab16 the whole EEPROM, to
> correct the position of the 1-byte fields again.
> Currently we are fixing this in the firmware hotplug script: [1]
> This is definitely not a blocker for this series though (if we want to
> have a devicetree replacement for "ath9k_platform_data.endian_check"
> then I'd work on that within a separate series, but I somewhat
> consider these EEPROMs as "broken" so fixing them in
> userspace/firmware hotplug script is fine for me)
As a reference - the reference driver has been doign this for a while.
It attempts to detect the endianness by looking at the 0xa55a
signature endian and figuring out which endian the actual contents are
in.
So just FYI yeah, this is a "thing" for reasons I don't quite know.
-adrian
>
>
> Regards,
> Martin
>
>
> [0] https://git.lede-project.org/?p=source.git;a=commitdiff;h=a20616863d32d91163043b6657a63c836bd9c5ba
> [1] https://git.lede-project.org/?p=source.git;a=commitdiff;h=afa37092663d00aa0abf8c61943d9a1b5558b144
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Adrian Chadd @ 2016-12-14 6:17 UTC (permalink / raw)
To: Alexis Green
Cc: Manoharan, Rajkumar, Benjamin Morgan, Nagarajan, Ashok Raj,
Mohammed Shafi Shajakhan, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAAnMG+MY=LhfJxxUVdfRNYUW-2R+EXdLm2o6yDcCH0T1brRVxw@mail.gmail.com>
Hi!
ok, thanks! I've seen some .. annoying rate control related firmware
crashes if you aren't using 11ac / 11n rates (ie you're /really/
legacy, so I wondered if something similar is going on here.
Thanks!
-a
On 13 December 2016 at 22:06, Alexis Green <agreen@cococorp.com> wrote:
> Hi Adrian,
>
> I have not done much testing of ath10k and ath9k devices in a single
> encrypted mesh recently, but I have a memory of only having this issue
> when communicating between ath10k devices.
>
> Alexis
>
> On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>> Hi!
>>
>> Hm! So is there a firmware bug if there are 11n only capable nodes in
>> an 11s mesh?
>>
>>
>>
>> -adrian
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Adrian Chadd @ 2016-12-14 5:53 UTC (permalink / raw)
To: Alexis Green
Cc: Manoharan, Rajkumar, Benjamin Morgan, Nagarajan, Ashok Raj,
Mohammed Shafi Shajakhan, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAAnMG+OmeataRKYRjOjtBXF_1-De-F4zWbUsWoYRhVu02NPrrw@mail.gmail.com>
Hi!
Hm! So is there a firmware bug if there are 11n only capable nodes in
an 11s mesh?
-adrian
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Alexis Green @ 2016-12-14 6:06 UTC (permalink / raw)
To: Adrian Chadd
Cc: Manoharan, Rajkumar, Benjamin Morgan, Nagarajan, Ashok Raj,
Mohammed Shafi Shajakhan, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAJ-Vmo=iLryhOS--PPYCGa9pE2GovPDOXi6xoH22xFOYXXKNVA@mail.gmail.com>
Hi Adrian,
I have not done much testing of ath10k and ath9k devices in a single
encrypted mesh recently, but I have a memory of only having this issue
when communicating between ath10k devices.
Alexis
On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi!
>
> Hm! So is there a firmware bug if there are 11n only capable nodes in
> an 11s mesh?
>
>
>
> -adrian
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Alexis Green @ 2016-12-14 5:36 UTC (permalink / raw)
To: Manoharan, Rajkumar
Cc: Benjamin Morgan, Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan,
lede-dev@lists.infradead.org, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <ccf17009a52748c99accdaa005ea837a@NALASEXR01H.na.qualcomm.com>
Thank you for your help Rajkumar,
We've traced the problem down to a peering issue. Looks like there was
a missing compile flag that caused some kind of incongruence. My best
guest is that beacons are generated by firmware and advertise support
for AC mode, whereas wpa_supplicant, when not compiled with
CONFIG_IEEE80211AC=y, sends mesh peering messages and creates peers
without AC support, causing firmware to get confused. After
recompiling supplicant with the correct flag, no more crashes were
observed in casual testing. I submitted a pull request to LEDE to,
hopefully, fix it in upstream.
Best regards,
Alexis
On Tue, Dec 13, 2016 at 3:51 PM, Manoharan, Rajkumar
<rmanohar@qca.qualcomm.com> wrote:
>> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
>> encryption and it still crashes. I suspect this means wpa_supplicant is setting up
>> the interface incorrectly and/or transmitting a malformed packet that is causing
>> the driver to crash.
>>
> Ben,
>
> IIRC mesh support was validated in qca988x in VHT mode while ago. Either it could
> be regression in driver/fw or lede mac80211 package.
>
> 1) Could you please try plain backports in lede w/o applying ath10k patches.
> I do see 160MHz support in LEDE.
> 2) There are some peer stats dump from your earlier log. Disable peer stats
> by "peer_stats" debugfs.
> 3) Please confirm the behavior with older firmware revisions.
> 4) use iw to bring up open mesh to rule out wpa_s config
>
> -Rajkumar
>
^ permalink raw reply
* RE: ath10k firmware crashes in mesh mode on QCA9880
From: Manoharan, Rajkumar @ 2016-12-13 23:51 UTC (permalink / raw)
To: Benjamin Morgan, Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan
Cc: agreen@cococorp.com, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <5850831D.7020206@cococorp.com>
PiBUZXN0ZWQgdGhlIDEwLjIuNC43MC41OS0yIGZpcm13YXJlIGFuZCB3cGFfc3VwcGxpY2FudCBy
dW5uaW5nIFdJVEhPVVQNCj4gZW5jcnlwdGlvbiBhbmQgaXQgc3RpbGwgY3Jhc2hlcy4gSSBzdXNw
ZWN0IHRoaXMgbWVhbnMgd3BhX3N1cHBsaWNhbnQgaXMgc2V0dGluZyB1cA0KPiB0aGUgaW50ZXJm
YWNlIGluY29ycmVjdGx5IGFuZC9vciB0cmFuc21pdHRpbmcgYSBtYWxmb3JtZWQgcGFja2V0IHRo
YXQgaXMgY2F1c2luZw0KPiB0aGUgZHJpdmVyIHRvIGNyYXNoLg0KPiANCkJlbiwNCg0KSUlSQyBt
ZXNoIHN1cHBvcnQgd2FzIHZhbGlkYXRlZCBpbiBxY2E5ODh4IGluIFZIVCBtb2RlIHdoaWxlIGFn
by4gIEVpdGhlciBpdCBjb3VsZA0KYmUgcmVncmVzc2lvbiBpbiBkcml2ZXIvZncgb3IgbGVkZSBt
YWM4MDIxMSBwYWNrYWdlLg0KDQoxKSBDb3VsZCB5b3UgcGxlYXNlIHRyeSBwbGFpbiBiYWNrcG9y
dHMgaW4gbGVkZSB3L28gYXBwbHlpbmcgYXRoMTBrIHBhdGNoZXMuDQogICAgIEkgZG8gc2VlIDE2
ME1IeiBzdXBwb3J0IGluIExFREUuDQoyKSBUaGVyZSBhcmUgc29tZSBwZWVyIHN0YXRzIGR1bXAg
ZnJvbSB5b3VyIGVhcmxpZXIgbG9nLiBEaXNhYmxlIHBlZXIgc3RhdHMgDQogICAgIGJ5ICJwZWVy
X3N0YXRzIiBkZWJ1Z2ZzLg0KMykgUGxlYXNlIGNvbmZpcm0gdGhlIGJlaGF2aW9yIHdpdGggb2xk
ZXIgZmlybXdhcmUgcmV2aXNpb25zLg0KNCkgdXNlIGl3IHRvIGJyaW5nIHVwIG9wZW4gbWVzaCB0
byBydWxlIG91dCB3cGFfcyBjb25maWcNCg0KLVJhamt1bWFyDQoNCg==
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Benjamin Morgan @ 2016-12-13 23:24 UTC (permalink / raw)
To: Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan
Cc: agreen@cococorp.com, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <58504113.2080702@cococorp.com>
Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
encryption and it still crashes. I suspect this means wpa_supplicant is
setting up the interface incorrectly and/or transmitting a malformed
packet that is causing the driver to crash.
[ 162.010206] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
d30144f6-a8fb-4c0d-bcdf-6ff3b2c37243)
[ 162.019322] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c
chip_id 0x043202ff sub 0000:0000
[ 162.028687] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 1
[ 162.041764] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2 api
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[ 162.053908] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[ 162.061332] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal file max-sta 128 raw 0 hwcrypto 1
[ 162.072975] ath10k_pci 0000:01:00.0: firmware register dump:
[ 162.078732] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
0x009A45AF 0x00955B31
[ 162.086771] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
0x00000001 0x40000000
[ 162.094804] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
0x00407120 0x004436CC
[ 162.102849] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
0x009A3550 0x009A355E
[ 162.110892] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
0x00000000 0x00000000
[ 162.118935] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
0x0040AC60 0x0040AC09
[ 162.126978] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
0x00000000 0xC09A45AF
[ 162.135011] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
0x0044110C 0x00442074
[ 162.143056] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
0x0044110C 0x00407120
[ 162.151099] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
0x0040AC10 0x00001580
[ 162.159142] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
0x009C6458 0x004436CC
[ 162.167185] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
0x004208FC 0x00439E4C
[ 162.175225] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
0x004208FC 0x004265C4
[ 162.183253] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
0x00424FE8 0x00000002
[ 162.191298] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
0x00000004 0x004039D0
[ 162.297229] ieee80211 phy0: Hardware restart was requested
[ 162.302880] ath10k_pci 0000:01:00.0: wmi disable pktlog
~Benjamin
On 12/13/2016 10:42 AM, Benjamin Morgan wrote:
> Just tested the latest 10.2.4.70.59-2 firmware and it still crashes
> with wpa_supplicant encrypted mesh =(
>
> [ 85.201440] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> b7f44483-0488-46af-8dff-db88f4b56327)
> [ 85.210573] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 85.219940] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 85.233034] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2
> api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
> [ 85.245177] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 85.252592] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal file max-sta 128 raw 0 hwcrypto 1
> [ 85.264235] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 85.269992] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A45AF 0x00955B31
> [ 85.278031] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
> 0x00000002 0x00439E98
> [ 85.286078] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [ 85.294107] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A3550 0x009A355E
> [ 85.302152] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [ 85.310195] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [ 85.318239] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
> 0x00400000 0xC09A45AF
> [ 85.326282] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
> 0x0044110C 0x00442074
> [ 85.334314] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
> 0x0044110C 0x00407120
> [ 85.342350] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
> 0x0040AC14 0x00001580
> [ 85.350393] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
> 0x009C6458 0x004436CC
> [ 85.358437] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
> 0x004208FC 0x00439E4C
> [ 85.366479] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
> 0x004208FC 0x00425AAC
> [ 85.374512] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
> 0x00424FE8 0x00000002
> [ 85.382548] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [ 85.487067] ieee80211 phy0: Hardware restart was requested
> [ 85.492701] ath10k_pci 0000:01:00.0: wmi disable pktlog
>
> Any new leads on tracking down this issue?
>
> ~Benjamin
>
>
> On 12/06/2016 01:32 PM, Benjamin Morgan wrote:
>> 1. Yes, this appears to happens every time a unicast packet with
>> wpa_supplicant encryption in VHT80 mode is received. I haven't seen a
>> successful ping-pong pair.
>> 2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
>> 3. We ran our experiment again with extra debugging turned on.
>> Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
>> Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
>> The ping command we used was run on Node A was 'ping -s 1500 -i
>> 0.1 10.230.5.42'
>> Here is the dmesg log from Node B.
>>
>> [ 5413.478170] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5413.503954] ath10k_pci 0000:01:00.0: scan event bss channel type 4
>> reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running
>> (2)
>> [ 5413.503985] ath10k_pci 0000:01:00.0: chan info err_code 0 freq
>> 5825 cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count
>> 312271423
>> [ 5413.504029] ath10k_pci 0000:01:00.0: scan event completed type 2
>> reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running
>> (2)
>> [ 5413.525868] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
>> cipher 4 len 16
>> [ 5413.526014] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
>> value 1
>> [ 5413.526193] ath10k_pci 0000:01:00.0: mac vdev 0 set keyidx 1
>> [ 5413.526216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
>> value 1
>> [ 5413.526532] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180
>> width 3 ptr 86db29b0
>> [ 5413.526556] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
>> needed? 0 allowed? 1
>> [ 5413.526574] ath10k_pci 0000:01:00.0: mac chanctx assign ptr
>> 86db29b0 vdev_id 0
>> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
>> 5180 phymode 11ac-vht80
>> [ 5413.526616] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 5413.533099] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 5413.533148] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
>> [ 5413.533163] ath10k_pci 0000:01:00.0: mac txpower 23
>> [ 5413.533180] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
>> [ 5413.533247] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
>> [ 5413.533295] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
>> width 3 ptr 86db29b0 changed 10
>> [ 5413.533318] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
>> width 3 ptr 86db29b0 changed 2
>> [ 5413.533337] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
>> needed? 1 allowed? 1
>> [ 5413.533357] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
>> subtype 0 macaddr 18:a6:f7:26:0f:21
>> [ 5413.533412] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
>> [ 5413.533463] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 5413.937652] ath10k_pci 0000:01:00.0: wmi event debug mesg len 152
>> [ 5413.978273] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5414.478363] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5414.527015] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 5414.527067] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc
>> id 0 bssid 18:a6:f7:26:0f:21
>> [ 5414.527121] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
>> [ 5414.527165] ath10k_pci 0000:01:00.0: mac monitor started
>> [ 5414.527216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
>> value 1000
>> [ 5414.527262] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
>> [ 5414.527278] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 5414.527294] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5414.527314] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5414.527330] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 5414.527457] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc
>> id 0 bssid 00:00:00:00:00:00
>> [ 5414.527501] ath10k_pci 0000:01:00.0: mac vdev 0 up
>> [ 5414.527564] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
>> [ 5414.541090] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
>> needed? 1 allowed? 1
>> [ 5414.978454] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5415.478548] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5415.978649] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5416.445280] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
>> needed? 1 allowed? 1
>> [ 5416.478761] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5416.978879] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5417.478985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5417.979081] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5418.479190] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5418.979301] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5419.479403] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5419.979551] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5420.479643] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5420.979746] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5421.479841] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5421.979940] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5422.480288] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5422.980386] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5423.480490] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5423.980600] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5424.480702] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5424.971969] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
>> 18:a6:f7:23:6e:66 (new sta) sta 1 / 128 peer 2 / 144
>> [ 5424.972000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
>> peer_addr 18:a6:f7:23:6e:66
>> [ 5424.975107] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 5424.975134] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5424.975219] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5424.975238] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 5424.980787] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.204468] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:23:6e:66
>> associated
>> [ 5425.204531] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:23:6e:66
>> mcs cnt 24 nss 3
>> [ 5425.204548] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 qos 1
>> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
>> phymode 11na-ht40
>> [ 5425.204585] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
>> 18:a6:f7:23:6e:66 (new)
>> [ 5425.204614] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
>> 0x18:a6:f7:23:6e:66 set param 1 value 0
>> [ 5425.205376] ath10k_pci 0000:01:00.0: received event id 36891 not
>> implemented
>> [ 5425.209240] ath10k_pci 0000:01:00.0: wmi vdev install key idx 0
>> cipher 4 len 16
>> [ 5425.209655] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
>> cipher 4 len 16
>> [ 5425.209848] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
>> value 1
>> [ 5425.210196] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 5425.210221] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 5425.210296] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 5425.210315] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 5425.480863] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.938619] ath10k_pci 0000:01:00.0: wmi event debug mesg len 100
>> [ 5425.980946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5425.995007] ath10k_pci 0000:01:00.0: mac sta rc update for
>> 18:a6:f7:23:6e:66 changed 00000001 bw 2 nss 3 smps 1
>> [ 5425.995060] ath10k_pci 0000:01:00.0: mac update sta
>> 18:a6:f7:23:6e:66 peer bw 2
>> [ 5425.995081] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
>> 0x18:a6:f7:23:6e:66 set param 4 value 2
>> [ 5426.481030] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5426.981117] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5427.481206] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5427.981294] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5428.481628] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5428.981718] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5429.481812] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5429.981894] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5430.481985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5430.982073] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5431.482174] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5431.982505] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5432.482597] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5432.982679] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5433.482765] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5433.982857] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5434.482946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5434.983008] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5435.483100] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5435.983181] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5436.483276] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5436.983366] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5437.483445] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5437.983516] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5438.483607] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5438.983692] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 5439.439875] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
>> db76b67c-ca98-4519-a762-4ff4edb45526)
>> [ 5439.449007] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
>> 0x4100016c chip_id 0x043202ff sub 0000:0000
>> [ 5439.458378] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
>> tracing 0 dfs 1 testmode 1
>> [ 5439.471460] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
>> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
>> [ 5439.481844] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
>> crc32 bebc7c08
>> [ 5439.489267] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
>> cal file max-sta 128 raw 0 hwcrypto 1
>> [ 5439.500918] ath10k_pci 0000:01:00.0: firmware register dump:
>> [ 5439.506678] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
>> 0x009A4577 0x00955B31
>> [ 5439.514706] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
>> 0x00000002 0x00439E98
>> [ 5439.522751] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
>> 0x00407120 0x004436CC
>> [ 5439.530794] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
>> 0x009A3518 0x009A3526
>> [ 5439.538834] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
>> 0x00000000 0x00000000
>> [ 5439.546871] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
>> 0x0040AC60 0x0040AC09
>> [ 5439.554915] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
>> 0x00400000 0xC09A4577
>> [ 5439.562948] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
>> 0x0044110C 0x00442074
>> [ 5439.570992] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
>> 0x0044110C 0x00407120
>> [ 5439.579032] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
>> 0x0040AC14 0x00001580
>> [ 5439.587070] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
>> 0x009C643C 0x004436CC
>> [ 5439.595113] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
>> 0x004208FC 0x00439E4C
>> [ 5439.603146] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
>> 0x004208FC 0x00425E00
>> [ 5439.611191] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
>> 0x00424FE8 0x00000002
>> [ 5439.619230] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
>> 0x00000004 0x004039D0
>> [ 5439.726818] ieee80211 phy0: Hardware restart was requested
>> [ 5439.732433] ath10k_pci 0000:01:00.0: wmi mgmt vdev down id 0x1
>> [ 5439.732461] ath10k_pci 0000:01:00.0: wmi vdev stop id 0x1
>> [ 5439.732482] ath10k_pci 0000:01:00.0: failed to synchronize monitor
>> vdev 1 stop: -143
>> [ 5439.740370] ath10k_pci 0000:01:00.0: mac monitor vdev 1 stopped
>> [ 5439.740386] ath10k_pci 0000:01:00.0: failed to stop monitor vdev:
>> -143
>> [ 5439.747042] ath10k_pci 0000:01:00.0: wmi disable pktlog
>>
>> We noticed in this log that when the radio starts up it says that it
>> is in VHT80 mode:
>> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
>> 5180 phymode 11ac-vht80
>>
>> But when a peer connects it seems to think the peer is in HT40 mode:
>> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
>> phymode 11na-ht40
>>
>> Compared to no encryption case - this log was taken from Node A:
>>
>> [ 24.874253] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180
>> width 3 ptr 86d26db0
>> [ 24.874278] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
>> needed? 0 allowed? 1
>> [ 24.874296] ath10k_pci 0000:01:00.0: mac chanctx assign ptr
>> 86d26db0 vdev_id 0
>> [ 24.874312] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
>> 5180 phymode 11ac-vht80
>> [ 24.874337] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 24.881335] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 24.881423] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
>> [ 24.881438] ath10k_pci 0000:01:00.0: mac txpower 23
>> [ 24.881454] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
>> [ 24.881491] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
>> [ 24.881515] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
>> width 3 ptr 86d26db0 changed 10
>> [ 24.881535] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
>> width 3 ptr 86d26db0 changed 2
>> [ 24.881554] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
>> needed? 1 allowed? 1
>> [ 24.881574] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
>> subtype 0 macaddr 18:a6:f7:23:6e:66
>> [ 24.881689] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
>> [ 24.881745] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
>> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
>> [ 25.273460] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 25.730570] ath10k_pci 0000:01:00.0: wmi event debug mesg len 300
>> [ 25.773566] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 25.874556] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
>> [ 25.879992] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc
>> id 0 bssid 18:a6:f7:23:6e:66
>> [ 25.880077] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
>> [ 25.880093] ath10k_pci 0000:01:00.0: mac monitor started
>> [ 25.880139] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
>> value 1000
>> [ 25.880184] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
>> [ 25.880199] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.880215] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.880235] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.880250] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.880988] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc
>> id 0 bssid 00:00:00:00:00:00
>> [ 25.881035] ath10k_pci 0000:01:00.0: mac vdev 0 up
>> [ 25.881097] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
>> [ 25.882968] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> [ 25.928796] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.928821] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.928866] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.928883] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.929020] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
>> needed? 1 allowed? 1
>> [ 25.941886] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.941911] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.941955] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.941972] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.953727] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.953753] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.953798] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.953817] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.970588] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.970614] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.970659] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.970676] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 25.989056] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 25.989081] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 25.989126] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 25.989143] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 26.071686] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
>> 18:a6:f7:26:0f:21 (new sta) sta 1 / 128 peer 2 / 144
>> [ 26.071712] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
>> peer_addr 18:a6:f7:26:0f:21
>> [ 26.071952] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:26:0f:21
>> associated
>> [ 26.071981] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:26:0f:21
>> mcs cnt 24 nss 3
>> [ 26.071999] ath10k_pci 0000:01:00.0: mac vht peer
>> 18:a6:f7:26:0f:21 max_mpdu 1048575 flags 0x601b001
>> [ 26.072013] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 qos 1
>> [ 26.072028] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21
>> phymode 11ac-vht80
>> [ 26.072047] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
>> 18:a6:f7:26:0f:21 (new)
>> [ 26.072071] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
>> 0x18:a6:f7:26:0f:21 set param 1 value 0
>> [ 26.072502] ath10k_pci 0000:01:00.0: received event id 36891 not
>> implemented
>> [ 26.074194] ath10k_pci 0000:01:00.0: mac sta rc update for
>> 18:a6:f7:26:0f:21 changed 00000000 bw 2 nss 3 smps 1
>> [ 26.074586] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
>> staggered
>> [ 26.074609] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
>> [ 26.074682] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
>> [ 26.074701] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
>> value 2
>> [ 26.074760] ath10k_pci 0000:01:00.0: mac vdev 0 slot_time 2
>> [ 26.074779] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 7
>> value 2
>> [ 26.273652] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 26.730650] ath10k_pci 0000:01:00.0: wmi event debug mesg len 44
>> [ 26.773733] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>> [ 27.135445] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
>> needed? 1 allowed? 1
>> [ 27.273810] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>>
>> It seems to start up in VHT80 mode and when it peers with Node B it
>> thinks Node B is also in VHT80 mode and ping works.
>>
>> 4. Beacons are sent at 6 Mb/s basic rate and unicast QoS Data is sent
>> with three spatial streams. Attached is the full pcap of the experiment.
>>
>> Thank you for looking into this!
>>
>> ~Benjamin
>>
>> On 12/05/2016 11:24 AM, Nagarajan, Ashok Raj wrote:
>>> 0x009A4577 0x00955B31
>>>
>>> Benjamin, Thanks for the logs.
>>> Quick questions to further debug the issue here,
>>>
>>> 1. Is this issue seen every time you start sending data traffic?
>>> 2. Issue seen with older firmwares? (FYR,
>>> http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
>>> 3. Could you please share the dmesg from your device after enabling
>>> MAC and WMI logs in ath10k driver
>>> To enable debug logs please see
>>> http://linuxwireless.org/en/users/Drivers/ath10k/debug/
>>> 4. Do you know what is the Number of Spatial Streams seen in mesh
>>> beacons and in mesh data packet?
>>>
>>> Thanks,
>>> Ashok
>>
>
^ permalink raw reply
* [PATCH V2] ath10k: fix incorrect txpower set by P2P_DEVICE interface
From: ryanhsu @ 2016-12-13 22:55 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: ryanhsu
From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Ath10k reports the phy capability that supports P2P_DEVICE interface.
When we use the P2P supported wpa_supplicant to start connection, it'll
create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).
ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
...
ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0
And the txpower in per vif bss_conf will only be set to valid tx power when
the interface is assigned with channel_ctx.
But this P2P_DEVICE interface will never be used for any connection, so
that the uninitialized bss_conf.txpower=0 is assinged to the
arvif->txpower when interface created.
Since the txpower configuration is firmware per physical interface.
So the smallest txpower of all vifs will be the one limit the tx power
of the physical device, that causing the low txpower issue on other
active interfaces.
wlan0: Limiting TX power to 21 (24 - 3) dBm
ath10k_pci mac vdev_id 0 txpower 21
ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
ath10k_pci mac txpower 0
This issue only happens when we use the wpa_supplicant that supports
P2P or if we use the iw tool to create the control P2P_DEVICE interface.
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index fe42bf5..6e1550b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4671,7 +4671,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar)
lockdep_assert_held(&ar->conf_mutex);
list_for_each_entry(arvif, &ar->arvifs, list) {
- WARN_ON(arvif->txpower < 0);
+ if (arvif->txpower <= 0)
+ continue;
if (txpower == -1)
txpower = arvif->txpower;
@@ -4679,8 +4680,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar)
txpower = min(txpower, arvif->txpower);
}
- if (WARN_ON(txpower == -1))
- return -EINVAL;
+ if (txpower == -1)
+ return 0;
ret = ath10k_mac_txpower_setup(ar, txpower);
if (ret) {
--
1.9.1
^ permalink raw reply related
* Re: [RFC V3 03/11] nl80211: add support for gscan
From: Johannes Berg @ 2016-12-13 22:29 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <3dd64ef5-f05e-4a80-0c98-9a2548affd1c@broadcom.com>
On Tue, 2016-12-13 at 21:09 +0100, Arend Van Spriel wrote:
>
> > There's a bit of a weird hard-coded restriction to 16 channels too,
> > that's due to the bucket map?
>
> Uhm. Is there? I will check, but if you can give me a pointer where
> to look it is appreciated.
Just look for "< 16" or "<= 16" or so in the patch. I do think that's
because the channel map is a u16 though, not sure we'd want to change
that.
johannes
^ permalink raw reply
* Re: [Patch] NFC: trf7970a:
From: Mark Greer @ 2016-12-13 22:05 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, justin
In-Reply-To: <20160422000119.GA21754@animalcreek.com>
On Thu, Apr 21, 2016 at 05:01:19PM -0700, Mark Greer wrote:
> On Mon, Apr 18, 2016 at 03:48:37PM -0400, Geoff Lansberry wrote:
>
> Hi Geoff.
>
> > The current version of the trf7970a driver is missing support for several features that we needed to operate a custom board.
> > We feel that these features will be useful to others as well, and we want to share them.
> >
> > 1: Support for using a gpio as Slave-Select. Our processor has several devices on the spi bus, and we ran out of ss lines. This patch gives TRF7970A the ability to
> > drive the ss line of the chip from a gpio that is defined in the device tree.
> >
> > 2. When reviewing problems we were having in our implementation with TI support staff, they recommended that during initialization, address 0x18 should be written to zero. This patch adds that change
> >
> > 3. This existing version of the driver assumes that the crystal driving the trf7970a is 13.56 MHz, because there are several places in the driver code where the rel
> > ated register is re-written, there is clean way to change to 27.12 MHz. This patch adds a device tree option for 27 MHz and properly or's in changes in locations w
> > here the register is changed.
> >
> > 4. the existing version of the driver assumes that 3.3 volt io is used. The trf7970a has a special register where you can configure it for 1.8 volt io. This patch
> > adds a device tree option to select that this setting should be made.
> >
> > [PATCH 1/4] NFC: trf7970a: Add support for gpio as SS
> > [PATCH 2/4] NFC: trf7970a: add TI recommended write of zero to
> > [PATCH 3/4] NFC: trf7970a: add device tree option for 27MHz clock
> > [PATCH 4/4] NFC: trf7970a: Add device tree option of 1.8 Volt IO
>
> I'm on vacation this week but will be back next week. I'll take a
> look once I'm back.
>
> In the meantime, for emails sent to public (techie) list always keep
> the lines less than 80 characters and always bottom-post (i.e., put
> your text *underneath* the text that you are responding to). Also,
> when you change one or more patches in a series, re-submit the entire
> series with the version number incremented (.e.g., v2, v3, ...) even
> when you change only one of them. It is a easier for others to know
> what the latest versions are that way.
Hi Geoff.
I know its been a ridiculously long time since I said I would look at
your patches but I have time now. Do you have an updated version of
your patch series?
Mark
--
^ permalink raw reply
* Re: [RFC V3 03/11] nl80211: add support for gscan
From: Arend Van Spriel @ 2016-12-13 20:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1481645962.20412.41.camel@sipsolutions.net>
On 13-12-2016 17:19, Johannes Berg wrote:
> On Mon, 2016-12-12 at 11:59 +0000, Arend van Spriel wrote:
>> This patch adds support for GScan which is a scan offload feature
>> used in Android.
>
> Found a few places with spaces instead of tabs as indentation, and
> spurious braces around single-statement things, but other than that it
> looks fine from a patch/nl80211 POV.
I added a check in wiphy_register() in this patch which actually is more
appropriate with the "gscan capabilities" patch.
> Haven't really looked into the details of gscan itself now though,
> sorry.
>
> There's a bit of a weird hard-coded restriction to 16 channels too,
> that's due to the bucket map?
Uhm. Is there? I will check, but if you can give me a pointer where to
look it is appreciated.
Regards,
Arend
^ permalink raw reply
* Re: [RFC V3 01/11] nl80211: add reporting of gscan capabilities
From: Arend Van Spriel @ 2016-12-13 20:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1481645701.20412.39.camel@sipsolutions.net>
On 13-12-2016 17:15, Johannes Berg wrote:
>
>> + case 14:
>> + if (!rdev->wiphy.gscan) {
>> + /* done */
>> + state->split_start = 0;
>> + break;
>> + }
>>
>
> Nit, but I'm not really happy with this - this assumes that case 14 is
> the last case, if anyone ever adds one we break this code but it would
> still work if the device has gscan. Move the gscan stuff into a new
> function and make that return immediately if gscan is NULL or so?
Agree. When coding this piece I was aware that this would need to change
when 'case 15' would be added, which is probably too easy to overlook. I
will change it.
Regards,
Arend
^ permalink raw reply
* Re: [RFC v2 05/11] ath10k: htc: refactorization
From: Michal Kazior @ 2016-12-13 19:21 UTC (permalink / raw)
To: Erik Stromdahl
Cc: Valo, Kalle, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <70b8a055-e6ba-857d-8b03-06f50e3f10fe@gmail.com>
On 13 December 2016 at 19:37, Erik Stromdahl <erik.stromdahl@gmail.com> wro=
te:
>
>
> On 12/13/2016 06:26 PM, Valo, Kalle wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> On 13 December 2016 at 14:44, Valo, Kalle <kvalo@qca.qualcomm.com> wrot=
e:
>>>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>>>
>>>>> Code refactorization:
>>>>>
>>>>> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
>>>>> to ath10k_htc_control_rx_complete.
>>>>>
>>>>> This eases the implementation of SDIO/mbox significantly since
>>>>> the ep_rx_complete cb is invoked directly from the SDIO/mbox
>>>>> hif layer.
>>>>>
>>>>> Since the ath10k_htc_control_rx_complete already is present
>>>>> (only containing a warning message) there is no reason for not
>>>>> using it (instead of having a special case for ep 0 in
>>>>> ath10k_htc_rx_completion_handler).
>>>>>
>>>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>>>
>>>> I tested this on QCA988X PCI board just to see if there are any
>>>> regressions. It crashes immediately during module load, every time, an=
d
>>>> bisected that the crashing starts on this patch:
>>>>
>>>> [ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 ir=
q_mode 0 reset_mode 0
>>>> [ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10=
k/pre-cal-pci-0000:02:00.0.bin failed with error -2
>>>> [ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10=
k/cal-pci-0000:02:00.0.bin failed with error -2
>>>> [ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016=
c chip_id 0x043202ff sub 0000:0000
>>>> [ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 trac=
ing 1 dfs 1 testmode 1
>>>> [ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 ap=
i 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
>>>> [ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10=
k/QCA988X/hw2.0/board-2.bin failed with error -2
>>>> [ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A cr=
c32 bebc7c08
>>>> [ 1241.136693] BUG: unable to handle kernel NULL pointer dereference a=
t (null)
>>>> [ 1241.136738] IP: [< (null)>] (null)
>>>> [ 1241.136759] *pdpt =3D 0000000000000000 *pde =3D f0002a55f0002a55 [ =
1241.136781]
>>>> [ 1241.136793] Oops: 0010 [#1] SMP
>>>>
>>>> What's odd is that when I added some printks on my own and enabled bot=
h
>>>> boot and htc debug levels it doesn't crash anymore. After everything
>>>> works normally after that, I can start AP mode and connect to it. Is i=
t
>>>> a race somewhere?
>>>
>>> Yes. htc_wait_target() is called after hif_start(). The ep_rx_complete
>>> is set in htc_wait_target() [changed patch 4, but still too late].
>>>
>>> ep_rx_complete must be set prior to calling hif_start(). You probably
>>> crash on end of ath10k_htc_rx_completion_handler() when trying to call
>>> ep->ep_ops.ep_rx_complete(ar, skb).
>>
>> Yeah, just checked and ep->ep_ops.ep_rx_complete is NULL at the end of
>> ath10k_htc_rx_completion_handler().
>>
> It is indeed correct as Michal points out, there is a risk that the
> first HTC control message (typically an HTC ready message) is received
> before the HTC control endpoint is connected.
>
> I have experienced a similar race with my SDIO implementation as well.
> In this case I did solve the issue by enabling HIF target interrupts
> after the HTC control endpoint was connected. I am not sure however if
> this is the most elegant way to solve this problem.
>
> My SDIO target won't send the HTC ready message before this is done.
> The fix essentially consists of moving the ..._irg_enable call from
> hif_start into another hif op.
It makes more sense to move ep_rx_complete setup/assignment before
hif_start(). This assignment should be done very early as there is
nothing to change/override for this endpoint during operation, is
there? It's known what it needs to store very early on.
> I have made a few updates since I submitted the original RFC and created
> a repo on github:
>
> https://github.com/erstrom/linux-ath
>
> I have a bunch of branches that are all based on the tags on the ath mast=
er.
>
> As of this moment the latest version is:
>
> ath-201612131156-ath10k-sdio
>
> This branch contains the original RFC patches plus some addons/fixes.
>
> In the above mentioned branch there are a few commits related to this
> race condition. Perhaps you can have a look at them?
>
> The commits are:
> 821672913328cf737c9616786dc28d2e4e8a4a90
I would avoid if(bus=3D=3Dxx) checks.
> dd7fcf0a1f78e68876d14f90c12bd37f3a700ad7
> 7434b7b40875bd08a3a48a437ba50afed7754931
>
> Perhaps this approach can work with PCIe as well?
I think I did contemplate the unmask/start distinction at some point
but I didn't go with it for some reason I can't recall now.
Micha=C5=82
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Benjamin Morgan @ 2016-12-13 18:42 UTC (permalink / raw)
To: Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan
Cc: agreen@cococorp.com, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <58472E7B.7090603@cococorp.com>
Just tested the latest 10.2.4.70.59-2 firmware and it still crashes with
wpa_supplicant encrypted mesh =(
[ 85.201440] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
b7f44483-0488-46af-8dff-db88f4b56327)
[ 85.210573] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c
chip_id 0x043202ff sub 0000:0000
[ 85.219940] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 1
[ 85.233034] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.59-2 api
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[ 85.245177] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[ 85.252592] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal file max-sta 128 raw 0 hwcrypto 1
[ 85.264235] ath10k_pci 0000:01:00.0: firmware register dump:
[ 85.269992] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
0x009A45AF 0x00955B31
[ 85.278031] ath10k_pci 0000:01:00.0: [04]: 0x009A45AF 0x00060130
0x00000002 0x00439E98
[ 85.286078] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
0x00407120 0x004436CC
[ 85.294107] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
0x009A3550 0x009A355E
[ 85.302152] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
0x00000000 0x00000000
[ 85.310195] ath10k_pci 0000:01:00.0: [20]: 0x409A45AF 0x0040AAC4
0x0040AC60 0x0040AC09
[ 85.318239] ath10k_pci 0000:01:00.0: [24]: 0x809A44F2 0x0040AB24
0x00400000 0xC09A45AF
[ 85.326282] ath10k_pci 0000:01:00.0: [28]: 0x809A3A16 0x0040AB84
0x0044110C 0x00442074
[ 85.334314] ath10k_pci 0000:01:00.0: [32]: 0x809A601A 0x0040ABB4
0x0044110C 0x00407120
[ 85.342350] ath10k_pci 0000:01:00.0: [36]: 0x809A2EA4 0x0040ABF4
0x0040AC14 0x00001580
[ 85.350393] ath10k_pci 0000:01:00.0: [40]: 0x80990F63 0x0040AD04
0x009C6458 0x004436CC
[ 85.358437] ath10k_pci 0000:01:00.0: [44]: 0x80998520 0x0040AD64
0x004208FC 0x00439E4C
[ 85.366479] ath10k_pci 0000:01:00.0: [48]: 0x8099AEA5 0x0040AD84
0x004208FC 0x00425AAC
[ 85.374512] ath10k_pci 0000:01:00.0: [52]: 0x809BFC39 0x0040AEE4
0x00424FE8 0x00000002
[ 85.382548] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
0x00000004 0x004039D0
[ 85.487067] ieee80211 phy0: Hardware restart was requested
[ 85.492701] ath10k_pci 0000:01:00.0: wmi disable pktlog
Any new leads on tracking down this issue?
~Benjamin
On 12/06/2016 01:32 PM, Benjamin Morgan wrote:
> 1. Yes, this appears to happens every time a unicast packet with
> wpa_supplicant encryption in VHT80 mode is received. I haven't seen a
> successful ping-pong pair.
> 2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
> 3. We ran our experiment again with extra debugging turned on.
> Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
> Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
> The ping command we used was run on Node A was 'ping -s 1500 -i
> 0.1 10.230.5.42'
> Here is the dmesg log from Node B.
>
> [ 5413.478170] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5413.503954] ath10k_pci 0000:01:00.0: scan event bss channel type 4
> reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
> [ 5413.503985] ath10k_pci 0000:01:00.0: chan info err_code 0 freq 5825
> cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count 312271423
> [ 5413.504029] ath10k_pci 0000:01:00.0: scan event completed type 2
> reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
> [ 5413.525868] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
> cipher 4 len 16
> [ 5413.526014] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
> value 1
> [ 5413.526193] ath10k_pci 0000:01:00.0: mac vdev 0 set keyidx 1
> [ 5413.526216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
> value 1
> [ 5413.526532] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180
> width 3 ptr 86db29b0
> [ 5413.526556] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
> needed? 0 allowed? 1
> [ 5413.526574] ath10k_pci 0000:01:00.0: mac chanctx assign ptr
> 86db29b0 vdev_id 0
> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
> 5180 phymode 11ac-vht80
> [ 5413.526616] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 5413.533099] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 5413.533148] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
> [ 5413.533163] ath10k_pci 0000:01:00.0: mac txpower 23
> [ 5413.533180] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
> [ 5413.533247] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
> [ 5413.533295] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
> width 3 ptr 86db29b0 changed 10
> [ 5413.533318] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
> width 3 ptr 86db29b0 changed 2
> [ 5413.533337] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
> needed? 1 allowed? 1
> [ 5413.533357] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
> subtype 0 macaddr 18:a6:f7:26:0f:21
> [ 5413.533412] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
> [ 5413.533463] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 5413.937652] ath10k_pci 0000:01:00.0: wmi event debug mesg len 152
> [ 5413.978273] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5414.478363] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5414.527015] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 5414.527067] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc
> id 0 bssid 18:a6:f7:26:0f:21
> [ 5414.527121] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
> [ 5414.527165] ath10k_pci 0000:01:00.0: mac monitor started
> [ 5414.527216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
> value 1000
> [ 5414.527262] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
> [ 5414.527278] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 5414.527294] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5414.527314] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5414.527330] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 5414.527457] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc
> id 0 bssid 00:00:00:00:00:00
> [ 5414.527501] ath10k_pci 0000:01:00.0: mac vdev 0 up
> [ 5414.527564] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
> [ 5414.541090] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
> needed? 1 allowed? 1
> [ 5414.978454] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5415.478548] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5415.978649] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5416.445280] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
> needed? 1 allowed? 1
> [ 5416.478761] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5416.978879] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5417.478985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5417.979081] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5418.479190] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5418.979301] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5419.479403] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5419.979551] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5420.479643] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5420.979746] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5421.479841] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5421.979940] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5422.480288] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5422.980386] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5423.480490] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5423.980600] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5424.480702] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5424.971969] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
> 18:a6:f7:23:6e:66 (new sta) sta 1 / 128 peer 2 / 144
> [ 5424.972000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
> peer_addr 18:a6:f7:23:6e:66
> [ 5424.975107] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 5424.975134] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5424.975219] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5424.975238] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 5424.980787] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.204468] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:23:6e:66
> associated
> [ 5425.204531] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:23:6e:66
> mcs cnt 24 nss 3
> [ 5425.204548] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 qos 1
> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
> phymode 11na-ht40
> [ 5425.204585] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
> 18:a6:f7:23:6e:66 (new)
> [ 5425.204614] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
> 0x18:a6:f7:23:6e:66 set param 1 value 0
> [ 5425.205376] ath10k_pci 0000:01:00.0: received event id 36891 not
> implemented
> [ 5425.209240] ath10k_pci 0000:01:00.0: wmi vdev install key idx 0
> cipher 4 len 16
> [ 5425.209655] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
> cipher 4 len 16
> [ 5425.209848] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31
> value 1
> [ 5425.210196] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 5425.210221] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 5425.210296] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 5425.210315] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 5425.480863] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.938619] ath10k_pci 0000:01:00.0: wmi event debug mesg len 100
> [ 5425.980946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5425.995007] ath10k_pci 0000:01:00.0: mac sta rc update for
> 18:a6:f7:23:6e:66 changed 00000001 bw 2 nss 3 smps 1
> [ 5425.995060] ath10k_pci 0000:01:00.0: mac update sta
> 18:a6:f7:23:6e:66 peer bw 2
> [ 5425.995081] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
> 0x18:a6:f7:23:6e:66 set param 4 value 2
> [ 5426.481030] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5426.981117] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5427.481206] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5427.981294] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5428.481628] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5428.981718] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5429.481812] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5429.981894] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5430.481985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5430.982073] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5431.482174] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5431.982505] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5432.482597] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5432.982679] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5433.482765] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5433.982857] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5434.482946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5434.983008] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5435.483100] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5435.983181] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5436.483276] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5436.983366] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5437.483445] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5437.983516] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5438.483607] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5438.983692] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 5439.439875] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> db76b67c-ca98-4519-a762-4ff4edb45526)
> [ 5439.449007] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 5439.458378] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 5439.471460] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [ 5439.481844] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 5439.489267] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal file max-sta 128 raw 0 hwcrypto 1
> [ 5439.500918] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 5439.506678] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A4577 0x00955B31
> [ 5439.514706] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> 0x00000002 0x00439E98
> [ 5439.522751] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [ 5439.530794] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A3518 0x009A3526
> [ 5439.538834] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [ 5439.546871] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [ 5439.554915] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> 0x00400000 0xC09A4577
> [ 5439.562948] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> 0x0044110C 0x00442074
> [ 5439.570992] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> 0x0044110C 0x00407120
> [ 5439.579032] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> 0x0040AC14 0x00001580
> [ 5439.587070] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> 0x009C643C 0x004436CC
> [ 5439.595113] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> 0x004208FC 0x00439E4C
> [ 5439.603146] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> 0x004208FC 0x00425E00
> [ 5439.611191] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> 0x00424FE8 0x00000002
> [ 5439.619230] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [ 5439.726818] ieee80211 phy0: Hardware restart was requested
> [ 5439.732433] ath10k_pci 0000:01:00.0: wmi mgmt vdev down id 0x1
> [ 5439.732461] ath10k_pci 0000:01:00.0: wmi vdev stop id 0x1
> [ 5439.732482] ath10k_pci 0000:01:00.0: failed to synchronize monitor
> vdev 1 stop: -143
> [ 5439.740370] ath10k_pci 0000:01:00.0: mac monitor vdev 1 stopped
> [ 5439.740386] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
> [ 5439.747042] ath10k_pci 0000:01:00.0: wmi disable pktlog
>
> We noticed in this log that when the radio starts up it says that it
> is in VHT80 mode:
> [ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
> 5180 phymode 11ac-vht80
>
> But when a peer connects it seems to think the peer is in HT40 mode:
> [ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
> phymode 11na-ht40
>
> Compared to no encryption case - this log was taken from Node A:
>
> [ 24.874253] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180
> width 3 ptr 86d26db0
> [ 24.874278] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
> needed? 0 allowed? 1
> [ 24.874296] ath10k_pci 0000:01:00.0: mac chanctx assign ptr
> 86d26db0 vdev_id 0
> [ 24.874312] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
> 5180 phymode 11ac-vht80
> [ 24.874337] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 24.881335] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 24.881423] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
> [ 24.881438] ath10k_pci 0000:01:00.0: mac txpower 23
> [ 24.881454] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
> [ 24.881491] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
> [ 24.881515] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
> width 3 ptr 86d26db0 changed 10
> [ 24.881535] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
> width 3 ptr 86d26db0 changed 2
> [ 24.881554] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
> needed? 1 allowed? 1
> [ 24.881574] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
> subtype 0 macaddr 18:a6:f7:23:6e:66
> [ 24.881689] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
> [ 24.881745] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
> 0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
> [ 25.273460] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 25.730570] ath10k_pci 0000:01:00.0: wmi event debug mesg len 300
> [ 25.773566] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 25.874556] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
> [ 25.879992] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc
> id 0 bssid 18:a6:f7:23:6e:66
> [ 25.880077] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
> [ 25.880093] ath10k_pci 0000:01:00.0: mac monitor started
> [ 25.880139] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
> value 1000
> [ 25.880184] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
> [ 25.880199] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.880215] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.880235] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.880250] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.880988] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc
> id 0 bssid 00:00:00:00:00:00
> [ 25.881035] ath10k_pci 0000:01:00.0: mac vdev 0 up
> [ 25.881097] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
> [ 25.882968] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 25.928796] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.928821] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.928866] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.928883] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.929020] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
> needed? 1 allowed? 1
> [ 25.941886] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.941911] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.941955] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.941972] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.953727] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.953753] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.953798] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.953817] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.970588] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.970614] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.970659] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.970676] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 25.989056] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 25.989081] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 25.989126] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 25.989143] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 26.071686] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
> 18:a6:f7:26:0f:21 (new sta) sta 1 / 128 peer 2 / 144
> [ 26.071712] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
> peer_addr 18:a6:f7:26:0f:21
> [ 26.071952] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:26:0f:21
> associated
> [ 26.071981] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:26:0f:21
> mcs cnt 24 nss 3
> [ 26.071999] ath10k_pci 0000:01:00.0: mac vht peer 18:a6:f7:26:0f:21
> max_mpdu 1048575 flags 0x601b001
> [ 26.072013] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 qos 1
> [ 26.072028] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21
> phymode 11ac-vht80
> [ 26.072047] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
> 18:a6:f7:26:0f:21 (new)
> [ 26.072071] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
> 0x18:a6:f7:26:0f:21 set param 1 value 0
> [ 26.072502] ath10k_pci 0000:01:00.0: received event id 36891 not
> implemented
> [ 26.074194] ath10k_pci 0000:01:00.0: mac sta rc update for
> 18:a6:f7:26:0f:21 changed 00000000 bw 2 nss 3 smps 1
> [ 26.074586] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
> staggered
> [ 26.074609] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
> [ 26.074682] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
> [ 26.074701] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13
> value 2
> [ 26.074760] ath10k_pci 0000:01:00.0: mac vdev 0 slot_time 2
> [ 26.074779] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 7
> value 2
> [ 26.273652] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 26.730650] ath10k_pci 0000:01:00.0: wmi event debug mesg len 44
> [ 26.773733] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
> [ 27.135445] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
> needed? 1 allowed? 1
> [ 27.273810] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
>
> It seems to start up in VHT80 mode and when it peers with Node B it
> thinks Node B is also in VHT80 mode and ping works.
>
> 4. Beacons are sent at 6 Mb/s basic rate and unicast QoS Data is sent
> with three spatial streams. Attached is the full pcap of the experiment.
>
> Thank you for looking into this!
>
> ~Benjamin
>
> On 12/05/2016 11:24 AM, Nagarajan, Ashok Raj wrote:
>> 0x009A4577 0x00955B31
>>
>> Benjamin, Thanks for the logs.
>> Quick questions to further debug the issue here,
>>
>> 1. Is this issue seen every time you start sending data traffic?
>> 2. Issue seen with older firmwares? (FYR,
>> http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
>> 3. Could you please share the dmesg from your device after enabling
>> MAC and WMI logs in ath10k driver
>> To enable debug logs please see
>> http://linuxwireless.org/en/users/Drivers/ath10k/debug/
>> 4. Do you know what is the Number of Spatial Streams seen in mesh
>> beacons and in mesh data packet?
>>
>> Thanks,
>> Ashok
>
^ permalink raw reply
* Re: [RFC v2 05/11] ath10k: htc: refactorization
From: Erik Stromdahl @ 2016-12-13 18:37 UTC (permalink / raw)
To: Valo, Kalle, michal.kazior@tieto.com
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <871sxbzqo6.fsf@kamboji.qca.qualcomm.com>
On 12/13/2016 06:26 PM, Valo, Kalle wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> On 13 December 2016 at 14:44, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>>
>>>> Code refactorization:
>>>>
>>>> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
>>>> to ath10k_htc_control_rx_complete.
>>>>
>>>> This eases the implementation of SDIO/mbox significantly since
>>>> the ep_rx_complete cb is invoked directly from the SDIO/mbox
>>>> hif layer.
>>>>
>>>> Since the ath10k_htc_control_rx_complete already is present
>>>> (only containing a warning message) there is no reason for not
>>>> using it (instead of having a special case for ep 0 in
>>>> ath10k_htc_rx_completion_handler).
>>>>
>>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>>
>>> I tested this on QCA988X PCI board just to see if there are any
>>> regressions. It crashes immediately during module load, every time, and
>>> bisected that the crashing starts on this patch:
>>>
>>> [ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
>>> [ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
>>> [ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
>>> [ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
>>> [ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
>>> [ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
>>> [ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
>>> [ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
>>> [ 1241.136693] BUG: unable to handle kernel NULL pointer dereference at (null)
>>> [ 1241.136738] IP: [< (null)>] (null)
>>> [ 1241.136759] *pdpt = 0000000000000000 *pde = f0002a55f0002a55 [ 1241.136781]
>>> [ 1241.136793] Oops: 0010 [#1] SMP
>>>
>>> What's odd is that when I added some printks on my own and enabled both
>>> boot and htc debug levels it doesn't crash anymore. After everything
>>> works normally after that, I can start AP mode and connect to it. Is it
>>> a race somewhere?
>>
>> Yes. htc_wait_target() is called after hif_start(). The ep_rx_complete
>> is set in htc_wait_target() [changed patch 4, but still too late].
>>
>> ep_rx_complete must be set prior to calling hif_start(). You probably
>> crash on end of ath10k_htc_rx_completion_handler() when trying to call
>> ep->ep_ops.ep_rx_complete(ar, skb).
>
> Yeah, just checked and ep->ep_ops.ep_rx_complete is NULL at the end of
> ath10k_htc_rx_completion_handler().
>
It is indeed correct as Michal points out, there is a risk that the
first HTC control message (typically an HTC ready message) is received
before the HTC control endpoint is connected.
I have experienced a similar race with my SDIO implementation as well.
In this case I did solve the issue by enabling HIF target interrupts
after the HTC control endpoint was connected. I am not sure however if
this is the most elegant way to solve this problem.
My SDIO target won't send the HTC ready message before this is done.
The fix essentially consists of moving the ..._irg_enable call from
hif_start into another hif op.
I have made a few updates since I submitted the original RFC and created
a repo on github:
https://github.com/erstrom/linux-ath
I have a bunch of branches that are all based on the tags on the ath master.
As of this moment the latest version is:
ath-201612131156-ath10k-sdio
This branch contains the original RFC patches plus some addons/fixes.
In the above mentioned branch there are a few commits related to this
race condition. Perhaps you can have a look at them?
The commits are:
821672913328cf737c9616786dc28d2e4e8a4a90
dd7fcf0a1f78e68876d14f90c12bd37f3a700ad7
7434b7b40875bd08a3a48a437ba50afed7754931
Perhaps this approach can work with PCIe as well?
/Erik
^ permalink raw reply
* Re: [RFC v2 05/11] ath10k: htc: refactorization
From: Valo, Kalle @ 2016-12-13 17:26 UTC (permalink / raw)
To: michal.kazior@tieto.com
Cc: Erik Stromdahl, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <CA+BoTQkuUFxnra75B4LpF5+k9yE7hkNYDXbtUMBLq2LFuPSasg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 13 December 2016 at 14:44, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>
>>> Code refactorization:
>>>
>>> Moved the code for ep 0 in ath10k_htc_rx_completion_handler
>>> to ath10k_htc_control_rx_complete.
>>>
>>> This eases the implementation of SDIO/mbox significantly since
>>> the ep_rx_complete cb is invoked directly from the SDIO/mbox
>>> hif layer.
>>>
>>> Since the ath10k_htc_control_rx_complete already is present
>>> (only containing a warning message) there is no reason for not
>>> using it (instead of having a special case for ep 0 in
>>> ath10k_htc_rx_completion_handler).
>>>
>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>
>> I tested this on QCA988X PCI board just to see if there are any
>> regressions. It crashes immediately during module load, every time, and
>> bisected that the crashing starts on this patch:
>>
>> [ 1239.715325] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_=
mode 0 reset_mode 0
>> [ 1239.885125] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/=
pre-cal-pci-0000:02:00.0.bin failed with error -2
>> [ 1239.885260] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/=
cal-pci-0000:02:00.0.bin failed with error -2
>> [ 1239.885687] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c =
chip_id 0x043202ff sub 0000:0000
>> [ 1239.885699] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracin=
g 1 dfs 1 testmode 1
>> [ 1239.885899] ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api =
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
>> [ 1239.941836] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/=
QCA988X/hw2.0/board-2.bin failed with error -2
>> [ 1239.941993] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc3=
2 bebc7c08
>> [ 1241.136693] BUG: unable to handle kernel NULL pointer dereference at =
(null)
>> [ 1241.136738] IP: [< (null)>] (null)
>> [ 1241.136759] *pdpt =3D 0000000000000000 *pde =3D f0002a55f0002a55 [ 12=
41.136781]
>> [ 1241.136793] Oops: 0010 [#1] SMP
>>
>> What's odd is that when I added some printks on my own and enabled both
>> boot and htc debug levels it doesn't crash anymore. After everything
>> works normally after that, I can start AP mode and connect to it. Is it
>> a race somewhere?
>
> Yes. htc_wait_target() is called after hif_start(). The ep_rx_complete
> is set in htc_wait_target() [changed patch 4, but still too late].
>
> ep_rx_complete must be set prior to calling hif_start(). You probably
> crash on end of ath10k_htc_rx_completion_handler() when trying to call
> ep->ep_ops.ep_rx_complete(ar, skb).
Yeah, just checked and ep->ep_ops.ep_rx_complete is NULL at the end of
ath10k_htc_rx_completion_handler().
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH v2] ath9k: do not return early to fix rcu unlocking
From: Tobias Klausmann @ 2016-12-13 17:08 UTC (permalink / raw)
To: kvalo, helgaas, linux-kernel, linux-pci, marc.zyngier,
Janusz.Dziedzic, ath9k-devel, linux-wireless, rmanohar,
bharat.kumar.gogada
Cc: Tobias Klausmann, # v4 . 9
In-Reply-To: <e15c5efc-d548-8b32-ca86-5ec26506ff7c@nbd.name>
Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb
where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
and suspicious RCU usage:
===============================
[ INFO: suspicious RCU usage. ]
4.9.0-rc8 #11 Not tainted
-------------------------------
kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by swapper/7/0:
#0:
(
rcu_read_lock
){......}
, at:
[<ffffffffa06ed110>] ath_tx_edma_tasklet+0x0/0x450 [ath9k]
stack backtrace:
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001
ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8
ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4
Call Trace:
<IRQ>
[<ffffffff8132b1e5>] dump_stack+0x68/0x93
[<ffffffff810a25f7>] lockdep_rcu_suspicious+0xd7/0x110
[<ffffffff810c3cd4>] rcu_eqs_enter_common.constprop.85+0x154/0x200
[<ffffffff810c5a54>] rcu_irq_exit+0x44/0xa0
[<ffffffff81058631>] irq_exit+0x61/0xd0
[<ffffffff81018d25>] do_IRQ+0x65/0x110
[<ffffffff81672189>] common_interrupt+0x89/0x89
<EOI>
[<ffffffff814ffe11>] ? cpuidle_enter_state+0x151/0x200
[<ffffffff814ffee2>] cpuidle_enter+0x12/0x20
[<ffffffff8109a6ae>] call_cpuidle+0x1e/0x40
[<ffffffff8109a8f6>] cpu_startup_entry+0x146/0x220
[<ffffffff810336f8>] start_secondary+0x148/0x170
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
Cc: <stable@vger.kernel.org> # v4.9
---
v2: break instead of unlock (rename patch) [Felix Fietkau],
fix reference to commit [Kalle Valo]
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..e47286bf378e 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,7 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = &txq->txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
- return;
+ break;
}
bf = list_first_entry(fifo_list, struct ath_buf, list);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations
From: Kalle Valo @ 2016-12-13 17:03 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, linux-kernel@vger.kernel.org, USB list,
Linux Wireless List, Eric Biggers, linux-crypto, Herbert Xu,
Stephan Mueller
In-Reply-To: <CALCETrXxQ9FxuqV5A1rkj2SpeFfd89njDP9h5VBuNx387ieKdQ@mail.gmail.com>
Andy Lutomirski <luto@amacapital.net> writes:
> On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Andy Lutomirski <luto@kernel.org> writes:
>>
>>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>>> at the stack.
>>>
>>> Fix it by switching from ahash to shash. The result should be
>>> simpler, faster, and more correct.
>>>
>>> Cc: stable@vger.kernel.org # 4.9 only
>>> Reported-by: Eric Biggers <ebiggers3@gmail.com>
>>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>>
>> "more correct"? Does this fix a real user visible bug or what? And why
>> just stable 4.9, does this maybe have something to do with
>> CONFIG_VMAP_STACK?
>
> Whoops, I had that text in some other patches but forgot to put it in
> this one. It'll blow up with CONFIG_VMAP_STACK=y if a debug option
> like CONFIG_DEBUG_VIRTUAL=y is set. It may work by accident if
> debugging is off.
Makes sense now, thanks. I'll add that to the commit log and queue this
to 4.10.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations
From: Andy Lutomirski @ 2016-12-13 16:41 UTC (permalink / raw)
To: Kalle Valo
Cc: Andy Lutomirski, linux-kernel@vger.kernel.org, USB list,
Linux Wireless List, Eric Biggers, linux-crypto, Herbert Xu,
Stephan Mueller
In-Reply-To: <87mvg0kqno.fsf@purkki.adurom.net>
On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Andy Lutomirski <luto@kernel.org> writes:
>
>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>> at the stack.
>>
>> Fix it by switching from ahash to shash. The result should be
>> simpler, faster, and more correct.
>>
>> Cc: stable@vger.kernel.org # 4.9 only
>> Reported-by: Eric Biggers <ebiggers3@gmail.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>
> "more correct"? Does this fix a real user visible bug or what? And why
> just stable 4.9, does this maybe have something to do with
> CONFIG_VMAP_STACK?
Whoops, I had that text in some other patches but forgot to put it in
this one. It'll blow up with CONFIG_VMAP_STACK=y if a debug option
like CONFIG_DEBUG_VIRTUAL=y is set. It may work by accident if
debugging is off.
--Andy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox