From: Ben Greear <greearb@candelatech.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] 3.17 regression, ath9k: Summarize hw state per channel context
Date: Fri, 03 Oct 2014 14:17:00 -0700 [thread overview]
Message-ID: <542F124C.50406@candelatech.com> (raw)
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 <rmanohar@qti.qualcomm.com>
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).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
: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 <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: "ath9k-devel@lists.ath9k.org" <ath9k-devel@venema.h4ckr.net>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
rmanohar@qti.qualcomm.com
Subject: 3.17 regression, ath9k: Summarize hw state per channel context
Date: Fri, 03 Oct 2014 14:17:00 -0700 [thread overview]
Message-ID: <542F124C.50406@candelatech.com> (raw)
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 <rmanohar@qti.qualcomm.com>
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).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
: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 <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next reply other threads:[~2014-10-03 21:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-03 21:17 Ben Greear [this message]
2014-10-03 21:17 ` 3.17 regression, ath9k: Summarize hw state per channel context Ben Greear
2014-10-04 7:46 ` [ath9k-devel] " Sujith Manoharan
2014-10-04 7:46 ` Sujith Manoharan
2014-10-04 14:30 ` [ath9k-devel] " Ben Greear
2014-10-04 14:30 ` Ben Greear
2014-10-16 22:41 ` [ath9k-devel] " Ben Greear
2014-10-16 22:41 ` Ben Greear
2014-10-24 18:54 ` [ath9k-devel] " Ben Greear
2014-11-04 21:33 ` Ben Greear
2014-11-04 21:33 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542F124C.50406@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath9k-devel@lists.ath9k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.