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

Ivo Van Doorn ivdoorn at gmail.com
Fri Jul 30 02:21:06 AEST 2010

On Thu, Jul 29, 2010 at 6:09 PM, Helmut Schaa
<helmut.schaa at googlemail.com> wrote:
> Am Donnerstag 29 Juli 2010 schrieb Ivo Van Doorn:
>> 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.
> Yeah, I didn't do that much tests regarding the DELAY_INT_CFG but afaik this
> should only affect DMA_DONE interrupts. Maybe I find some time to play with
> that as well ...

The documentation doesn't specify it is only for DMA, it talks about
interrupts in general.
It also states that we should listen to the INT_SOURCE_CSR_TXDELAYINT/
INT_SOURCE_CSR_RXDELAYINT interrupts to know if the delayed interrupt has
been triggered.

>> > 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.
> Ok :(
>> 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.
> Yeah, but these frames are injected and thus marked with
>> > 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?
> Hmm, we could of course check the STA_FIFO register during each interrupt
> invocation, including DMA_DONE etc.
> Not sure, but I'll give it a shot.



More information about the users mailing list