>Number: 165895 >Category: kern >Synopsis: [ath] overly busy cabq can tie up all tx buffers >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 10 01:50:01 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: FreeBSD-HEAD >Organization: >Environment: -MIPS, AR9130 AP (TP-WR1043nd) >Description: In a congested air environment with a very busy broadcast traffic LAN (in my instance, a _lot_ of IPv4 ARP and IPv6 ND frames) the CABQ can fill up with traffic and tie up all the tx buffers.
This stops things such as management traffic (ie, probe response/authentication frames) from successfully transmitting. >How-To-Repeat: * AR9130 AP * _VERY_ busy 2.4GHz environment * configure in HT/40 mode * inject a lot of broadcast traffic sysctl dev.ath.0.txagg will show the CABQ (queue 8) will be constantly filled with traffic. >Fix: In the short term, we should just limit the amount of data going into the multicast queue. This includes power save traffic, so we need to be careful. In the longer term, when we decouple ath_buf TX from actual software TX queues, we may wish to buffer some frames in the avp->av_mcastq before we assign them a hardware TX ath_buf + descriptor. We still will have a problem with traffic filling up. There may be a radio configuration issue causing it to think the air is overly congested. I'll investigate that in a separate PR. >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
