Incomplete scan results after rf(un)kill

Daniel J Blueman daniel at quora.org
Mon Jan 30 04:56:11 PST 2017


On 30 January 2017 at 16:04, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
> Daniel J Blueman <daniel at quora.org> writes:
>
>> On 27 January 2017 at 23:44, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
>>> Daniel J Blueman <daniel at 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.

Good tip; I'll harvest this info at next occurrence.

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

I'm using the ubuntu mainline builds; WARN_ON_ONCE(work > weight) is
at line 5161 in dev.c in 4.9.6.

Thanks,
  Daniel
-- 
Daniel J Blueman



More information about the ath10k mailing list