Hi Kalle,
On Friday, May 18, 2018 01:28 PM, Kalle Valo wrote:
Daniel Mack <dan...@zonque.org> writes:
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.
The firmware version might make a difference so I recommend always
mentioning the firmware version as well. For example, what if your
firmware does not support that command or parameter?
Sure, that could be the case. FTR - the firmware I'm using is the one
that came out of the Qualcomm r1034.2.1 BSP. It is recognized by the
driver as 'WCN v2.0 RadioPhy vRhea_GF_1.12 with 19.2MHz XO'.
Also I would recommend to file a bug to bugzilla.kernel.org so that all
the information is one place and it can be easily updated. Now it's
pretty difficult to get the big picture from various emails on the list.
Yes, I agree it's a bit convoluted. However, there's already the bug
report on 96board.org that Bjorn opened some time back, and I considered
that sufficient. IMO, it has all the information needed, plus a link to
a tool to reproduce the issue.
https://bugs.96boards.org/show_bug.cgi?id=538
The patches in this series can be considered as general cleanups that
are not necessarily related to this particular issue.
Thanks,
Daniel
