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.
raspbian
networking
wireless
dgrat
źródło
źródło
Odpowiedzi:
Wydaje się, że jest to znany problem. Z tego, co znalazłem, możemy tylko:
i wyłącz szyfrowanie hw (aby to zrobić w oprogramowaniu). Edytuj lub utwórz /etc/modprobe.d/rt2800usb.conf:
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:
Wersja oprogramowania jest drukowana podczas uruchamiania do dmesg w wierszu zawierającym:
rt2x00lib_request_firmware: Informacje - Wykryto oprogramowanie układowe - wersja:
źródło
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: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.
źródło
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)
źródło
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.
źródło