Search Linux Wireless

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

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

 



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



[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