[rt2x00-users] rt2x00: status update regarding txdone handling

Ivo Van Doorn ivdoorn at gmail.com
Fri Jul 30 01:49:24 AEST 2010


Hi,

> I'm still fighting with the txdone handling in rt2800pci. Sometimes the tx
> queues get stuck. It took me a few days but it seems as if the TX_STA_FIFO
> register limitation to hold max 16 entries is causing this problem.

Weird, for rt2800usb this doesn't seem to be the problem. The queue locks
up even when I continuously read the TX_STA_FIFO register.

> It seems as if either
> 1) interrupts are disabled on the host CPU and thus multiple tx status entries
>   accumulate before they get processed by the host CPU.

Have you checked the DELAY_INT_CFG register?
Seems to control everything for stacking up interrupts.

> Not every tx'ed frame status needs to be reported back to mac80211. There are
> a few frames that need a tx status report, but they are marked with
> IEEE80211_TX_CTL_REQ_TX_STATUS by mac80211. All other frames don't require the
> tx status. But of course the tx status is also used by the rate control
> algorithm.

That flag shouldn't be used by drivers, I had such a check in the past
for rt2x00,
and Johannes asked me to always report the status for all frames. The problem is
also that the status is not only needed for the Rate control, but also
for hostapd,
which wants to know if frames must be retried or not.

> That's why I though about limiting the number of frames that require a tx
> status (including a number of "normal" frames to make the rate control happy)
> to something around 15. Once we are waiting for the tx status of 15 frames
> we won't accept any more frames that require a tx status.
>
> We could mark all frames that require a tx status with a unique identifier
> between 0x1 and 0xf and all others with 0. The non-marked frames would be
> freed from the DMA_DONE interrupt handler, while the marked frames are freed
> once the tx status arrives.
>
> As far as I could see during my tests so far this might be the only way to
> really ensure that no tx status gets lost.

You still will not be able to match frames against the correct TX status,
and although you reduce the chance that no TX status reports are missed
between the raised IRQ and the reading of the STA_FIFO register,
the chance still exists.

Is there perhaps a possibility to trigger the reading of TX status reports
more often? Some other interrupt perhaps which we can listen to?

Ivo




More information about the users mailing list