On Wed, 2016-01-27 at 21:34 -0800, Linus Torvalds wrote:

.. except now I upgraded the nearest access point, and now wireless
on that machine no longer works.

Can you describe the upgrade a bit more, just for background?

Or rather, it actually *does* work in the sense that it
authenticates, it associates, and it actually gets a DHCP lease etc.
So the darn thing has an IP address and everything, but then nothing
else seems to go through after that. Very odd. My guess is that the
auth/assoc/dhcp thign happens at low rates, then it starts trying to
up the rates, and things go to hell.

That's usually the case, yes. Auth/assoc/etc. management frames use low
rates anyway, and the first few data frames usually also do until it
scales up.

The code involved is drivers/net/wireless/realtek/rtlwifi/rc.c

I do note that that rate_fixup_ratelist() function is a bit odd wrt
those rate indexes: it has code to make sure that there are no valid
rates following an invalid one:

                /*
                 * make sure there's no valid rate following
                 * an invalid one, just in case drivers don't
                 * take the API seriously to stop at -1.
                 */
                if (inval) {
                        rates[i].idx = -1;
                        continue;
                }
                if (rates[i].idx < 0) {
                        inval = true;
                        continue;
                }

but then that "RC is busted" case that generates a warning will add
one of those invalid rates in the middle anyway. So I get the feeling
that if that warning ever triggers, it will basically be screwing up
that whole rate table. I dunno.

This should be OK, it's more of a sanity check. The driver is supposed
to stop transmission attempts at the first -1 it seems, but the rate
control algorithm shouldn't generate useless attempts that will never
really get used, since that indicates a bug in the rate scaling.

Is there anything sane I can do to help debug this case?

Could you print out the entire table there when the warning happens? Or
at least, it'd help to figure out at which index the invalid actually
happens. It seems that if that perhaps happens on the very first index,
the driver might get completely confused and perhaps not even send the
frame, which would lead to symptoms like the one you describe.

It seems plausible that there's a path somewhere in the rate scaling
code that forgets to set IEEE80211_TX_RC_MCS or so.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html