On 09.05.2013 22:11, Lev Serebryakov wrote:
And there is no power setting settings on Windows (or I
don't know how to find them, but I see big property page with
different settings, like roaming aggressiveness and preferred
frequency band).
Lev,
depends of driver
Hello, Adrian.
You wrote 9 мая 2013 г., 21:23:20:
AC When you say recover fast, what's that mean?
First time I call forced bstuck several times, but it seems, that
client re-associate after first one. For second time (AP was
rebooted after first experiment) client lost association (According
ok, I'll go over hte logs again soon.
thanks! we're getting there!
adrian
On 9 May 2013 10:26, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 9 мая 2013 г., 21:23:20:
AC When you say recover fast, what's that mean?
First time I call forced bstuck several times, but it
Hello, Adrian.
You wrote 9 мая 2013 г., 23:24:07:
AC Next time you do this, can you do this:
AC wlandebug +crypto +assoc +state
AC I'd like to see what's actually going on behind the scenes.
AC I bet this is what is actually going on. Can you please do the
AC wlandebug above, so we can see if
Hello, Adrian.
You wrote 9 мая 2013 г., 23:24:07:
AC I bet this is what is actually going on. Can you please do the
AC wlandebug above, so we can see if it's actually disassociating and not
AC transitioning back through SCAN/ASSOC states?
Here it is. Faster, than usual (~150 seconds, typical it
Hello, Adrian.
You wrote 9 мая 2013 г., 23:39:49:
May 9 23:36:43 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] pwr save q
overflow, drops 8895 (size 50)
messages are generating with these srttings.
AC ... right; is that the MAC address of the test station?
Yep!
--
// Black Lion AKA Lev
Hello, Lev.
You wrote 9 мая 2013 г., 23:42:32:
AC I bet this is what is actually going on. Can you please do the
AC wlandebug above, so we can see if it's actually disassociating and not
AC transitioning back through SCAN/ASSOC states?
LS Here it is. Faster, than usual (~150 seconds, typical it
On 9 May 2013 12:48, Lev Serebryakov l...@freebsd.org wrote:
f0:a2:25:ec:38:c6 is Kindle.
c4:85:08:3f:9e:c2 is Windows client, UDP stream receiver.
Ok. So this is a different problem.
May 9 23:39:18 gateway kernel: wlan0: [f0:a2:25:ec:38:c6] RSN ie: mc
3/0 uc 3/0 key 2 caps 0x0
May 9
.. and basically, once you've grabbed some hostapd debugging, let me
know if you see transmit queue stalls. Yes, the queue handling w/
power-save handling in hostapd mode is rather suboptimal. That's high
up on my 'broken stuff that needs fixing' list.
Let me know how the data gathering goes and
Hello, Adrian.
You wrote 9 мая 2013 г., 23:58:31:
AC .. and basically, once you've grabbed some hostapd debugging, let me
AC know if you see transmit queue stalls. Yes, the queue handling w/
AC power-save handling in hostapd mode is rather suboptimal. That's high
AC up on my 'broken stuff that
Yup, looks like the TX queue is just too deep and the EAPOL messages
aren't making out.
I thought I fixed this.
I'll see if I can replicate this on holidays, but it may take a while.
But luckily this looks like I've fixed the hardware TX queue stall!
adrian
Ah. So these non aggregate tests are showing a problem - there shouldn't be 500
frames in the txq. Ever. That's just plain dumb.
Because of this, the logic I introduced to limit queue depth for a node isn't
working - the node software queue depth never grows past a handful. They're
immediately
Yeah, -HEAD right now is still busted.
I'm testing out some locking changes right now that fix how I was
handling the holding descriptors. Once that's in -HEAD, I'll tell you
to re-test.
Thanks!
Adrian
On 8 May 2013 13:49, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 8
Hello, Adrian.
You wrote 9 мая 2013 г., 1:00:06:
AC Yeah, -HEAD right now is still busted.
AC I'm testing out some locking changes right now that fix how I was
AC handling the holding descriptors. Once that's in -HEAD, I'll tell you
AC to re-test.
We had long holidays (4 days!) here, so I
Ok, please update to the latest -HEAD as of right now and re-test.
Adrian
On 8 May 2013 14:03, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 9 мая 2013 г., 1:00:06:
AC Yeah, -HEAD right now is still busted.
AC I'm testing out some locking changes right now that fix how
Hi Lev (and others);
I've fixed the UDP TX + rekey session drop bug.
Please re-test your testcase on the latest -HEAD and let me know how it goes.
I'd really like to sneak in these power save and reassociate changes
of mine, but first I want to make sure that your issue is correctly
resolved.
Hello, Adrian.
You wrote 3 мая 2013 г., 8:22:40:
I'll do some further digging. It may be that I just give in and add
the TXQ stall workaround. I'd however like to avoid doing that if
possible. :-)
AC Hm, I'm reproducing it here and I see some odd descriptor behaviour.
AC I'll tinker with it a
Hi!
Please update to the head -HEAD and test!
I'm still debugging all of this and trying to understand what the
other failure cases. Right now I'm seeing STA disassocications during
UDP testing but it doesn't look like a stalled queue.
Thanks,
Adrian
Hi,
So doing this testing as a station doing the UDP transmitting (to a
FreeBSD AP) is showing some interesting behaviour. No, i don't think
it's your bug.
The key re-negotiation seems to be failing somewhere; I bet it's out
of sequence or out of order crypto frames. I've seen this happen
before
On 2 May 2013 18:54, Adrian Chadd adr...@freebsd.org wrote:
.. and I've now (mostly) successfully reproduced this here at home.
I'll do some further digging. It may be that I just give in and add
the TXQ stall workaround. I'd however like to avoid doing that if
possible. :-)
Hm, I'm
Hello, Adrian.
You wrote 1 мая 2013 г., 2:17:52:
AC Well, right now I'm trying to figure out whether there's a race
AC condition in setting up / enabling the TX queue that I haven't yet
AC seen before, or whether we've hit another one of those corner case
AC bugs in the TX queue handling.
I
On 1 May 2013 02:32, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 1 мая 2013 г., 2:17:52:
AC Well, right now I'm trying to figure out whether there's a race
AC condition in setting up / enabling the TX queue that I haven't yet
AC seen before, or whether we've hit another
I'm trying to plan out how to potentially address this.
I don't know whether it'll be enough to just set TXE to 1 for that
queue and restart TX that way. I was hoping you'd post some more
results with aggregate frames, but it doesn't seem to be happening.
I'm hoping I don't have to stop the DMA
Hello, Adrian.
You wrote 30 апреля 2013 г., 8:53:00:
AC Any follow-up with the latest stuff in -HEAD? I'd like to see if the
AC hardware queue is behaving how I think it is.
Sorry, was busy yesterday.
Sources: r250041, TDMA is enabled in kernel config.
Warm-up: 120 seconds of TCP,
On 30 April 2013 01:24, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 30 апреля 2013 г., 8:53:00:
AC Any follow-up with the latest stuff in -HEAD? I'd like to see if the
AC hardware queue is behaving how I think it is.
Sorry, was busy yesterday.
Sources: r250041, TDMA
Well, right now I'm trying to figure out whether there's a race
condition in setting up / enabling the TX queue that I haven't yet
seen before, or whether we've hit another one of those corner case
bugs in the TX queue handling.
I may add in a hack to the completion code that checks if the queue
.. well, please update to -HEAD; I've just added some more debugging
to the reset path to see what the state of the hardware queue is.
Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To
Hello, Adrian.
You wrote 29 апреля 2013 г., 11:29:32:
AC Please update to -HEAD first!
Ok :) These test were on r250017.
AC And erm, run iperf tcp first, before udp. That way aggregation is
AC negotiated. :-)
Ok. But on previous revisions it was not needed. But previous tests
were done no
There's likely some bugs with the AMPDU aggregation negotiating
kicking in when all the TX buffers are full. I thought that was fixed,
alas.
I'll investigate that later. I have to acquire some programmable
attenuators to do this.
adrian
___
Any follow-up with the latest stuff in -HEAD? I'd like to see if the
hardware queue is behaving how I think it is.
Adrian
On 29 April 2013 00:49, Adrian Chadd adr...@freebsd.org wrote:
There's likely some bugs with the AMPDU aggregation negotiating
kicking in when all the TX buffers are full.
Hello, Adrian.
You wrote 27 апреля 2013 г., 22:56:30:
AC You're not doing something like leaving bgscan enabled, or not
AC defining a channel up front?
Here is my config:
ifconfig_wlan0=inet 192.168.135.1 netmask 255.255.255.0 mode 11ng channel
3:ht/40 -bgscan ssid home.serebryakov.spb.ru
On 28 April 2013 11:50, Lev Serebryakov l...@freebsd.org wrote:
300M. Only 11-30M seen by client now, but no beacon stucks.
After AP hangs several forced beacon stucks + hostaptd restart
allow client to re-associate.
Right. That's likely because 11n aggregation wasn't enabled. I don't
Hello, Adrian.
You wrote 28 апреля 2013 г., 23:38:20:
AC There's some race condition hack that Sam threw in that gets enabled
AC only if you compile things with TDMA support enabled. Would you mind
AC compiling in TDMA support (add options IEEE80211_SUPPORT_TDMA) to your
AC kernel config and
.. how's this never triggered a clang warning on me before?
Just add casts for now or something so it compiles.
Adrian
On 28 April 2013 12:48, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 28 апреля 2013 г., 23:38:20:
AC There's some race condition hack that Sam threw
Hello, Adrian.
You wrote 28 апреля 2013 г., 23:49:38:
AC .. how's this never triggered a clang warning on me before?
AC Just add casts for now or something so it compiles.
Testing... One more datapoint: with this option bsnmpd with wlan
plugin complains:
Apr 29 00:09:46 gateway
Hello, Adrian.
You wrote 28 апреля 2013 г., 23:38:20:
AC There's some race condition hack that Sam threw in that gets enabled
AC only if you compile things with TDMA support enabled. Would you mind
AC compiling in TDMA support (add options IEEE80211_SUPPORT_TDMA) to your
AC kernel config and
Hello, Adrian.
You wrote 26 апреля 2013 г., 4:11:44:
AC Ok. Next time it happens, force a stuck beacon:
AC sysctl dev.ath.X.forcebstuck=1
AC That will cause the right kind of reset in order to log the frames in
AC the TX queue.
AC Make sure you have the right debug mask though!
Without reboot
Hi,
Wait. sysctl dev.ath.0.forcebstuck=1 didn't fix it?
adrian
On 26 April 2013 01:25, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 26 апреля 2013 г., 4:11:44:
AC Ok. Next time it happens, force a stuck beacon:
GOT IT!
You could use sudo messages as markers in log
On 26 April 2013 01:45, Adrian Chadd adr...@freebsd.org wrote:
Hi,
Wait. sysctl dev.ath.0.forcebstuck=1 didn't fix it?
So the descriptors are mostly completed. I really need to hack the
reset path to continue printing everything in the queue, not just the
frames that were completed.
But the
Hello, Adrian.
You wrote 26 апреля 2013 г., 18:56:57:
AC And please cc -wireless with your debugging results :)
Ok.
It is interesting how throughput is not connected to rate after
these problems. Now I have client at stable 270M rate with RSSI ~28,
and only 15-20Mbit/s of UDP traffic
On 26 April 2013 14:14, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 26 апреля 2013 г., 18:56:57:
AC And please cc -wireless with your debugging results :)
Ok.
It is interesting how throughput is not connected to rate after
these problems. Now I have client at
Hello, Adrian.
You wrote 26 апреля 2013 г., 12:51:17:
Wait. sysctl dev.ath.0.forcebstuck=1 didn't fix it?
Ok, several such commands helps without down/up of interface.
Log attached: a lot of traffic, several BAR retransmits, interface
hangs, several forcebstuck=1, client could
You're not doing something like leaving bgscan enabled, or not
defining a channel up front?
There's a lot of resets hre.
adrian
On 26 April 2013 14:28, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 26 апреля 2013 г., 12:51:17:
Wait. sysctl dev.ath.0.forcebstuck=1 didn't
Hi,
I've just committed something to -HEAD that logs -all- the descriptors
in the TX queue during a reset.
This requires ATH_DEBUG_RESET to be set (0x20), so use the same debug
mask as before.
Thanks!
Adrian
___
freebsd-wireless@freebsd.org mailing
Ok. Next time it happens, force a stuck beacon:
sysctl dev.ath.X.forcebstuck=1
That will cause the right kind of reset in order to log the frames in
the TX queue.
Make sure you have the right debug mask though!
Adrian
___
Try dropping it down to a HT20 channel.
adrian
On 23 April 2013 05:41, Lev Serebryakov l...@freebsd.org wrote:
Hello, Freebsd-wireless.
Now my router/AP is new hardware in new case, and it is not
overheating for sure.
AP's WiFi card is Ubiquity SR-71E MiniPCIe card. Client is Intel
Hello, Adrian.
You wrote 23 апреля 2013 г., 18:43:45:
AC Try dropping it down to a HT20 channel.
AP or client or both? Is it enough to disable HT40 channels on
client?
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
Falling back to a ht:20- channel did considerably lower the number of stuck
beacon messages on my AR9220. It still periodically hangs though (is this
why ``baseband hangs?'' is listed in the wiki?).
On Tue, Apr 23, 2013 at 5:45 PM, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You
On 23 April 2013 12:57, Petko Bordjukov bordju...@gmail.com wrote:
Falling back to a ht:20- channel did considerably lower the number of stuck
beacon messages on my AR9220. It still periodically hangs though (is this
why ``baseband hangs?'' is listed in the wiki?).
Well, partially.
I'm seeing
49 matches
Mail list logo
