#11862: ath: Failed to stop TX DMA, queues=0x004
------------------------------+-----------------------------------
Reporter: igor@… | Owner: nbd
Type: defect | Status: assigned
Priority: response-needed | Milestone: Barrier Breaker 14.07
Component: kernel | Version: Trunk
Resolution: | Keywords:
------------------------------+-----------------------------------
Comment (by tatsuya46):
i use ddwrt but this problem is relevant to all fw except stock that
support qualcomm atheros, found some info about it & made it reproduceable
http://svn.dd-wrt.com/ticket/2952#comment:110
http://www.dd-
wrt.com/phpBB2/viewtopic.php?t=171400&postdays=0&postorder=asc&start=285
i found the cause, finally..it was in front of me the whole damn time, its
the 40mhz/fat channel intolerant bit that some clients either force, or
have the option to force it. thats what that setting does, make that
client do ht20 only, BUT also tries to force the entire network on 2.4ghz
to use ht20 as well. its an override, but "wide ht40" only setting, is
also an override, 2 overrides clash & start fighting, somehow the client
wins. i thought of this yesterday when i noticed the macbook online, the
entire network was in ht20 only & had their uptimes reset + tx dma spam
again. i know apple computers never do ht40 on 2.4ghz cause of apple's
decision, but apparently THEY ARE BY DEFAULT FORCING 40mhz/FAT CHANNEL
INTOLERANT. other clients such as the iphone/ipad/ipod touch,
playstation4, wii-u, which are also ht20 only 802.11n devices, do NOT
cause this problem & never did cause they dont force that stupid
intolerant setting
i can now replicate the tx dma spam & dropouts at any given time with 100%
chance & its simple with the correct hardware, in order to reproduce u
need to do the following, with the following radios
*get an AR93xx or newer radio such as those found in the
wndr4300/wndr3700v4 & tl-wdr4900 v1. this is NOT OCCURING ON OLDER AR92xx
found in wndr3700 v1/v2/wndr3800/dir-825 b1/b2. only 1 single failed to
stop tx dma occurs when i do it on these radios, with no drops, but
jittery throughput.
*have another ht40 device connected (to same radio 2.4ghz) @ ht40 rates,
ensure u have wide ht40 ONLY set, NOT dynamic or full ht20. if u dont have
another ht40 device connected, the issue will not occur
*get a test client, best with windows, that has the 40mhz/fat channel
intolerant nic setting, or a client you know that automatically forces it
enabled such as a macbook when used on 2.4ghz
*switch on 40mhz/fat channel intolerant on the client so it disconnects &
reconnects
*observe all other connected ht40 clients should be now forced down to
ht20 until 40mhz/fat channel intolerant is disabled or the client
disconnects, dropouts/tx dma spam should occur now & any throughput
running at the same time will tank to near 0 mbps
*switch off 40mhz/fat channel intolerant on the test client
*reinitialize the radios by applying settings on wifi page or reboot
router
*attempt again
u MUST do it in these steps to reproduce, doing this i can make spam of tx
dma & dropouts happen indefinitely, all day every day with the exact same
queues=0x002! & 0x00a! codes EVERY single time. so the problem is newer
radios cant SMOOTHLY transition from ht40 to ht20 while that client is
connected, or override that stupid 40mhz/fat channel intolerant bit that a
client may connect with. i hope the latter is going to be the fix, how &
why should a single client connecting with an 802.11n OPTIONAL SPEC
setting, 40mhz/fat channel intolerant, override the AP? AP is boss, when
the user selects ht40 ONLY, it should be ht40 ONLY, ht20 clients still
work fine like always, but that 40mhz/fat channel intolerant bit needs to
be properly overridden & not force down the entire network
this has nothing to do with 20/40 coexistence setting nics have, or
protection mode, or any other setting, its solely 40mhz/fat channel
intolerant. on AR93xx+ radios, dont know about QCAxxxx radios or any newer
2.4ghz AR9xxx after AR93xx, dont have them. the SOC AR9344 on
wndr4300/wndr3700v4 is 100% reproduceable, the AR9381 in tl-wdr4900 v1.x
is 100% reproduceable
http://www.dd-
wrt.com/phpBB2/viewtopic.php?t=171400&postdays=0&postorder=asc&start=285
brainslayer can u please investigate this exactly following the steps i
mentioned & using a 2.4ghz radio of similar model? (ur tl-wdr4900 v1 will
do)
========================================================================================
another user, kryptex has stated:
I confirm tatsuya46's findings from Comment 110 above, for WNDR3800 on
r26446 (Wide HT40 setting on the 2.4G network). I connected 2 laptops with
HT40-capable WiFi? cards: Intel 6205 and Atheros AR9285. Under normal
circumstances both connect with HT40.
If I enable the "Fat channel intolerant" setting in the Intel 6205's
driver (up to date, latest v17.14), it immediately forces the entire
network down to HT20 (on both Intel 6205 and Atheros AR9285) and the
network speed suffers really badly, with intermittent
disconnects/reconnects: speeds are down to 1 Mbps instead of the usual
90-95 Mpbs. The network is unusable in this state, it's really awful.
Now we know what "bad client" is: a client with setting <HT40/fat channel
intolerant> enabled. As soon as such a client connects to Atheros-based
routers, it produces intermittent disconnects, laggy connection, TX DMA
errors, and the network becomes very unstable.
It's great to have finally nailed down the cause for the ath9k
dropouts/freezes. With this new information a fix is most probably
straightforward to implement. E.g. when such "bad clients" connect (Apple
products such as Macbooks etc.), the transition from HT40 down to HT20
should be somehow made smooth and stable; or simply just allow the "bad
client" with the HT40 intolerant bit to connect @HT20 and leave the rest
of the network @HT40. The latter solution is arguably the best way to fix
this bug.
========================================================================================
when testing this on the latest version of netgear stock fw for
wndr3700v1, the 2.4ghz network holds ht40 with the "up to 300mbps" dynamic
setting (theres 3 other 2.4ghz networks in this house, with 1 being 2ft
from it), & when connecting my laptop with 40mhz intolerant ENABLED, the
dropouts or lag does not occur, to add to that the network DOES NOT FOLLOW
the 40mhz intolerant setting of my laptop, it completely & seamlessly
OVERRIDES it, using the "up to 300mbps" setting on STOCK FW, thats the
same as dynamic ht20/40..while on ddwrt ht40 ONLY, does not override 40mhz
intolerant + it creates failed to stop tx dma & dropouts
also during this test (that was repeated 3 times), the test laptop with
40mhz intolerant enabled, ITSELF didnt even use ht20 rates, it held with
ht40. with my iphone 6 doing a wlan throughput test throughout the entire
test, its throughput did not drop any more than 1.5mbps for a period of 1
second when the laptop connected. the entire test on stock fw was
completely seamless, completely, seamless & smooth
--
Ticket URL: <https://dev.openwrt.org/ticket/11862#comment:301>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
