On 10/15/2010 11:47 AM, Luis R. Rodriguez wrote:
On Fri, Oct 15, 2010 at 9:51 AM, Ben Greear<greearb@xxxxxxxxxxxxxxx> wrote:
On 10/14/2010 04:48 PM, Luis R. Rodriguez wrote:
On Thu, Oct 14, 2010 at 04:39:45PM -0700, Luis R. Rodriguez wrote:
On Thu, Oct 14, 2010 at 4:30 PM, Ben Greear<greearb@xxxxxxxxxxxxxxx>
wrote:
On 10/14/2010 04:19 PM, Luis R. Rodriguez wrote:
Ok please try this patch, it cures it for me.
Well, it got a lot further than normal, but it still
hit the poison check after a few minutes.
Current test case is my app loading 130 or so stations, each running
wpa_supplicant. All were created, and quite a few had associated
when the poison check hit.
So, it definitely looks like a step in the right direction, but
not fully fixed yet.
I'll do some more testing with this patch applied and using just my
perl script to make sure the problem is reproducible outside of my
application.
Ok, whatever userspace does it should not corrupt to kernel, unless
its poking /dev/mem
Can also try this one instead, it will prevent any other instances
we would not have caught on stopping and starting RX here.
It ran longer than before any of your locking patches (about 3 minutes), but
it did hit the poison check.
Before it did, I had a bunch of OOM errors trying to allocate
skbs. I have 2GB of RAM on this system, but maybe it's not tuned
properly, and not all of that can be used for networking on 32-bit
kernels....
I have Felix's 3 ani patches from ~3 days ago applied, running 130 stations
in WPA mode.
I'm going to try running fewer to dodge the OOM case,
but I have a few other things to take care of first.
Thanks for testing. So now I cannot reproduce the poison anymore, any
other ideas what I can try? Does the perl script still give you poison
or just with your Ãber proprietary application?
I was just writing that my script wouldn't reproduce it..but it did before I
was done typing. Same looking poison exception as ever.
I also notice my Trendnet AP is very un-happy with anything past around 30 STA
devices associated, and according to it's status page..NONE of my STAs are associated,
though things show up in /proc/net/wireless and I see auth/assoc messages in
/var/log/messages on my STA system, so the AP may just be funky.
On my system, most of the STAs are constantly trying to associate and being
rejected by the AP.
Here is updated script, creates 130 STAs and sleeps a bit between starting supplicants.
It assumes you have a single PHY device, and if you do, it will use it's name regardless
of how many times you reload the driver.
Please forgive the lameness in the MAC creation logic..though it does at least appear
to work :)
Thanks,
Ben
#!/usr/bin/perl
use strict;
my $iw = "./local/sbin/iw";
my $ip = "./local/sbin/ip";
my $wpa_s = "./local/bin/wpa_supplicant";
my $ssid = "candela-n";
my $key = "wpadmz123";
my $phy = `cat /sys/class/ieee80211/*/name`;
chomp($phy);
my $max = 130;
my $i;
my $j = 4;
my $k = 1;
my $bmac = "00:01:02:03:";
my $cmd;
# Create stations
for ($i = 0; $i<$max; $i++) {
runCmd("$iw phy $phy interface add sta$i type station");
if ($j > 99) {
$j = 1;
$k++;
}
my $mc5 = "$j";
if (length($mc5) == 1) {
$mc5 = "0$mc5"; # pad mac octet
}
my $mc4 = "$k";
if (length($mc4) == 1) {
$mc4 = "0$mc4"; # pad mac octet
}
$j++;
my $mac = "$bmac$mc4:$mc5";
runCmd("$ip link set sta$i address $mac");
runCmd("$iw dev sta$i set power_save off");
}
# Bring them up with WPA
for ($i = 0; $i<$max; $i++) {
open(FD, ">sta$i" . "_wpa.conf") || die("Couldn't open file: $!\n");
print FD "
ctrl_interface=/var/run/wpa_supplicant
fast_reauth=1
#can_scan_one=1
network={
ssid=\"$ssid\"
proto=WPA
key_mgmt=WPA-PSK
psk=\"$key\"
pairwise=TKIP CCMP
group=TKIP CCMP
}
";
runCmd("$wpa_s -B -i sta$i -c sta$i" . "_wpa.conf -P sta$i" . "_wpa.pid -t -f sta$i" . "_wpa.log");
sleep(2);
}
sub runCmd {
my $cmd = shift;
print "$cmd\n";
`$cmd`;
}
Luis
--
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
--
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
