ath10k-ct: workaround TX rate code firmware bug #129
Conversation
|
So instead of the huge WARN_ONCE I now get following: |
|
Could you please change the printk output to specify which place in the code is generating the warning message? That will help me understand what is broken in firmware. And, you can just do the patch against a single tree...I'll pull this into my upstream kernels manually, then backport, then re-pull into ath10k-ct. |
ynezz
force-pushed
the
upstream/workaround-invalid-tx-rate
branch
from
10bc073
to
4aa51bc
Compare
Is this enough? ath10k-5.4/htt_rx.c: dev_warn_once(ar->dev, "htt tx ct: fixing invalid VHT TX rate code 0xff\n");
ath10k-5.4/htt_rx.c: dev_warn_once(ar->dev, "htt tx: fixing invalid VHT TX rate code 0xff\n");
ath10k-5.4/wmi.c: dev_warn_once(ar->dev, "wmi: fixing invalid VHT TX rate code 0xff\n");
As I don't know if/how fast is this going to propagate into your trees, I've simply fixed OpenWrt 19.07 and snapshot kernel version so I could simply reuse this. |
|
Your change looks good, plz update the pull request and I'll get it merged and propagated today. |
It seems, that we get a bad tx/rx rate from firmware, it is not a real problem so just check for invalid rate (0xff) and force it to be zero instead. Fixes: greearb#117 Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3055 Signed-off-by: Petr Štetiar <ynezz@true.cz>
ynezz
force-pushed
the
upstream/workaround-invalid-tx-rate
branch
from
4aa51bc
to
c1b6fa6
Compare
|
Done. |
|
I pushed this to ath10k-ct, please test if you are able, and update OpenWrt to use latest ath10k-ct commit id. I had to tweak the 4.19 code as patch would not apply cleanly..it compiles but un-tested at runtime. |
Pulls in workaround for TX rate code firmware bug which might as well help track it down via different printk()s and thus possibly provide more clue for proper fix. Firmware currently sends wrong (0xff) TX rate code which causes WARN_ONCE, so the workaround just changes this bogus value (0xff) into 0. For 5.4 it also pulls in tx-queue-wake throttling patch "ath10k: Restart xmit queues below low-water mark", which should improve performance with high number of concurrent TCP streams. Ref: greearb/ath10k-ct#129 Signed-off-by: Petr Štetiar <ynezz@true.cz>
Pulls in workaround for TX rate code firmware bug which might as well help track it down via different printk()s and thus possibly provide more clue for proper fix. Firmware currently sends wrong (0xff) TX rate code which causes WARN_ONCE, so the workaround just changes this bogus value (0xff) into 0. For 5.4 it also pulls in tx-queue-wake throttling patch "ath10k: Restart xmit queues below low-water mark", which should improve performance with high number of concurrent TCP streams. Ref: greearb/ath10k-ct#129 Signed-off-by: Petr Štetiar <ynezz@true.cz>
It seems, that we get a bad tx/rx rate from firmware, it is not a real
problem so just check for invalid rate (0xff) and force it to be zero
instead.
Fixes: #117
Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3055