Re: [LEDE-DEV] ath10k firmware crashes in mesh mode on QCA9880

[Adrian Chadd]

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 <agr...@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 <adr...@freebsd.org> wrote:
>> Hi!
>>
>> Hm! So is there a firmware bug if there are 11n only capable nodes in
>> an 11s mesh?
>>
>>
>>
>> -adrian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] ath10k firmware crashes in mesh mode on QCA9880

[Adrian Chadd]

Hi!

Hm! So is there a firmware bug if there are 11n only capable nodes in
an 11s mesh?



-adrian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients

[Adrian Chadd]

hiya!

Can you file a kernel.org bug mentioning this?

thanks!


-a


On 18 November 2016 at 01:30, Timo Sigurdsson
 wrote:
> Hi again,
>
> in the meantime, I have some more information to add to the issue mentioned in
> my email quoted further down below.
>
> Ben Greear approached me off-list and suggested to try the Candela Tech ath10k
> driver and firmware and see if the issue occurs with that as well. So, for the
> last 3 weeks I've been testing the CT driver and firmware and I can happily
> report that the issue with the driver crashing after a while when a Nexus 5X
> device is connected is not occuring with the current BETA 18
> firmware-2-ct-full-community.bin. So, this really seems like a regression in
> the official API level 5 ath10k firmware blobs.
>
> The CT firmware is not perfect either, since it seems to suffer from a 
> different
> bug that has been resolved in the official firmwares, and that is that after a
> reboot of my TP-Link Archer C7 v2, the ath10k driver won't load. Only after a
> hard reset or "cold boot" it will come up. That's an issue I had with older
> official firmwares as well, but it has been resolved with the recent API level
> 5 firmwares.
>
> Nevertheless, for the time being, I will stick to the CT firmware because I 
> can
> work around the reboot issue and having the 5GHz wifi working for my Nexus 5X
> clients is more important.
>
> Over the next weeks, I will test different combinations of ath10k(-ct) driver
> and firmware to see if there's a combination that resolves all issues. This
> morning I flashed a LEDE build with the official ath10k driver and the CT
> firmware binary.
>
> But of course, if someone has more suggestions on what I could try or what
> information I could collect to help resolve the issue related to the Nexus 5X
> clients in the official firmware binaries, I think that would be beneficial
> for a larger audience.
>
> Regards,
>
> Timo
>
> P.S.: Please include my email address in any reply, since I'm not subscribed
> to the mailing list. Thank you.
>
>
> Timo Sigurdsson schrieb am 29.10.2016 22:19:
>
>> Hi everybody,
>>
>> I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE (r1952,
>> Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for the
>> fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel or
>> ath10k driver will crash after a while. 5Ghz wifi will be dead after that
>> until I reboot the system.
>>
>> This issue has been reported before [1] and it also has been declared as
>> solved with newer firmwares [2] (but reopened by other users). However, even
>> with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository the
>> issue is far from resolved. I have tried many different firmware revisions
>> over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can could
>> only find that the issue sometimes takes longer to trigger with some 
>> firmwares
>> (which might just be random), but it would always occur at some point with 
>> API
>> level 5 firmwares. With API level 2 firmwares (which I testesd when I was
>> still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X had
>> other connectivity issues with these older firmwares that made this
>> combination no fun to use either. But this shows that the firmware itself
>> makes the difference here.
>>
>> I actually have two Nexus 5X on my network (my wife's and my own). I can
>> trigger the crash with either one of them. And if both Nexus 5X are connected
>> to the 5Ghz radio, then the issue triggers much faster (can be as low as 15
>> minutes). My workaround is to let the Nexus 5X devices only connect to the
>> 2.4GHz radio. This way, the device can runs for weeks without any issue or
>> crash, but of course I would prefer the actual bug being fixed rather than to
>> circumvent it.
>>
>> I'm appending a syslog from my access point with a crash happening while one
>> Nexus 5X was connected to the 5GHz radio starting from the time the system
>> booted. I randomized the MAC addresses. but left the first two characters
>> unique so different clients can be distinguished.
>>
>> If there is more info I could collect to help identify the cause of this
>> issue, please let me know (and possibly how to do that as well).
>>
>> Thank you and regards,
>>
>> Timo
>>
>> [1] http://lists.infradead.org/pipermail/ath10k/2015-November/006413.html
>> [2] https://dev.openwrt.org/ticket/20854
>>
>> And here's the log:
>> Fri Oct 28 02:01:35 2016 kern.notice kernel: [0.00] Linux version
>> 4.4.26 (user@buildsystem) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1952) ) #0 Fri
>> Oct 21 15:52:28 2016
>> [...]
>> Fri Oct 28 02:01:35 2016 kern.info kernel: [9.468751] Loading modules
>> backported from Linux version wt-2016-10-03-1-g6fcb1a6
>> Fri Oct 28 02:01:35 2016 kern.info kernel: [9.476481] Backport generated 
>> by
>> backports.git backports-20160324-9-g0e38f5c
>> Fri Oct 28 02:01:35