Hi,
I have an Atheros 9227 card in AP mode. It looks like there is some packet loss
at the wireless layer, resulting in large delays at the IP layer. Also, every
few days, nothing seems to be able to associate. Restarting the interface
(/etc/rc.d/netif restart wlan0) fixes that but the possible
On 16 Jul 2016, at 17:51, Adrian Chadd wrote:
> hi!
>
> both of these should be fixed in stable/11 :)
Excellent. Time for an upgrade then I guess :-)
Thanks very much!
Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/m
On 16 Jul 2016, at 17:51, Adrian Chadd wrote:
> hi!
>
> both of these should be fixed in stable/11 :)
After many days of building I am now on 11.0-BETA1 r302942. Ping times
certainly seem to be better though not 100% stable (but maybe there is
interference about).
64 bytes from 10.0.0.1: ic
Well after a week of running 11 (BETA1 r303134) I think sadly its worse than
10. No more bf_next errors. Still lots of "ath0: stuck beacon; resetting (bmiss
count 4)”. The main thing though is the the clients drop of the network and
can’t reattach.
Sometimes restarting hostapd is all that is n
On 29 Jul 2016, at 22:43, Adrian Chadd wrote:
> oh god damint, wait. It's an AR9227, right?
Yep.
> ok, please just twist my arm to figure out and commit the "am i deaf?
> restart please" workaround I think i need for the AR9227/AR9287. Grr.
Sorry! If it helps I’m happy to make a donation to y
On 29 Jul 2016, at 23:07, Adrian Chadd wrote:
> Hi,
>
> Yeah, the problem is that the NF calibration will time out, and I
> don't know if it's logging that by default.
>
> Do sysctl dev.ath.0.hal.debug=0x8 and then see what it lsogging when
> things hang.
Ironically, after doing that it staye
On 02 Aug 2016, at 22:53, Adrian Chadd wrote:
> do this:
Thanks. I don’t want to speak too soon but the ping time are looking promising.
I’ll let you know in a day or two how it goes.
For anyone following along at home the sysctl is "dev.ath.0.forcebstuck” (no
underscore).
Thanks Adrian!
On 02 Aug 2016, at 22:53, Adrian Chadd wrote:
> sysctl dev.ath.0.hal.force_full_reset=1
> while true; do
>sysctl dev.ath.0.force_bstuck=1
>sleep 300
> done
>
> .. see if that fixes things.
Definitely not fixed. It does sometimes seem to be good immediately after the
sysctl runs - but
On 04 Aug 2016, at 00:41, Adrian Chadd wrote:
> ok. I'll go dig an ar9227 out of storage and set it up to see what's going on.
>
> please do this:
>
> sysctl dev.ath.0.hal.debug=0x18
>
> then paste me the results from 'dmesg' over some period of time (eg
> between good/bad/good times.)
OK I
On 04 Aug 2016, at 09:50, Adrian Chadd wrote:
> Hi,
>
> Recompile with ATH_DEBUG, AH_DEBUG, ATH_DIAGAPI
I don’t know if the debug code actually changes something or its just Murphy’s
law but everything has, so far, been working since. Maybe this email will be
enough to break it…and there we
On 05 Aug 2016, at 21:22, Andrew Stevenson wrote:
>
> The same messages are repeated in dmesg so here is a sample:
>
But of course I forgot to sysctl dev.ath.0.hal.debug=0x18 after restarting with
the new kernel…
It was currently broken but sysctl dev.ath.0.hal.force_full_reset=
OK a bit less incompetently this time. This is dmesg with duplicate lines
suppressed. The first field is the number of times the line was duplicated.
164 ar5416DoCalibration: IQ Calibration, state 2, calValid 0x4
0 ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
32 ar5416D
On 06 Aug 2016, at 10:33, Adrian Chadd wrote:
> ok. Try running with 'sysctl dev.ath.0.hal.force_full_reset=1'
> enabled. It looks like the DMA engine reset isn't fully resetting
> things.
It has been running for 5 days or so now with force_full_reset but without the
forcebstuck loop in case i
13 matches
Mail list logo
