[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