Kalle Valo wrote:
> This reverts commit 9ed4f91628737c820af6a1815b65bc06bd31518f.
>
> The commit introduced a regression that over read the ie with
> the padding.
>
> - the expected IE information
>
> ath10k_pci :03:00.0: found firmware features ie (1 B)
> ath10k_pci :03:00.0: Enabling
Update to this issue, I can reliably reproduce a crash by using a
USB-Ethernet adapter.
Setup is: (c1) [ iperf client -> ethernet ] -> (AP) [ usb-ethernet
(wan) -> wifi (lan) ] > (c2) [wifi -> iperf server]
This will bring down the module on the AP almost instantaneously.
___
hi,
do you have firmware source at the current gig? or access to the pktlog tools?
Have you verified that the frames weren't at all indicated up via HTT?
Like are they absolutely NOT coming up via HTT, or are they coming up
via HTT but being thrown out before the driver is ready to pass them
up.
From: Ryan Hsu
QCA9377 firmware update the IRAM banks from 4 to 9.
Signed-off-by: Ryan Hsu
---
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 355db6a.
Hi Adrian,
We do not have access to firmware source, nor to any other QCA proprietary
tools at this time.
The logs were collected by enabling ATH10K_DBG_DATA in debug_mask.
AFICT, those messages are generated inside ath10k_htt_rx_h_deliver(), and the
only place where the frames could be dropped
Hi,
Yeah, it's possible it's being dropped in the HTT notification path -
the hardware afaik is doing the ACKing there.
I think pktlog is the primary way I'd try to debug this but yeah,
there's no open pktlog tool iirc for even just looking at the packet
data..
-adrian
___
