1

Temat: Failed to stop TX DMA, queues=0x002

W logach routera TL-WR841N V9 pojawiają się wpisy
Failed to stop TX DMA, queues=0x002
Prawdopodobnie w wyniku próby podłączenia jakiegoś telefonu lub tabletu który sprawia problemy.
Radio pracuje niestabilnie, są duże wahania prędkości PHY na wykresie.
Wersja firmware    OpenWrt Barrier Breaker 14.07 / LuCI 0.12 Branch (0.12+git-14.328.38210-ea67bd1)
Wersja jądra    3.10.49
Czy to jakiś znany bug w sterowniku ath9k ?

2

Odp: Failed to stop TX DMA, queues=0x002

Zaktualizuj wersję do CC lub trunka, przecież masz wersję sprzed dinozaurów.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

3

Odp: Failed to stop TX DMA, queues=0x002

kermu napisał/a:

W logach routera TL-WR841N V9 pojawiają się wpisy
Failed to stop TX DMA, queues=0x002
Prawdopodobnie w wyniku próby podłączenia jakiegoś telefonu lub tabletu który sprawia problemy.
Radio pracuje niestabilnie, są duże wahania prędkości PHY na wykresie.
Wersja firmware    OpenWrt Barrier Breaker 14.07 / LuCI 0.12 Branch (0.12+git-14.328.38210-ea67bd1)
Wersja jądra    3.10.49
Czy to jakiś znany bug w sterowniku ath9k ?

W tym routerze siedzi QCA953x, który w miarę stabilne wsparcie w kernelu/ath9k dostał dopiero w wersji CC.

4

Odp: Failed to stop TX DMA, queues=0x002

Dziękuję za info
tutaj
https://dev.openwrt.org/ticket/11862
jest szerzej opisany problem.
Problem dla mnie jest taki że CC zajmuje więcej miejsca
i będę musiał zrezygnować z niektórych, przydatnych dodatkowych pakietów.

5

Odp: Failed to stop TX DMA, queues=0x002

To coś pojawia się od początku istnienia ath9k, ale stanowczo mniej w aktualnych wydaniach. I tak, wygląda na to że zależy w jakiś sposób od środowiska. Nowsze wersje sterowników lepiej sobie radzą z tym problemem, choć też nadal się czasami pojawia.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

6 (edytowany przez kermu 2016-05-18 20:46:10)

Odp: Failed to stop TX DMA, queues=0x002

Teorie moje są dwie
1. Duże zaszumienie , w związku z czym duża liczba retransmisji w warstwie PHY.
2. Któreś z urządzeń klienckich nie współpracuje prawidłowo z radiem.
Zauważyłem że problem zaczął się pojawiać od wczoraj u klienta u którego zalogowanych
jest 5-6 urządzeń do AP.
Finalnie router okresowo dostaje duży load i są straty pakietów 5-6 % które powodują że wadliwie działa usługi IPTV.
Po kilku sekundach problem ustępuje by powrócić po jakimś czasie.
Teoria z zaszumieniem znajduje o tyle uzasadnienie że przy próbach zmian kanału na niektórych kanałach
problem wydawał się nie występować (testowałem ping -i 0.1 <IP routera>)
Wyłączenia radia na 100% rozwiązywało problem.
Ten firmware mam aktualnie w większości routerów u klientów i do tej pory był chyba tylko jeden incydentalny przypadek. Ten jest drugi w którym jest wyjątkowo dużo zalogowanych urzadzeń do AP.

7

Odp: Failed to stop TX DMA, queues=0x002

Czy openwrt korzysta z finkcji ANI (patent Atheros-a)
dla drivera ar71xx ?
https://wiki.freebsd.org/dev/ath_hal%28 … seImmunity
https://forum.openwrt.org/viewtopic.php?id=46703
Jeśli tak, czy można to wyłączyć ?

8

Odp: Failed to stop TX DMA, queues=0x002

cat /sys/kernel/debug/ieee80211/phy0/ath9k/ani
            ANI: ENABLED
      ANI RESET: 59
     OFDM LEVEL: 6
      CCK LEVEL: 0
        SPUR UP: 4346
      SPUR DOWN: 4346
OFDM WS-DET ON: 0
OFDM WS-DET OFF: 0
     MRC-CCK ON: 1285
    MRC-CCK OFF: 1285
    FIR-STEP UP: 4104
  FIR-STEP DOWN: 4079
INV LISTENTIME: 0
    OFDM ERRORS: 141711495
     CCK ERRORS: 4287140

echo 0 >/sys/kernel/debug/ieee80211/phy0/ath9k/ani
root@ro:/sys/kernel/debug/ieee80211/phy0/ath9k# cat /sys/kernel/debug/ieee80211/phy0/ath9k/ani
            ANI: DISABLED

9

Odp: Failed to stop TX DMA, queues=0x002

ANI wyłączało się za czasów AA i BB. W CC nie polecają tego, gdzieś na forum openwrt.org było to opisywane. Choć jak chcesz to wyłączyć możesz.

Masz niepotrzebny router, uszkodzony czy nie - chętnie przygarnę go.

10 (edytowany przez kermu 2016-05-18 21:51:55)

Odp: Failed to stop TX DMA, queues=0x002

Z praktyki radiowca wiem że nie działa to dobrze.
Pomysł teoretycznie może i jest dobry jednak w praktyce czułośc toru odbiorczego
w obecności zakłóceń jest tak obniżana że radio w AP przestaje słyszeć klientów
o słabszym sygnale i pojawiają się retransmisje lub disconnecty,
dlatego ja zawsze wyłaczam ten "feature" na stacjach bazowych
poza tym obciążą on dość mocno CPU co może być właśnie powodem
lagów w routerze jak pojawiają się zakłócenia w eterze.
Na tą chwilę wyłączyłem, zobaczę czy pomoże.
Być może w CC pojawiła się jakaś sensowna implementacja tego.