[ath9k-devel] Warning in ath_rc_get_highest_rix()

[Pavel Roskin <proski@gnu.org>]

On Wed, 4 Jan 2012 17:46:45 -0500
Pavel Roskin <proski@gnu.org> wrote:

> I hit this bug on a freshly installed Fedora 16 and judging by the
> duplicate bugs it looks like many Fedora users are hitting it too:
> https://bugzilla.redhat.com/show_bug.cgi?id=771113

Some detailed information has been posted in the bug.

That's the variables printed before WARN_ON():

legacy = 0
minindex = 0
maxindex = 9
ath_rc_priv->probe_time = 34481809
now_msec = 54187647
best_thruput = -939514064
this_thruput = 264
rate = 11
next_rate = 0
best_rate = 11
rate_table->info[rate].rate_flags = 0x0
ath_rc_priv->ht_cap = 0x0
ath_rc_priv->rate_table_size = 12
ath_rc_priv->hw_maxretry_pktcnt = 0
ath_rc_priv->rate_max_phy = 11

There are 3 conditions when the rate is returned.  If neither
condition is true, WARN_ON() is hit and the lowest rate is returned.

The first two conditions require that ath_rc_priv->ht_cap is not 0, so
they don't apply.

The last condition requires that rate_table->info[rate].rate_flags is
not 0, so it doesn't apply either.

I think rate_table->info[rate].rate_flags should not be 0.  rate is 11,
which is reasonable.

Rate flags 0 corresponds to RC_INVALID.  I'm not sure how we can get it
with the rate 11.

Also, best_thruput should not be negative.  Its value in hex is
0xc8002730.  That looks like an address to me.  Or maybe there
was an overflow in this_thruput calculation.  But even the worst case
scenario would be 450000 * 100 = 45000000, well below largest integer.
Or maybe ath_rc_priv->per[tx_rate] was negative?

I'll appreciate is somebody could take a closer look and maybe suggest
a patch that would clarify the problem.  I cannot reproduce the problem
anymore, so we have to rely on the bug reporters who can.

-- 
Regards,
Pavel Roskin