Daniel Mack <daniel@xxxxxxxxxx> 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? 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. -- Kalle Valo
