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 <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
