[rt2x00-users] rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out

Helmut Schaa helmut.schaa at googlemail.com
Tue Nov 30 21:31:21 UTC 2010


Hi,

Am Dienstag 30 November 2010 schrieb Johannes Stezenbach:
> > > So, it looks like the packet was queued inside the device, but
> > > TX happens after the URB was completed and thus the
> > > TX_STA_FIFO entry only appears later.  If this is normal
> > > device operation then we shouldn't wait for a 1 sec timeout?
> > > Or is there another explanation for this?
> > 
> > I have tried increasing the timeout in the past, and it didn't
> > help.
> 
> I meant to decrease it to a few milliseconds -- the time it usually
> takes to send a frame.  If the hardware/firmware works like it looks
> (complete the URB now, but send the packet later)

Yes, that is how it works on PCI as well but we've got an interrupt there
when the frame is really sent out. USB is lacking such a functionality.

> then it's not a
> "timeout", it is "wait until frame is sent and then read TX_STA_FIFO".

Why not try again to read TX_STA_FIFO again when the watchdog triggers?

> However, I don't know if it is time critical to call ieee80211_tx_status()
> ASAP, maybe there is no downside to wait 1 second?

I'm not sure about all the timeouts but for example injected EAPOL frames
(from hostapd) require a tx status before hostapd times out but I guess the
timeout in hostapd for that should be > 1 second. Not sure though.

Other then that and a few other cases the tx status is only used by the 
rate control algorithm and to send frames to monitor mode interfaces.

> "Watchdog" and "warning" sound like this is an unexpected event
> or a malfunction, but if this is a normal event then the
> message can be removed,  Agreed?
> 
> BTW, I was using channel 1 and there are maybe half a dozen APs
> in neighbouring office rooms on that channel, so maybe the packet
> was delayed because the channel was busy.

I doubt that. I don't think a frame should be delayed for such a long time
and even if the channel is busy. In that case the frame should get reported
as failed within time, no?

Helmut



More information about the users mailing list