Re: Problem with 9984 in routed mode with 512b frames.

[Ben Greear <greearb@candelatech.com>]

On 5/15/19 5:26 AM, Sebastian Gottschall wrote:
> 
> Am 15.05.2019 um 14:20 schrieb Ben Greear:
>> On 05/14/2019 09:26 PM, Sebastian Gottschall wrote:
>>> can you send me a detailed instruction for testing this on my devices? so which commands have been used for generating the traffic etc. (iperf3?)
>>
>> I am using our own traffic generator, but I imagine iperf3 should work fine too.
>>
>> I am testing on x86-64 and so forth.  Maybe you can test with UDP small-packet load on your platform
>> in routed mode (ie, external iperf generator through your AP) and see if you see issues?
> thats the plan. can you do a test with iperf3 to see if its reproduceable. i mean i will test it on ipq based boards and x64. but to make sure that the scenario
> is identical which raised up your issue, it would be find if we have identical software for testing including the same options

One of our other engineers will try to reproduce it on a different system today.

And in case you are sniffing during your own testing, I'd be curious if you see
any AMSDU frames?  I only see AMPDUS full of single-packet frames.  I would expect
several of the 512b frames to be put into AMSDU sub-frames.  I plan to look into that
after I figure out the tx stall issue.

Thanks,
Ben

>>
>> From debugging yesterday, I see a lot of tx-hang notifications in the firmware, and
>> I also believe I saw it trying to transmit with a 0 rate-indx, which is 11Mbps CCK,
>> which is invalid for 5Ghz.  I'll be debugging that more today.  I don't know if stock
>> firmware fails for the same reasons, but the symptom looked the same.
> could be a buffer overflow/locking due a udp flooding. so a missing check to drop packets which are out of limit or a too restrictive buffer management.
> like static frame buffers of max mtu size, but its just used partially by frame due the small size of the udp packets. you may know it better since you have 
> much better
> knowledge about the firmware internals.
>>
>> Thanks,
>> Ben
>>
>>>
>>> Sebastian
>>>
>>> Am 15.05.2019 um 03:52 schrieb Ben Greear:
>>>> Hello,
>>>>
>>>> I found a strange issue and curious if someone has seen similar.
>>>>
>>>> I made an AP where the AP interface acts as a routed interface.  I generate
>>>> traffic through another interface in the router.  When sending 300Mbps of 512 byte
>>>> UDP payloads, in the downstream direction, and with the station being a 1x1 /AC device,
>>>> then the AP NIC appears to mostly lock up within about 1 minute. I still see beacons, but no
>>>> data frames.  In some cases, I reproduced with very slow speed traffic as well.
>>>>
>>>> I tried using a mostly un-modified firmware (ie, similar to upstream QCA), as well as my
>>>> hacked upon firmware, and all act similarly.  I'm using the 4.20 kernel, but at least for now,
>>>> it does not appear to be a kernel issue.
>>>>
>>>> If I use larger MTU sized frames, or have a 2x2 station instead of 1x1 then it is much harder
>>>> to reproduce (and maybe cannot be reproduced).  Also, when generating traffic directly on
>>>> the AP device instead of using the routed interface as a traffic source, it is harder to
>>>> reproduce.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>
>>
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k