hi,
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.
Good, this i can likely reproduce.
-adrian
On 6 August 2016 at 00:48, Andrew Stevenson wrote:
> OK a bit less incompetently this
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
Hi,
Recompile with ATH_DEBUG, AH_DEBUG, ATH_DIAGAPI
Thanks!
-adrian
On 4 August 2016 at 00:48, Andrew Stevenson wrote:
>
> 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
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
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.)
Thanks,
-adrian
On 3 August 2016 at 15:36, Andrew Stevenson
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
hi,
do this:
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.
-adrian
..
On 2 August 2016 at 12:19, Andrew Stevenson wrote:
>
> On 29 Jul 2016, at 23:07, Adrian Chadd
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,
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.
Thanks!
-adrian
___
freebsd-wireless@freebsd.org
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
On Fri, Jul 29, 2016 at 01:43:20PM -0700, Adrian Chadd wrote:
> oh god damint, wait. It's an AR9227, right?
>
> 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.
>
Consider your arm twisted.
Glen
oh god damint, wait. It's an AR9227, right?
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.
-a
___
freebsd-wireless@freebsd.org mailing list
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
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:
oss remains.
> >>
> >> I notice quite numerous errors in dmesg. Bursts of:
> >>
> >> ath0: ath_tx_default_comp: bf 0xfe826aa0: seqno 550: bf_next not
> >> NULL!
> >> ath0: ath_tx_default_comp: bf 0xfe831d20: seqno 551: bf_next no
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
he possible packet
>> loss remains.
>>
>> I notice quite numerous errors in dmesg. Bursts of:
>>
>> ath0: ath_tx_default_comp: bf 0xfe826aa0: seqno 550: bf_next not
>> NULL!
>> ath0: ath_tx_default_comp: bf 0xfe831d20: seqno 551: bf_next not
, nothing seems to be able to associate. Restarting the
> interface (/etc/rc.d/netif restart wlan0) fixes that but the possible packet
> loss remains.
>
> I notice quite numerous errors in dmesg. Bursts of:
>
> ath0: ath_tx_default_comp: bf 0xfffffe0000826aa0: seqno 550: bf_next not NULL
that but the possible packet loss remains.
I notice quite numerous errors in dmesg. Bursts of:
ath0: ath_tx_default_comp: bf 0xfe826aa0: seqno 550: bf_next not NULL!
ath0: ath_tx_default_comp: bf 0xfe831d20: seqno 551: bf_next not NULL!
ath0: ath_tx_default_comp: bf 0xfe827298: seqno 552
19 matches
Mail list logo