On 2018-03-16 00:49, Ben Greear wrote:
On 03/15/2018 04:44 PM, Rosen Penev wrote:
On Sun, Mar 4, 2018 at 3:05 PM, Stefan Lippers-Hollmann
<s....@gmx.de> wrote:
Hi
On 2018-03-04, Hauke Mehrtens wrote:
On 03/04/2018 06:40 PM, Rosen Penev wrote:
[...]
On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev <ros...@gmail.com> wrote:
[...]
I also saw problems with the 10.2.4-1.0-00033 FW on my BT HH5, the
ath10k wifi was just not available after some time.
I am now trying the FW 10.2.4-1.0-00037, see this commit:
https://github.com/kvalo/ath10k-firmware/commit/31695fbc77f81391f579747bb8e51c50a581c3cd
10.2.4-1.0-00037 has been fine for me on the BT Business Hub 5 Type A
for the last couple of days, however my uptimes haven't been much
higher
than 3-4 days each (for unrelated reasons).
I tested again. It seems while 29 is more stable, I've gotten the
uptime to as low as 20 hours. It seems one of my devices is wrecking
the firmware.
I have since updated to ath10k-ct with its corresponding firmware and
currently have an uptime of 20 hours. Besides the incessant debug span
in dmesg, it seems to be working well.
You can get rid of that spam:
See the first entry here:
http://www.candelatech.com/ath10k-ug.php
If you find any crashes, let me know, or open a bug on the ath10k-ct
github project that I run....
Thanks,
Ben
Hi Ben,
Slightly offtopic, but:
Any reason why this is on by default?
I also noticed this while testing IBSS capability some time ago and my
1st thought was: "Is something wrong now??"
As the dmesg buffer is circular, all the debug prints start overwriting
the early bootprints after some time.
When another component fails, it gets difficult fetching a full bootlog
containing kernel version etc due to this.
It can be turned off easily, but reversing that logic also suggest it
could be turned on easily should any issues be noticed :)
Thanks,
Koen
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
