Re: Incomplete scan results after rf(un)kill

From: "Valo, Kalle" <kvalo@qca.qualcomm.com>
To: Daniel J Blueman <daniel@quora.org>
Cc: "ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: Incomplete scan results after rf(un)kill
Date: Mon, 30 Jan 2017 08:04:27 +0000	[thread overview]
Message-ID: <8737g1t1mh.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CAMVG2stRGR-rUAXABRaJjgD-816J5s2Jug0cB_sgfjnTjDWobg@mail.gmail.com>	(Daniel J. Blueman's message of "Sun, 29 Jan 2017 10:38:19 +0800")

Daniel J Blueman <daniel@quora.org> writes:

> On 27 January 2017 at 23:44, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>> Daniel J Blueman <daniel@quora.org> writes:
>>
>>> On 4.9.5 and previous, I've noticed that 20% of the time after
>>> rfunkilling, AP scan results would often have only 1-2 out of the
>>> previous 10 APs, and the situation would persist until removing and
>>> reinserting the ath10k_pci module.
>>>
>>> This is on my Dell XPS 13 9360 (Kaby Lake) with current BIOS 1.2.3 on
>>> Ubuntu (ElementaryOS) 16.04 with updates.
>>>
>>> Could this have any relation to the missing firmware [1]?
>>>
>>> What state can I capture to help diagnose this?
>>
>> Do you see any pattern what APs are visible when the bug happens? For
>> example, are those 1-2 APs always the same one? And are they ones with
>> strongest signal strength or maybe related to certain channels?
>>
>> After the bug happens how does the device work otherwise? Have you
>> tested performance (iperf) or signal strength? Is there any packet loss
>> etc?
>
> Many thanks for following up Kalle! Interestingly, I do see the same
> subset of APs (but not the strongest) in the Networkmanager GUI,
> however when I scan from the CLI, nothing:
>
> # nmcli dev wifi
> *  SSID  MODE  CHAN  RATE  SIGNAL  BARS  SECURITY
> #

Better to use 'sudo iw wlan0 scan' (or whatever is the ath10k network
interface name in your setup, systemd has made guessing the name
difficult). That provides more information and communicates directly
with kernel.

> The issue also occurs when coming out of suspend. I didn't check dmesg
> other times, but this may or may not be related:
>
> [  204.454815] WARNING: CPU: 3 PID: 0 at
> /home/kernel/COD/linux/net/core/dev.c:5161 net_rx_action+0x26e/0x380

It may very well be. Do you know exactly to what warning that line 5161
points to in your kernel version? With latest ath.git master branch line
5182 in dev.c is this warning napi_poll():

	WARN_ON_ONCE(work > weight);

But I do not know if you are seeing that warning or something else
because my kernel sources doesn't match what you use.

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