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

Message ID 20180304173143.4892-1-rosenp@gmail.com
State Superseded
Headers show
Series
  • [LEDE-DEV] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"
Related show

Commit Message

Rosen Penev March 4, 2018, 5:31 p.m.
This reverts commit 8d755ef052dca29db3b8da74149d9c7d74a54842.

The 33 firmware for QCA988x is not stable for me on both my Turris Omnia and my Archer C7v2. With version 33, I cannot get uptime longer than 2 days before the ath10k driver crashes. With version 29, I've gotten 49 days uptime with 29 of those days having a properly working 5GHz interface.

I have also tested version 37 but that one behaves similar to 33 with the ath10k driver crashing.

Other reports indicate similar findings: https://forum.lede-project.org/t/archer-c7-v4-support/3924/152

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 package/firmware/ath10k-firmware/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Rosen Penev March 4, 2018, 5:40 p.m. | #1
I would like this to be backported to 17.01 as well. The mentioned
Archer C7v2 runs 17.01. No impact between 17.01 and master.

On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev <rosenp@gmail.com> wrote:
> This reverts commit 8d755ef052dca29db3b8da74149d9c7d74a54842.
>
> The 33 firmware for QCA988x is not stable for me on both my Turris Omnia and my Archer C7v2. With version 33, I cannot get uptime longer than 2 days before the ath10k driver crashes. With version 29, I've gotten 49 days uptime with 29 of those days having a properly working 5GHz interface.
>
> I have also tested version 37 but that one behaves similar to 33 with the ath10k driver crashing.
>
> Other reports indicate similar findings: https://forum.lede-project.org/t/archer-c7-v4-support/3924/152
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>  package/firmware/ath10k-firmware/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile
> index 5b582085a4..2fc3618995 100644
> --- a/package/firmware/ath10k-firmware/Makefile
> +++ b/package/firmware/ath10k-firmware/Makefile
> @@ -253,7 +253,7 @@ define Package/ath10k-firmware-qca988x/install
>                 $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
>                 $(1)/lib/firmware/ath10k/QCA988X/hw2.0/
>         $(INSTALL_DATA) \
> -               $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
> +               $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
>                 $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
>  endef
>
> --
> 2.14.3
>
Hauke Mehrtens March 4, 2018, 9:58 p.m. | #2
On 03/04/2018 06:40 PM, Rosen Penev wrote:
> I would like this to be backported to 17.01 as well. The mentioned
> Archer C7v2 runs 17.01. No impact between 17.01 and master.
> 
> On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev <rosenp@gmail.com> wrote:
>> This reverts commit 8d755ef052dca29db3b8da74149d9c7d74a54842.
>>
>> The 33 firmware for QCA988x is not stable for me on both my Turris Omnia and my Archer C7v2. With version 33, I cannot get uptime longer than 2 days before the ath10k driver crashes. With version 29, I've gotten 49 days uptime with 29 of those days having a properly working 5GHz interface.
>>
>> I have also tested version 37 but that one behaves similar to 33 with the ath10k driver crashing.
>>
>> Other reports indicate similar findings: https://forum.lede-project.org/t/archer-c7-v4-support/3924/152
>>
>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>> ---
>>  package/firmware/ath10k-firmware/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile
>> index 5b582085a4..2fc3618995 100644
>> --- a/package/firmware/ath10k-firmware/Makefile
>> +++ b/package/firmware/ath10k-firmware/Makefile
>> @@ -253,7 +253,7 @@ define Package/ath10k-firmware-qca988x/install
>>                 $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
>>                 $(1)/lib/firmware/ath10k/QCA988X/hw2.0/
>>         $(INSTALL_DATA) \
>> -               $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
>> +               $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
>>                 $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
>>  endef

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

Hauke
Rosen Penev March 4, 2018, 10:58 p.m. | #3
On Sun, Mar 4, 2018 at 1:58 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> On 03/04/2018 06:40 PM, Rosen Penev wrote:
>> I would like this to be backported to 17.01 as well. The mentioned
>> Archer C7v2 runs 17.01. No impact between 17.01 and master.
>>
>> On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev <rosenp@gmail.com> wrote:
>>> This reverts commit 8d755ef052dca29db3b8da74149d9c7d74a54842.
>>>
>>> The 33 firmware for QCA988x is not stable for me on both my Turris Omnia and my Archer C7v2. With version 33, I cannot get uptime longer than 2 days before the ath10k driver crashes. With version 29, I've gotten 49 days uptime with 29 of those days having a properly working 5GHz interface.
>>>
>>> I have also tested version 37 but that one behaves similar to 33 with the ath10k driver crashing.
>>>
>>> Other reports indicate similar findings: https://forum.lede-project.org/t/archer-c7-v4-support/3924/152
>>>
>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>> ---
>>>  package/firmware/ath10k-firmware/Makefile | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile
>>> index 5b582085a4..2fc3618995 100644
>>> --- a/package/firmware/ath10k-firmware/Makefile
>>> +++ b/package/firmware/ath10k-firmware/Makefile
>>> @@ -253,7 +253,7 @@ define Package/ath10k-firmware-qca988x/install
>>>                 $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
>>>                 $(1)/lib/firmware/ath10k/QCA988X/hw2.0/
>>>         $(INSTALL_DATA) \
>>> -               $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
>>> +               $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
>>>                 $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
>>>  endef
>
> 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
>
I mentioned in the  commit message that I tried version 37 but it
gives me similar results to 33. Unfortunately, there seems to be no
quality control at Qualcomm...

Firmware 29 is somewhat recent and mostly stable.
> Hauke
Stefan Lippers-Hollmann March 4, 2018, 11:05 p.m. | #4
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@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).

Regards
	Stefan Lippers-Hollmann
Rosen Penev March 15, 2018, 11:44 p.m. | #5
On Sun, Mar 4, 2018 at 3:05 PM, Stefan Lippers-Hollmann <s.l-h@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@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.

Basically, this patch can be dropped .
> Regards
>         Stefan Lippers-Hollmann
Ben Greear March 15, 2018, 11:49 p.m. | #6
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@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@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
Koen Vandeputte March 16, 2018, 11:06 a.m. | #7
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@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@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
Ben Greear March 16, 2018, 3:34 p.m. | #8
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@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@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
>

Patch

diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile
index 5b582085a4..2fc3618995 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -253,7 +253,7 @@  define Package/ath10k-firmware-qca988x/install
 		$(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
 		$(1)/lib/firmware/ath10k/QCA988X/hw2.0/
 	$(INSTALL_DATA) \
-		$(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
+		$(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
 		$(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
 endef