Dostaję limity czasu Wi-Fi ze sterownikiem RT2800USB

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.

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:

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.

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)

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.