Search Linux Wireless

Re: [PATCH 00/10] Some more patches for wcn36xx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday, May 16, 2018 04:08 PM, Daniel Mack wrote:
Hence I believe that some sort of firmware internal buffer is overrun if
too many SMD requests fly in in a short amount of time. The firmware
does, however, still ack all packets just fine on the SMD channels, and
also the DXE communication flows are all healthy. No errors are reported
anywhere, but nothing is being put on the ether anymore.

And FTR, there is a commit in the prima repository that caught my attention a while back:

  https://source.codeaurora.org/external/wlan/prima/commit/?id=93cd8f3c

What this does (through an remarkable number of indirection layers) is sending the DUMP_COMMAND_REQ command with args = (274, 0, 0, 0, 0) when management frames get stuck, which smells pretty much like the issue I'm seeing. Doing the same with the mainline driver and the debugfs interface it exposes doesn't have any effect though.

But even if it did work, I wouldn't see a way to detect the situation in which this is needed reliably.


Daniel



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux