This routine is failing a lot on my AR9160. The ((reg & 0x7E7FFFEF) ==
0x00702400) test is the one that always fails. There is no debug
messages in this path, so it may not be obvious whether others are
experiencing the problem.
This forces ath9k_tasklet to reset the hardware. If I increase the
count to 500, I can eliminate most of the resets, so the hardware
isn't really hung. However, it sometimes takes over 25 milliseconds
before the test condition passes.
I don't have specs for the radio, and the numeric constants aren't
very useful, so I can't tell what condition we are waiting for or why.
Can someone with a spec shed some light on this problem?
bool ath9k_hw_check_alive(struct ath_hw *ah)
{
int count = 50;
u32 reg;
if (AR_SREV_9285_10_OR_LATER(ah))
return true;
do {
reg = REG_READ(ah, AR_OBS_BUS_1);
if ((reg & 0x7E7FFFEF) == 0x00702400)
continue;
switch (reg & 0x7E000B00) {
case 0x1E000000:
case 0x52000B00:
case 0x18000B00:
continue;
default:
return true;
}
} while (count-- > 0);
return false;
}
Thanks,
Bill Jordan
On Mon, Jan 10, 2011 at 7:26 PM, Felix Fietkau <[email protected]> wrote:
> On 2011-01-10 1:23 PM, Bill Jordan wrote:
>>
>> This routine is failing a lot on my AR9160. The ((reg& ?0x7E7FFFEF) ==
>> 0x00702400) test is the one that always fails. There is no debug
>> messages in this path, so it may not be obvious whether others are
>> experiencing the problem.
>>
>> This forces ath9k_tasklet to reset the hardware. If I increase the
>> count to 500, I can eliminate most of the resets, so the hardware
>> isn't really hung. However, it sometimes takes over 25 milliseconds
>> before the test condition passes.
>>
>> I don't have specs for the radio, and the numeric constants aren't
>> very useful, so I can't tell what condition we are waiting for or why.
>>
>> Can someone with a spec shed some light on this problem?
>
> I just posted a 4-patch series, the last patch of that should take care of
> this problem. Please test.
>
> - Felix
>
I tried your patch. It improved the situation, but it still reset
every couple minutes. It also seems to reset a few times in quick
succession every time it resets. What is the routine testing for? Is
this a test for a stuck transmitter? I'm in a very noisy environment,
and it could take a while to transmit.
Bill Jordan
On 2011-01-10 1:23 PM, Bill Jordan wrote:
> This routine is failing a lot on my AR9160. The ((reg& 0x7E7FFFEF) ==
> 0x00702400) test is the one that always fails. There is no debug
> messages in this path, so it may not be obvious whether others are
> experiencing the problem.
>
> This forces ath9k_tasklet to reset the hardware. If I increase the
> count to 500, I can eliminate most of the resets, so the hardware
> isn't really hung. However, it sometimes takes over 25 milliseconds
> before the test condition passes.
>
> I don't have specs for the radio, and the numeric constants aren't
> very useful, so I can't tell what condition we are waiting for or why.
>
> Can someone with a spec shed some light on this problem?
I just posted a 4-patch series, the last patch of that should take care
of this problem. Please test.
- Felix