[rt2x00-users] [RFC/RFT] rt2x00: Fix rt2800usb TX status report matching to a TX queue entry.

Andreas Hartmann andihartmann at 01019freenet.de
Tue Mar 6 17:45:54 EST 2012


Hi Gertjan, hi Stanislaw

Gertjan van Wingerde schrieb:
> Hi Stanislaw,
> 
> 
> On 5 mrt. 2012, at 17:44, Stanislaw Gruszka <sgruszka at redhat.com>
> wrote:
> 
>> On Wed, Feb 22, 2012 at 04:25:21PM +0100, Helmut Schaa wrote:
>>> On Wed, Feb 22, 2012 at 3:19 PM, Stanislaw Gruszka
>>> <sgruszka at redhat.com> wrote:
>>>> Not sure even if that possible, maybe will be better to do not
>>>> relay on TX_STA_FIFO, but on some other statistic registers. 
>>>> Not sure. I plan to work on that.
>>> 
>>> If we don't do accurate TX status reporting anymore we'd have to
>>> implement our own rc algo as well. And from what I know bout the
>>> PCI versions it should be possible to get the TX status reporting
>>> right ...
>>> 
>>> However, if you start debugging, it might make sense to start
>>> without BA sessions.
>> 
>> Mostly we receive all tx statuses, but sometimes not. I would tell
>> that we can rely on them (mostly).
>> 
>> I found reason of the stalls, it is race condition when
>> pausing/unpausing tx queue. Looks like Gertjan patch make tx
>> faster, what make that race condition better reproducible. I'll
>> post fix shortly.
> 
> Good work. Most probably that would fix other occurrences as well,
> like the stalls that Andreas Hartmann found in RT3572 even without my
> patch applied.

I'm really not proud of being a spoilsport and I have to apologize, but
this patch doesn't fix anything for me. The behaviour is unchanged with
single and multi core processors. I even got a stall after few minutes
with best radio conditions with single core cpu.
I tested on top of the source I already used for testing the fix
mentioned in the subject of this thread. Or should I use some other code
base?


Kind regards,
Andreas



More information about the users mailing list