Re: bf_next not NULL!

2016-08-06 Thread Adrian Chadd
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

Re: bf_next not NULL!

2016-08-05 Thread Andrew Stevenson
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

Re: bf_next not NULL!

2016-08-04 Thread Adrian Chadd
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

Re: bf_next not NULL!

2016-08-04 Thread Andrew Stevenson
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

Re: bf_next not NULL!

2016-08-03 Thread Adrian Chadd
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

Re: bf_next not NULL!

2016-08-02 Thread 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

Re: bf_next not NULL!

2016-08-02 Thread Adrian Chadd
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

Re: bf_next not NULL!

2016-08-02 Thread Andrew Stevenson
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,

Re: bf_next not NULL!

2016-07-29 Thread Adrian Chadd
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

Re: bf_next not NULL!

2016-07-29 Thread Andrew Stevenson
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

Re: bf_next not NULL!

2016-07-29 Thread Glen Barber
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

Re: bf_next not NULL!

2016-07-29 Thread Adrian Chadd
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

Re: bf_next not NULL!

2016-07-29 Thread Andrew Stevenson
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

Re: bf_next not NULL!

2016-07-21 Thread Andrew Stevenson
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:

Re: bf_next not NULL!

2016-07-18 Thread Willem Offermans
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

Re: bf_next not NULL!

2016-07-16 Thread Andrew Stevenson
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

Re: bf_next not NULL!

2016-07-16 Thread Adrian Chadd
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

Re: bf_next not NULL!

2016-07-16 Thread Willem Offermans
, 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

bf_next not NULL!

2016-07-16 Thread Andrew Stevenson
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