[LEDE-DEV] [PATCH] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"

Ben Greear greearb at candelatech.com
Fri Mar 16 08:34:14 PDT 2018



On 03/16/2018 04:06 AM, Koen Vandeputte wrote:
>
>
> 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.l-h at 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 <rosenp at 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 :)

Yeah, I think it is probably time to disable the logging by default.

I'll do that some time soon.

Thanks,
Ben

>
> Thanks,
>
> Koen
>

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



More information about the Lede-dev mailing list