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

Helmut Schaa helmut.schaa at googlemail.com
Fri Jul 30 02:09:29 AEST 2010

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 ...

> > 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