J'obtiens des délais d'attente WiFi avec le pilote rt2800usb


10

J'utilise le pilote rt2800usb (avec un dongle USB RT5370) et j'ai configuré mon Raspberry Pi comme hotspot WiFi avec hostapd. Le problème est que j'obtiens périodiquement des délais d'attente (voir l'exemple). Ce ne serait pas un problème si je n'utilisais pas mon RPi comme télécommande pour un quadcopter. Il semble être indépendant de la façon dont j'alimente mon RPi et cela se produit avec tous les dongles wifi Ralink de ce type que j'ai.

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

sortie 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

J'ai préparé un petit graphique comme illustration. J'ai implémenté ma propre fonction ping (avec des temps variables pour des raisons de test) et je vois tous les ~ 12s un timeout (indiqué en rouge par un petit espace). Je crois que l'utilisateur normal ne remarquera pas ces délais d'attente lorsqu'il surfera simplement sur Internet.

entrez la description de l'image ici


Vous avez dit qu'il semble être indépendant de la façon dont vous alimentez le pi. Cela signifie-t-il que vous avez essayé plusieurs alimentations différentes?
AwesomeUser

Cela signifie que j'ai essayé d'alimenter directement par le RPi et via USB-Hub. Tout de même. Il semble que ce soit un bogue de hostapd (peu probable), rt2800usb ou du firmware (rt2870).
dgrat

Avez-vous essayé d'alimenter le pi différemment?
AwesomeUser

Oui, le problème n'est pas lié à l'alimentation. Ethernet fonctionne également sans problème.
dgrat

Réponses:


7

Cela semble être un problème connu. D'après ce que j'ai trouvé, tout ce que nous pouvons faire est:

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

et désactiver le cryptage hw (ce sera donc fait dans le logiciel). Modifiez ou créez /etc/modprobe.d/rt2800usb.conf:

options rt2800usb nohwcrypt=1

N'oubliez pas non plus de mettre à jour /lib/firmware/rt2870.bin conformément à cet article http://www.raspberrypi.org/forums/viewtopic.php?t=22623 du site Web de MediaTek!

Versions du micrologiciel pour votre référence:

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)

La version du firmware est imprimée au démarrage vers dmesg dans la ligne contenant:
rt2x00lib_request_firmware: Info - Firmware détecté - version:


Attention, lorsque vous désactivez le cryptage HW, vous mettez davantage l'accent sur votre CPU.
martinlbb

pour mon D-Link, le firmware 0.33 semble utile. comme il n'est peut-être pas si facile de trouver le firmware du côté MediaTek ces jours-ci, il existe également d'autres options - l'une consiste à obtenir le micrologiciel sur github.com/afro-gum/DPO_RT5572_LinuxSTA/blob/master/common/…
ciekawy

0

Après la mise à jour vers le dernier noyau, j'ai passé 4 heures sans rencontrer autant de ces erreurs. Utilisez rpi-updatepour mettre à jour votre noyau.

Pour référence, mon uname -aest:

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

J'obtiens toujours des rt2800usb_entry_txstatus_timeouterreurs de temps en temps, mais cela remplissait mon dmesg. Je ne reçois plus les Got TX status for an empty queueerreurs.

Mettre à jour:

Parlé trop tôt. Ma pi était bien meilleure pendant 7 heures, puis a recommencé à recevoir un flot d'erreurs. N'ont pas été en mesure de comprendre ce qui déclenche les inondations d'erreur. Il semble que le problème ne se limite pas à Raspberry Pi (également sur OpenWRT , Fedora , Kernel.org ). Il semble que certaines personnes signalent que tout est normal pendant un certain temps avant que les erreurs ne se déclenchent.


0

J'ai mis à jour le noyau (de Linux alarmpi 3.12.26-2-ARCH à Linux alarmpi 3.12.28-2-ARCH) ce matin et depuis j'ai rempli mon journal avec

rt2800usb_entry_txstatus_timeout: Avertissement - Délai d'expiration de l'état TX pour l'entrée 6 dans la file d'attente 2

Ce n'est peut-être pas un correctif, mais la rétrogradation du noyau vers sa version précédente a fait fonctionner à nouveau (plus de 7 heures plus tard)


0

J'utilise un raspberry b +, linux 3.12.32+, avec un dongle wifi wipi. Le pi est à l'intérieur d'un préamplificateur audio, avec le dongle wifi connecté de l'extérieur via une rallonge USB (montée sur panneau type A). Il est essentiel que la masse du cordon USB soit fermement connectée au châssis du préampli. Sinon, nous obtenons exactement les messages d'erreur comme indiqué dans la question. Je n'ai vu aucune amélioration à ce sujet avec les versions plus récentes de rasbian ou mises à jour de rt2870.bin (testé v0.36). Ainsi, dans certains environnements, les messages d'erreur dmesg peuvent être dus à la pollution radio à proximité immédiate de l'appareil radio wifi (les moteurs génèrent des fréquences pouvant perturber les appareils radio). Essayez de maximiser la distance entre la radio et la perturbation et / ou d'améliorer le blindage radio.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.