Dostaję limity czasu Wi-Fi ze sterownikiem RT2800USB


10

Używam sterownika rt2800usb (z kluczem USB RT5370) i ​​skonfigurowałem Raspberry Pi jako hotspot Wi-Fi z hostapd. Problem polega na tym, że okresowo dostaję limity czasu (patrz przykład). Nie stanowiłoby to problemu, gdybym nie używał mojego RPi jako pilota do quadkoptera. Wydaje się być niezależny od tego, w jaki sposób zasilam moje RPi i dzieje się tak ze wszystkimi kluczami Wi-Fi Ralink tego typu, jakie mam.

Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Zeitüberschreitung der Anforderung.
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64

wyjście dmesg:

[ 2606.960813] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
[ 2606.960897] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
[ 2606.960925] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
[ 2606.961001] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 2606.961052] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 8 in queue 2
[ 2606.961093] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 9 in queue 2
[ 2606.961133] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 10 in queue 2
[ 2606.961174] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
[ 2608.352291] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.352524] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.352766] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.353014] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.353262] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.353511] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Jako ilustrację przygotowałem małą grafikę. Zaimplementowałem własną funkcję ping (ze zmiennymi czasami dla celów testowych) i widzę co ~ 12 s limit czasu (zaznaczony na czerwono małą przerwą). Wierzę, że zwykły użytkownik nie zauważy tych limitów czasu, gdy tylko surfuje po Internecie.

wprowadź opis zdjęcia tutaj


Powiedziałeś, że wydaje się to być niezależne od tego, jak zasilasz pi. Czy to oznacza, że ​​wypróbowałeś wiele różnych zasilaczy?
AwesomeUser

Oznacza to, że próbowałem zasilać bezpośrednio przez RPi i przez hub USB. Wszystko tak samo. Wygląda na to, że jest to błąd hostapd (mało prawdopodobne), rt2800usb lub oprogramowania układowego (rt2870).
dgrat

Czy próbowałeś zasilać pi inaczej?
AwesomeUser

Tak, problem nie jest związany z mocą. Ethernet działa również bez problemów.
dgrat

Odpowiedzi:


7

Wydaje się, że jest to znany problem. Z tego, co znalazłem, możemy tylko:

# disable power management (may need to be done periodically?)
iwconfig wlan0 power off 

i wyłącz szyfrowanie hw (aby to zrobić w oprogramowaniu). Edytuj lub utwórz /etc/modprobe.d/rt2800usb.conf:

options rt2800usb nohwcrypt=1

Nie zapomnij również zaktualizować /lib/firmware/rt2870.bin zgodnie z tym artykułem http://www.raspberrypi.org/forums/viewtopic.php?t=22623 ze strony MediaTek!

Wersje oprogramowania układowego w celach informacyjnych:

md5:36c944c3138125605d28c0a3a1338be9 version 0.29 from Raspian base install
md5:ac4f6d8b679945208a978e397c016aa7 version 0.33 from DPO_RT5572_LinuxSTA_2.6.1.3_20121022 (MediaTek website)

Wersja oprogramowania jest drukowana podczas uruchamiania do dmesg w wierszu zawierającym:
rt2x00lib_request_firmware: Informacje - Wykryto oprogramowanie układowe - wersja:


Ostrzeżenie: podczas wyłączania szyfrowania HW bardziej obciążasz procesor.
martinlbb

dla mojego D-Link oprogramowanie układowe 0.33 wydaje się pomocne. ponieważ w dzisiejszych czasach znalezienie oprogramowania układowego po stronie MediaTek może nie być takie proste, istnieją również inne opcje - jedną z nich jest pobranie fw z github.com/afro-gum/DPO_RT5572_LinuxSTA/blob/master/common/…
ciekawe

0

Po aktualizacji do najnowszego jądra spędziłem 4 godziny, nie dotykając prawie tyle błędów. Służy rpi-updatedo aktualizacji jądra.

Dla porównania moje uname -ato:

Linux boat-pi 3.12.28+ #713 PREEMPT Fri Sep 19 16:43:32 BST 2014 armv6l GNU/Linux

Nadal rt2800usb_entry_txstatus_timeoutczasami pojawia się błąd, ale kiedyś wypełniał mój plik dmesg. Nie dostaję już Got TX status for an empty queuebłędów.

Aktualizacja:

Mówiłem za wcześnie. Moja pi była znacznie lepsza przez 7 godzin, a potem znowu zaczęła się powódź błędów. Nie byłem w stanie dowiedzieć się, co powoduje powodzie błędu. Wygląda na to, że problem nie ogranicza się do Raspberry Pi (także na OpenWRT , Fedora , Kernel.org ). Wygląda na to, że niektóre osoby zgłaszają, że przez pewien czas wszystko jest normalne, zanim pojawią się błędy.


0

Zaktualizowałem jądro (z Linux alarmpi 3.12.26-2-ARCH na Linux alarmpi 3.12.28-2-ARCH) dziś rano i od tego czasu mój dziennik został wypełniony

rt2800usb_entry_txstatus_timeout: Ostrzeżenie - limit czasu statusu TX dla pozycji 6 w kolejce 2

Może nie być czystą poprawką, ale obniżenie jądra do poprzedniej wersji sprawiło, że wszystko znowu działa (ponad 7 godzin później)


0

Używam malinowego b +, Linux 3.12.32+, z Wipi WiFi-dongle. Pi znajduje się w przedwzmacniaczu audio z kluczem Wi-Fi podłączonym z zewnątrz za pomocą przedłużacza USB (montowany na panelu typu A). Bardzo ważne jest, aby uziemienie kabla USB było solidnie podłączone do obudowy przedwzmacniacza. W przeciwnym razie otrzymamy dokładnie komunikaty o błędach, jak pokazano w pytaniu. Nie zauważyłem żadnej poprawy tego w nowszych wersjach rasbian lub zaktualizowanych wersjach rt2870.bin (testowane v0.36). Tak więc w niektórych środowiskach komunikaty o błędach dmesg mogą być spowodowane zanieczyszczeniem radiowym w pobliżu urządzenia radiowego wifi (silniki generują częstotliwości, które mogą zakłócać urządzenia radiowe). Spróbuj zmaksymalizować odległość między radiem a zakłóceniami i / lub poprawić osłonę radia.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.