Re: ath10k: wmi service ready event not received

2019-05-14 Thread Kalle Valo
Linus Torvalds writes: > On Fri, May 10, 2019 at 7:25 AM Kalle Valo wrote: >> >> Can you post dmesg log when ath10k starts so that we know what hardware >> and firmware you are using? "dmesg | grep ath10k" should tell that, I >> assume this is a QCA6174 PCI device. Even better if you can provide

Re: [PATCH] mac80211: remove warning message

2019-05-14 Thread Johannes Berg
On Fri, 2019-05-10 at 15:01 +0800, Yibo Zhao wrote: > In multiple SSID cases, it takes time to prepare every AP interface > to be ready in initializing phase. If a sta already knows everything it > needs to join one of the APs and sends authentication to the AP which > is not fully prepared at this

[PATCH v2] mac80211: remove warning message

2019-05-14 Thread Yibo Zhao
In multiple SSID cases, it takes time to prepare every AP interface to be ready in initializing phase. If a sta already knows everything it needs to join one of the APs and sends authentication to the AP which is not fully prepared at this point of time, AP's channel context could be NULL. As a res

Re: [PATCH v2] mac80211: remove warning message

2019-05-14 Thread Johannes Berg
On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote: > In multiple SSID cases, it takes time to prepare every AP interface > to be ready in initializing phase. If a sta already knows everything it > needs to join one of the APs and sends authentication to the AP which > is not fully prepared at this

Re: [PATCH v2] mac80211: remove warning message

2019-05-14 Thread Yibo Zhao
On 2019-05-14 17:05, Johannes Berg wrote: On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote: In multiple SSID cases, it takes time to prepare every AP interface to be ready in initializing phase. If a sta already knows everything it needs to join one of the APs and sends authentication to the

Re: [PATCH v2] mac80211: remove warning message

2019-05-14 Thread Johannes Berg
On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote: > On 2019-05-14 17:05, Johannes Berg wrote: > > On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote: > > > In multiple SSID cases, it takes time to prepare every AP interface > > > to be ready in initializing phase. If a sta already knows everythin

Re: [PATCH v2] mac80211: remove warning message

2019-05-14 Thread Joe Perches
On Tue, 2019-05-14 at 11:12 +0200, Johannes Berg wrote: > On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote: > > On 2019-05-14 17:05, Johannes Berg wrote: > > > On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote: > > > > In multiple SSID cases, it takes time to prepare every AP interface > > > > t

Re: [PATCH v2] mac80211: remove warning message

2019-05-14 Thread Ben Greear
On 5/14/19 8:44 AM, Joe Perches wrote: On Tue, 2019-05-14 at 11:12 +0200, Johannes Berg wrote: On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote: On 2019-05-14 17:05, Johannes Berg wrote: On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote: In multiple SSID cases, it takes time to prepare eve

Re: [PATCH v2] mac80211: remove warning message

2019-05-14 Thread Johannes Berg
> We know the WARN hits, we have the backtrace, and it is easy enough (in my > setup > at least) to reproduce this. So, the WARN logic has done its job. > > Having more of these spam the kernel doesn't add much benefit I think. Well, this doesn't necessarily just catch a *single* issue, so it

Re: [PATCH v2] mac80211: remove warning message

2019-05-14 Thread Ben Greear
On 5/14/19 11:40 AM, Johannes Berg wrote: We know the WARN hits, we have the backtrace, and it is easy enough (in my setup at least) to reproduce this. So, the WARN logic has done its job. Having more of these spam the kernel doesn't add much benefit I think. Well, this doesn't necessarily

Re: [PATCH v2] mac80211: remove warning message

2019-05-14 Thread Johannes Berg
On Tue, 2019-05-14 at 11:54 -0700, Ben Greear wrote: > > Here is the info I have in my commit that changed this to WARN_ON_ONCE. > I never posted it because I had to hack ath10k to get to this state, so maybe > this is not a valid case to debug. > > > Maybe Yibo Zhao has a better example. > >

Problem with 9984 in routed mode with 512b frames.

2019-05-14 Thread Ben Greear
Hello, I found a strange issue and curious if someone has seen similar. I made an AP where the AP interface acts as a routed interface. I generate traffic through another interface in the router. When sending 300Mbps of 512 byte UDP payloads, in the downstream direction, and with the station

Re: [PATCH v2] ath10k: add support for simulate crash on SDIO chip

2019-05-14 Thread Claire Chang
Tested-by: Claire Chang If this patch adds support for detecting the real firmware assert, maybe the title should be "add support for _crash recovery_ on SDIO chip"

[PATCH] ath10k: change firmware file name for UTF mode of SDIO/USB

2019-05-14 Thread Wen Gong
Firmware name for UTF mode of SDIO has changed from utf-2.bin to utf-sdio-2.bin, so it need to change in ath10k, otherwise it will fail for UTF mode. After change the name in ath10k, it will success for UTF mode of SDIO/USB. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-7-QCARMSWP-1.

Re: Problem with 9984 in routed mode with 512b frames.

2019-05-14 Thread Sebastian Gottschall
can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?) Sebastian Am 15.05.2019 um 03:52 schrieb Ben Greear: Hello, I found a strange issue and curious if someone has seen similar. I made an AP where th