Re: 3.7.6+: ath9k: tx logic locks up after taking attenuation very high.

[Ben Greear <greearb@candelatech.com>]

On 02/21/2013 09:34 AM, Ben Greear wrote:
> On 02/20/2013 09:41 PM, Ben Greear wrote:
>> On 02/20/2013 05:38 PM, Sujith Manoharan wrote:
>>> Ben Greear wrote:
>>>> For instance, in this case, why do we have pending frames, the axq-stopped,
>>>> and no axq depth?  Is that an invalid state to begin with?  Once
>>>> it gets in the hung state, those numbers never change.  I'd assume
>>>> something should be poking more packets out of the pending frames
>>>> down into the axq logic?
>>>
>>> Something is broken in the xmit path, definitely.
>>
>> Ok, so here's a question:  In the ath_tx_complete method,
>> the pending_frames counter is only decremented if txq == c->tx.txq_map[q].
>>
>> Maybe it should always be decremented?
>>
>> What kinds of things could cause txq to not equal the txq-map[q]?
>
> I put in debugging code to check for that...and I can still reproduce
> the hang without ever failing the txq == ct->tx.txq_map[q]
> test..so problem is elsewhere it seems...

Ok, I think I see the problem, or at least some of it.

When the attenuation goes very high (signal of -80 or lower),
all transmit basically stops, at least for a bit (possibly while
rate-control algorithms adjust).

During this time, the ath_tx_complete_poll_work logic can hit,
causing a reset of the NIC.

I am seeing at the end of ath_draintxq that axq->pending_frames
reports 53 (in one example).

Shouldn't pending_frames be zero after finishing the ath_draintxq?


I added some logic to force pending_frames to be zero at the end
of that method (and also added some extra logic to reset when I
detect pending_frames type hang, and now my system appears to
recover when attenuation goes back to normal levels....

I'll post my hackings as RFC shortly.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com