3.17 regression, ath9k: Summarize hw state per channel context

Took a while, but I found the regression that has been bugging me.

This is on stock kernel, with hand-patched fixup from Felix that fixes crash related to minstrel (patch made it upstream later, so that isn't a current problem).

The test case is easily reproducible on my systems. I'm not sure all the details matter, but this happens to be my test case at the moment:

32-bit Fedora OS, latest supplicant, etc. ath9k NIC.

create wlan0 and sta0-4 (6 total), not sure how much that matters. associate all 6 (works fine)
disconnect 5 of them, leaving sta0 up
Start trying to bring up the other 5 one at a time. It will fail, with iw events looking like this (in these logs, several sta are trying to come up, but symptom is the same with just one)

2014-10-03 14:05:43.751  1.3:  sta2 (phy #0): scan finished: 2462, ""
2014-10-03 14:05:43.755  1.3:  sta1: new station 00:0e:8e:6f:40:49
2014-10-03 14:05:43.803  1.1:  vap0 (phy #1): mgmt TX status (cookie f3d5ce40): no ack
2014-10-03 14:05:43.978  1.1:  vap0 (phy #1): mgmt TX status (cookie f3d5ca80): no ack
2014-10-03 14:05:44.179  1.1:  vap0 (phy #1): mgmt TX status (cookie f3d5c900): no ack
2014-10-03 14:05:44.364  1.3:  sta1: del station 00:0e:8e:6f:40:49
2014-10-03 14:05:44.364  1.3:  sta1 (phy #0): auth: timed out
2014-10-03 14:05:45.647  1.3:  sta3 (phy #0): scan started
2014-10-03 14:05:45.659  1.1:  vap0 (phy #1): mgmt TX status (cookie f3d15000): no ack
2014-10-03 14:05:45.668  1.3:  sta3 (phy #0): scan finished: 2462, "ben-138"
2014-10-03 14:05:48.811  1.1:  vap0 (phy #1): mgmt TX status (cookie eaec63c0): no ack
2014-10-03 14:05:49.015  1.1:  vap0 (phy #1): mgmt TX status (cookie ef8cc540): no ack
2014-10-03 14:05:49.213  1.1:  vap0 (phy #1): mgmt TX status (cookie ef8cc540): no ack
2014-10-03 14:05:51.901  1.1:  vap0: del station 00:ab:cd:ef:01:01
2014-10-03 14:07:20.368  1.3:  wlan0 (phy #0): scan started

If I restart all interfaces on the radio, the will come up with no problem, until I try to restart one again.

Bisect points at this patch:

9a9c4fbc3fcabc0d510600743204f890ebdbb141 is the first bad commit commit 9a9c4fbc3fcabc0d510600743204f890ebdbb141

Author: Rajkumar Manoharan <[email protected]>
Date:   Wed Jun 11 16:18:03 2014 +0530

ath9k: Summarize hw state per channel context

Group and set hw state (opmode, primary_sta, beacon conf) per channel context instead of whole list of vifs. This would allow each channel context to run in different mode (STA/AP).

:040000 040000 aa6eab9d17a0b3468075ff7c1abfee2ccfcb521e e15af8b46ce047c8b46177e2d4cf74a4590a2181 M drivers

I will be happy to test patches if anyone has a suggested fix or needs debug output...

Thanks,
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Does this happen with latest wireless-testing ?

Sujith

It happens with a recent one, but I can test the very latest.

Thanks,
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

I found time to test it today, and problem still exists in wireless-testing (0275925709f044dbcbbef614847d8955ba1a7776).

Thanks,
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Has anyone had time to investigate this?

Do I need to write up some scripts to reproduce this so you can verify it yourself?

Thanks,
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

[snip]

Ok, so I started looking at this problem. The bug appears to lie in the calculating of the BSSID mask. I think the BSSID calculation must be broken any time you have vifs in more than one ctx.

The reason is that ath9k_calculate_iter_data is now called per ctx, but the bssid mask must be per radio, not per ctxt.

Maybe we need two different iter methods now..one similar to the new one for ctx related summary state, and one like the older code for the bssid mask?

Thanks,
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com