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
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.
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"
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
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.
>
>
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
> 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
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
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
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
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
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
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
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
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
15 matches
Mail list logo
