On 10/27/2010 09:26 AM, Luis R. Rodriguez wrote:
On Wed, Oct 27, 2010 at 9:17 AM, Ben Greear<greearb@xxxxxxxxxxxxxxx> wrote:
On 10/26/2010 03:17 PM, Luis R. Rodriguez wrote:
On Tue, Oct 26, 2010 at 3:11 PM, Ben Greear<greearb@xxxxxxxxxxxxxxx>
wrote:
On 10/26/2010 03:03 PM, Luis R. Rodriguez wrote:
On Tue, Oct 26, 2010 at 2:59 PM, Ben Greear<greearb@xxxxxxxxxxxxxxx>
wrote:
On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
Here is some more PCU locking enhancements I tested today
while trying to resolve the WARN() that happens when we
try to stop RX DMA and fail. While working on that I figured
I'd work on the TX DMA stuff too, here's a shot at it. I
can no longer get TX / RX DMA rants, please test and let
me know if you do. I only tried some basic testing like
rmmoding while scannign, which typicallly produced some
errors. Now I don't get squat.
Ben if you can test wit your super proprietary application
that'd be great.
This also simplifies locking considerably.
This doesn't break suspend so I'm happy. It also depends
on the last RX DMA fixes I had posted earlier. If you'd
like to get an all-in-one patch of all my patches pending
you can wget this file and git am it:
http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823
I have done some initial testing on the combined patch on top of
today's
wireless-testing tree. I also have the memory-barrier patch applied to
ath9k, as that is still not upstream. I have no idea if it has any
affect
or not (I'm on x86..seems that wmb() stuff was mostly for other
platforms?).
So far, it is showing zero problems, certainly no memory poison issues.
The wireless-testing tree has some lockdep warning related to a mouse
driver
that disables lockdep early, so it's possible there are lockdep issues
waiting.
I will let this test run for a while, but it already looks more stable
than before, so:
Tested-by: Ben Greear<greearb@xxxxxxxxxxxxxxx>
Awesome! Thanks for testing. So how about the TX dma rants, do you
still get those?
I've seen no rants at all.
Fucking awesome!
I'm using my standard 130 STAs
I love how now 130 STAs are "standard" for ath9k tests :)
I dropped it down to 30 STAs so that all could associate and
be stable with my AP. I set up a tcp stream running as fast as it could
between
two virtual STAs. It ran about 9Mbps bi-directional overnight
with no obvious problems.
Thanks for the reports, great to hear it is working fine now.
Of course, as soon as I hit send, something starts looking strange.
One of the interfaces generating ~9Mbps of traffic started bouncing,
with warnings about a class 2 frame received. Any idea what
that means?
Not sure it's an ath9k issue though, as power-cycling the AP made
everything start working again. So, plz don't worry about this
until we have a chance to test against different APs, etc.
2010-10-27 08:28:06.066 sta11 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:06.075 sta14 (phy #0): scan started
2010-10-27 08:28:06.947 sta14 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
2010-10-27 08:28:06.994 sta26 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 reason 6: Class 2 frame received from non-authenticated station
2010-10-27 08:28:06.998 sta26 (phy #0): disconnected (by AP) reason: 6: Class 2 frame received from non-authenticated station
2010-10-27 08:28:07.038 sta14 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:0d status: 0: Successful
2010-10-27 08:28:07.038 sta14: new station 00:14:d1:c6:d2:54
2010-10-27 08:28:07.038 sta14 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:0d status: 0: Successful
2010-10-27 08:28:07.038 sta14 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:07.093 sta17 (phy #0): scan started
2010-10-27 08:28:07.961 sta17 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
2010-10-27 08:28:08.018 sta17 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:10 status: 0: Successful
2010-10-27 08:28:08.027 sta17: new station 00:14:d1:c6:d2:54
2010-10-27 08:28:08.037 sta17 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:10 status: 0: Successful
2010-10-27 08:28:08.038 sta17 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:08.074 sta26 (phy #0): scan started
2010-10-27 08:28:08.943 sta26 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
2010-10-27 08:28:08.983 sta7 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:06 reason 0: <unknown>
2010-10-27 08:28:08.983 sta7 (phy #0): disconnected (by AP)
2010-10-27 08:28:09.014 sta26 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 status: 0: Successful
2010-10-27 08:28:09.018 sta26: new station 00:14:d1:c6:d2:54
2010-10-27 08:28:09.028 sta26 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 status: 0: Successful
2010-10-27 08:28:09.028 sta26 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:09.053 sta8 (phy #0): scan started
2010-10-27 08:28:09.913 sta8 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
2010-10-27 08:28:09.957 sta23 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:16 reason 0: <unknown>
2010-10-27 08:28:09.958 sta23 (phy #0): disconnected (by AP)
2010-10-27 08:28:09.999 sta8 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:07 status: 0: Successful
2010-10-27 08:28:10.003 sta8: new station 00:14:d1:c6:d2:54
2010-10-27 08:28:10.014 sta8 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:07 status: 0: Successful
2010-10-27 08:28:10.014 sta8 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:10.035 sta23 (phy #0): scan started
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
