10

I use the rt2800usb driver (with a RT5370 USB dongle) and configurated my Raspberry Pi as a WiFi hotspot with hostapd. The problem is, that I get periodically timeouts (see example). This wouldn't be a problem if I wouldn't use my RPi as a remote control for a quadcopter. It seems to be independent on how I power my RPi and it happens with all Ralink wifi dongles of this type I have.

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

dmesg output:

[ 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

I prepared a small graphic as illustration. I implemented my own ping function (with variable timings for testing reasons) and see every ~12s a timeout (indicated in red by a small gap). I believe the normal user will not notice these timeouts, when just surfing in the internet.

enter image description here

4
  • You said it seems to be independent on how you power the pi. Does that mean you have tried multiple different power supplies? Commented Apr 14, 2014 at 1:03
  • It means I tried to power directly by the RPi and via USB-Hub. Everything the same. It seems to be either a bug of hostapd (unlikely), rt2800usb or of the firmware (rt2870).
    – dgrat
    Commented Apr 14, 2014 at 9:18
  • Have you tried powering the pi differently? Commented Apr 14, 2014 at 12:42
  • Yep, the problem is not power related. Ethernet is also working without problems.
    – dgrat
    Commented Apr 14, 2014 at 17:13

4 Answers 4

7

It seems to be a known problem. From what I've found, all we can do is:

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

and disable hw encryption (so it will be done in the software). Edit or create /etc/modprobe.d/rt2800usb.conf :

options rt2800usb nohwcrypt=1

Also don't forget to update /lib/firmware/rt2870.bin according to this article http://www.raspberrypi.org/forums/viewtopic.php?t=22623 from MediaTek website!

Firmware versions for your reference:

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)

Firmware version is printed on bootup to dmesg in the line containing:
rt2x00lib_request_firmware: Info - Firmware detected - version:

2
  • Warning, when disabling HW encryption, you stress more your CPU.
    – martinlbb
    Commented Jan 12, 2015 at 13:21
  • for my D-Link the 0.33 firmware seems helpful. as it may be not that easy to find the firmware on the MediaTek side these days, there are also other options - one is to get the fw from github.com/afro-gum/DPO_RT5572_LinuxSTA/blob/master/common/…
    – ciekawy
    Commented May 3, 2017 at 0:44
0

After updating to the latest kernel, I've gone 4 hours without hitting nearly as many of these errors. Use rpi-update to update your kernel.

For reference, my uname -a is:

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

I still get rt2800usb_entry_txstatus_timeout error occasionally, but it used to fill my dmesg. I no longer get the Got TX status for an empty queue errors.

Update:

Spoke too soon. My pi was much better for 7 hours then started getting a flood of errors again. Haven't been able to figure out what triggers the error floods. Looks like the issue isn't confined to Raspberry Pi (also on OpenWRT, Fedora, Kernel.org). Seems like some people are reporting that everything is normal for a certain amount of time before the errors kick in.

0
0

I updated the kernel (from Linux alarmpi 3.12.26-2-ARCH to Linux alarmpi 3.12.28-2-ARCH) this morning and since got my journal filled with

rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2

May not be a clean fix, but downgrading the kernel to its previous version made things work again (more than 7 hours later)

0

I'm using a raspberry b+, linux 3.12.32+, with wipi wifi-dongle. The pi is inside an audio pre-amplifier, with the wifi-dongle connected from the outside through an extension usb-cord (panel mounted type A). It's critical that the usb-cord ground is firmly connected to the chassis of the pre-amp. Otherwise, we get exactly the error messages as shown in the question. Have not seen any improvement on this with newer rasbian or updated versions of rt2870.bin (tested v0.36). So, in some environments, the dmesg error messages can be due to radio pollution in the close proximity of the wifi radio device (motors generate frequencies that can disturb radio devices). Try to maximize the distance between the radio and the disturbance and/or improve radio shield.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.