Re: bf_next not NULL!

[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 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  ar5416DoCalibration: IQ Calibration, state 2, calValid 0x4
> 0   ar9287olcTemperatureCompensation: initPDADC=126, currPDADC=124
> 0   ar9287olcTemperatureCompensation: delta=1
> 0   NF calibrated [ctl] [chain 0] is -120
> 0   NF calibrated [ctl] [chain 1] is -120
> 0   NF calibrated [ext] [chain 0] is -121
> 0   NF calibrated [ext] [chain 1] is -120
> 0   CCA: [0: -121][1: -121][3: -121][4: -121]
> 0   2462 raw nf -120 adjust 24
> 204 ar5416DoCalibration: IQ Calibration, state 2, calValid 0x4
> 0   ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
> 87  ar5416DoCalibration: IQ Calibration, state 2, calValid 0x4
> 0   ar9287olcTemperatureCompensation: initPDADC=126, currPDADC=124
> 0   ar9287olcTemperatureCompensation: delta=1
> 0   NF calibrated [ctl] [chain 0] is -121
> 0   NF calibrated [ctl] [chain 1] is -121
> 0   NF calibrated [ext] [chain 0] is -121
> 0   NF calibrated [ext] [chain 1] is -121
> 0   CCA: [0: -121][1: -121][3: -121][4: -121]
> 0   2462 raw nf -121 adjust 25
> 150 ar5416DoCalibration: IQ Calibration, state 2, calValid 0x4
> 0   ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
> 138 ar5416DoCalibration: IQ Calibration, state 2, calValid 0x4
> 0   ar5416DoCalibration: sample 0 of 1 finished
> 0   0: Chn 0 pmi=0x127e79ea;pmq=0x13347b9d;iqcm=0xffca20b5;
> 0   0: Chn 1 pmi=0x10bfb290;pmq=0x116a15ed;iqcm=0xff899551;
> 0   0: Chn 2 pmi=0x;pmq=0x;iqcm=0x;
> 0   Start IQ Cal and Correction for Chain 0
> 0   Orignal: iq_corr_meas = 0xffca20b5
> 0pwr_meas_i = 0x127e79ea
> 0pwr_meas_q = 0x13347b9d
> 0iqCorrNeg is 0x0001
> 0iCoff = 0x0001
> 0qCoff = 0xfffd
> 0   New:  iCoff = 0x0001
> 0: iCoff = 0x1  qCoff = 0xfffd
> 0   IQ Cal and Correction done for Chain 0
> 0   Start IQ Cal and Correction for Chain 1
> 0   Orignal: iq_corr_meas = 0xff899551
> 0pwr_meas_i = 0x10bfb290
> 0pwr_meas_q = 0x116a15ed
> 0iqCorrNeg is 0x0001
> 0iCoff = 0x0003
> 0qCoff = 0xfffd
> 0   New:  iCoff = 0x0003
> 0: iCoff = 0x3  qCoff = 0xfffd
> 0   IQ Cal and Correction done for Chain 1
> 0   ar9287olcTemperatureCompensation: initPDADC=126, currPDADC=124
> 0   ar9287olcTemperatureCompensation: delta=1
> 0   NF calibrated [ctl] [chain 0] is -121
> 0   NF calibrated [ctl] [chain 1] is -121
> 0   NF calibrated [ext] [chain 0] is -121
> 0   NF calibrated [ext] [chain 1] is -121
> 0   CCA: [0: -121][1: -121][3: -121][4: -121]
> 0   2462 raw nf -121 adjust 25
> 0   ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
> 0   ar9287olcTemperatureCompensation: initPDADC=126, currPDADC=124
> 0   ar9287olcTemperatureCompensation: delta=1
> 0   NF calibrated [ctl] [chain 0] is -121
> 0   NF calibrated [ctl] [chain 1] is -121
> 0   NF calibrated [ext] [chain 0] is -121
> 0   NF calibrated [ext] [chain 1] is -121
> 0   CCA: [0: -121][1: -121][3: -121][4: -121]
> 0   2462 raw nf -121 adjust 25
> 1   ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
> 0   ar9287olcTemperatureCompensation: initPDADC=126, currPDADC=124
> 0   ar9287olcTemperatureCompensation: delta=1
> 0   NF calibrated [ctl] [chain 0] is -121
> 0   NF calibrated [ctl] [chain 1] is -121
> 0   NF calibrated [ext] [chain 0] is -121
> 0   NF calibrated [ext] [chain 1] is -121
> 0   CCA: [0: -121][1: -121][3: -121][4: -121]
> 0   2462 raw nf -121 adjust 25
> 0   ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
> 0   ar9287olcTemperatureCompensation: initPDADC=126, currPDADC=124
> 0   ar9287olcTemperatureCompensation: delta=1
> 0   NF calibrated [ctl] [chain 0] is -121
> 0   NF calibrated [ctl] [chain 1] is -121
> 0   NF calibrated [ext] [chain 0] is -120
> 0   NF calibrated [ext] [chain 1] is -121
> 0   CCA: [0: -121][1: -121][3: -121][4: -121]
> 0   2462 raw nf -121 adjust 25
> 0   ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
> 0   ar9287olcTemperatureCompensation: initPDADC=126, currPDADC=124
> 0   ar9287olcTemperatureCompensation: delta=1
> 0   NF calibrated [ctl] [chain 0] is -121
> 0   NF calibrated [ctl] [chain 1] is -122
> 0   

Re: bf_next not NULL!

[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 dev.ath.0.hal.force_full_reset=1 brought it 
back to life.

I will wait for it to die again so I can get messages before and after with 
debugging actually switched on…

Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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 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 enabled this last night and this morning I find that the DHCP server has 
> stopped serving anything on the WIFI interface. Thats a new one. It might be 
> a random bugs in the ISC DHCP server but I haven’t noticed it before and I 
> have seen that rtadvd sometimes doesn’t cope with broken interfaces and 
> requires a restart after they are fixed so maybe dhcpd is similar. That would 
> mean the sysctl loop had brought things back by itself. DHCP didn’t log 
> anything and seemed to be working over wired ethernet.
>
> I restarted DHCP and everything seems normal. Pings are a bit variable but no 
> IP layer loss (e.g. best 1.6ms, avg 6.9ms, worst 15.3 ms for a ping from a 
> client to the base station).
>
> Nothing logged yet from ath0 other than "ath0: stuck beacon; resetting (bmiss 
> count 0)” (note 0 this time) logged approx every 4 minutes. Every 5th 
> (approx) has a bmiss of 4). "ath0: device timeout” appears about once every 2 
> hours.
>
> I will keep checking and let you know.
>
> Thanks,
>
> Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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 good/bad/good times.)

OK I enabled this last night and this morning I find that the DHCP server has 
stopped serving anything on the WIFI interface. Thats a new one. It might be a 
random bugs in the ISC DHCP server but I haven’t noticed it before and I have 
seen that rtadvd sometimes doesn’t cope with broken interfaces and requires a 
restart after they are fixed so maybe dhcpd is similar. That would mean the 
sysctl loop had brought things back by itself. DHCP didn’t log anything and 
seemed to be working over wired ethernet.

I restarted DHCP and everything seems normal. Pings are a bit variable but no 
IP layer loss (e.g. best 1.6ms, avg 6.9ms, worst 15.3 ms for a ping from a 
client to the base station).

Nothing logged yet from ath0 other than "ath0: stuck beacon; resetting (bmiss 
count 0)” (note 0 this time) logged approx every 4 minutes. Every 5th (approx) 
has a bmiss of 4). "ath0: device timeout” appears about once every 2 hours.

I will keep checking and let you know.

Thanks,

Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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  wrote:
>
> 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 then at other times its back to its old tricks with lost 
> packets and the sysctl doesn’t seem to bring it back - however it seems to 
> have stopped the dropping of all the clients.
>
> Thanks,
>
> Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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 
underscore).

Thanks Adrian!

Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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  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 stayed up for the longest period in a while. 
> It has now died again however. I don’t know when it stopped working exactly 
> but there is nothing logged for ath0 since 0830 this morning (12.5 hours 
> ago)...ath0: stuck beacon; resetting (bmiss count 4). wlan0 has logged, about 
> an hour later, wlan0: STA 00:21:e9:e7:a9:e7 IEEE 802.11: disassociated.
>
> I don’t see anything logged via syslog, or in dmesg, that is different than 
> before the sysctl change.
>
> Thanks,
>
> Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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, after doing that it stayed up for the longest period in a while. It 
has now died again however. I don’t know when it stopped working exactly but 
there is nothing logged for ath0 since 0830 this morning (12.5 hours 
ago)...ath0: stuck beacon; resetting (bmiss count 4). wlan0 has logged, about 
an hour later, wlan0: STA 00:21:e9:e7:a9:e7 IEEE 802.11: disassociated.

I don’t see anything logged via syslog, or in dmesg, that is different than 
before the sysctl change.

Thanks,

Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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 mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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 happy to make a donation to your wifi (or beer!) fund if 
you send details.

I don’t see anything else about ath0 logged at the time. There is one "ath0: 
device timeout” but I think it was probably well before the actual clients lost 
connection.

Thanks,

Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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



signature.asc
Description: PGP signature

Re: bf_next not NULL!

[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
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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 needed, though occasionally I have 
to “restart" the interface (/etc/rc.d/netif restart wlan0).

Happens usually once or twice a day. Is there anything I can do to help debug? 
I tried to attach to hostapd with gdb last time but gdb had an internal error 
and killed the process.

Thanks,

Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[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: icmp_seq=188 ttl=64 time=1.336 ms
64 bytes from 10.0.0.1: icmp_seq=189 ttl=64 time=1.736 ms
64 bytes from 10.0.0.1: icmp_seq=190 ttl=64 time=1.859 ms
64 bytes from 10.0.0.1: icmp_seq=191 ttl=64 time=1.183 ms
64 bytes from 10.0.0.1: icmp_seq=192 ttl=64 time=9.892 ms
64 bytes from 10.0.0.1: icmp_seq=193 ttl=64 time=2.228 ms
64 bytes from 10.0.0.1: icmp_seq=194 ttl=64 time=1.116 ms
64 bytes from 10.0.0.1: icmp_seq=195 ttl=64 time=1.105 ms
64 bytes from 10.0.0.1: icmp_seq=196 ttl=64 time=1.796 ms

I still get the odd:

ath0: stuck beacon; resetting (bmiss count 4)

but so far much less than before.

Thanks for all your effort!

Andrew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[Willem Offermans]

Hello Adrian and FreeBSD friends,

Great news, I cannot wait till stable/11 is out. Thank you for all your 
effort.

On Sat, Jul 16, 2016 at 08:51:04AM -0700, Adrian Chadd wrote:
> hi!
> 
> both of these should be fixed in stable/11 :)
> 
> 
> -adrian
> 
> 
> On 16 July 2016 at 03:58, Willem Offermans  wrote:
> > Hello FreeBSD friends,
> >
> > On Sat, Jul 16, 2016 at 12:12:40PM +0200, Andrew Stevenson wrote:
> >> 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 
> >> 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: bf_next not 
> >> NULL!
> >> ath0: ath_tx_default_comp: bf 0xfe815bb0: seqno 553: bf_next not 
> >> NULL!
> >> ath0: ath_tx_default_comp: bf 0xfe821160: seqno 554: bf_next not 
> >> NULL!
> >>
> >> That can go on for about 20 lines, plus the ubiquitous:
> >>
> >> ath0: stuck beacon; resetting (bmiss count 4)
> >> ath0: stuck beacon; resetting (bmiss count 4)
> >> ath0: stuck beacon; resetting (bmiss count 4)
> >>
> >> that seems to be pretty regular.
> >>
> >> My card from dmesg:
> >>
> >> ath0:  mem 0x4810-0x4810 irq 21 at device 0.0 on pci4
> >> ath0: [HT] enabling HT modes
> >> ath0: [HT] enabling short-GI in 20MHz mode
> >> ath0: [HT] 1 stream STBC receive enabled
> >> ath0: [HT] 1 stream STBC transmit enabled
> >> ath0: [HT] 2 RX streams; 2 TX streams
> >> ath0: Enabling register serialisation
> >> ath0: AR9227 mac 384.2 RF5133 phy 15.15
> >> ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0
> >>
> >> And ifconfig output:
> >>
> >> wlan0: flags=8843 metric 0 mtu 1500
> >> ether 64:70:02:f0:c8:03
> >> inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255
> >> inet6 fe80::6670:2ff:fef0:c803%wlan0 prefixlen 64 scopeid 0x6
> >> nd6 options=61
> >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
> >> status: running
> >> ssid UgH channel 11 (2462 MHz 11g) bssid 64:70:02:f0:c8:03
> >> regdomain ETSI country DE indoor ecm authmode WPA2/802.11i
> >> privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit
> >> txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs
> >>
> >> I had previously been using 11ng but have just tried switching to see if 
> >> 11g had the same problems (it seems to).
> >>
> >> I'm running 10.3-STABLE r302736.
> >>
> >> Any ideas?
> >>
> >> Thanks,
> >>
> >
> > Maybe it is not related, maybe it is. I tried to use an Atheros AR938x
> > card in AP mode on FreeBSD 10.3, r302295 and 11.0, r297415 for quite some
> > time now. Of course I got the ``ath0: stuck beacon; resetting (bmiss count
> > 4)`` over and over again. Beside this, I also observed the following
> >   messages:
> >
> > Jul 12 11:15:47 kwik kernel: ath0: ath_edma_tx_processq: Q3: empty?
> > Jul 12 11:15:47 kwik kernel: ath0: ath_edma_tx_processq: Q3: empty?
> > Jul 12 12:13:33 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 15:10:19 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 16:10:32 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 18:40:01 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 18:42:36 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 19:52:05 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 20:11:45 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> >
> > and
> >
> > Jun  9 07:37:57 kwik kernel: ath0: stuck beacon; resetting (bmiss count 4)
> > Jun  9 22:21:35 kwik kernel: ath0: hardware error; resetting
> > Jun  9 22:21:35 kwik kernel: ath0: 0x 0x 0x, 
> > 0x 0x 0x
> > Jun  9 22:21:35 kwik kernel: ath0: hardware error; resetting
> > Jun  9 22:21:35 kwik kernel: ath0: 0x 0x 0x, 
> > 0x 0x 0x
> > Jun  9 23:07:35 kwik kernel: ath0: stuck beacon; resetting (bmiss count 4)
> >
> > The Wifi was so unstable that I looked for a different solution.
> >
> >
> > My card from dmesg:
> >
> > ath0:  mem 0xfbfe-0xfbff irq 16 at device 0.0 on 
> > pci1
> > ar9300_attach: calling ar9300_hw_attach
> > ar9300_hw_attach: calling ar9300_eeprom_attach
> > ar9300_flash_map: unimplemented 

Re: bf_next not NULL!

[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
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: bf_next not NULL!

[Adrian Chadd]

hi!

both of these should be fixed in stable/11 :)


-adrian


On 16 July 2016 at 03:58, Willem Offermans  wrote:
> Hello FreeBSD friends,
>
> On Sat, Jul 16, 2016 at 12:12:40PM +0200, Andrew Stevenson wrote:
>> 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 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: bf_next not 
>> NULL!
>> ath0: ath_tx_default_comp: bf 0xfe815bb0: seqno 553: bf_next not 
>> NULL!
>> ath0: ath_tx_default_comp: bf 0xfe821160: seqno 554: bf_next not 
>> NULL!
>>
>> That can go on for about 20 lines, plus the ubiquitous:
>>
>> ath0: stuck beacon; resetting (bmiss count 4)
>> ath0: stuck beacon; resetting (bmiss count 4)
>> ath0: stuck beacon; resetting (bmiss count 4)
>>
>> that seems to be pretty regular.
>>
>> My card from dmesg:
>>
>> ath0:  mem 0x4810-0x4810 irq 21 at device 0.0 on pci4
>> ath0: [HT] enabling HT modes
>> ath0: [HT] enabling short-GI in 20MHz mode
>> ath0: [HT] 1 stream STBC receive enabled
>> ath0: [HT] 1 stream STBC transmit enabled
>> ath0: [HT] 2 RX streams; 2 TX streams
>> ath0: Enabling register serialisation
>> ath0: AR9227 mac 384.2 RF5133 phy 15.15
>> ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0
>>
>> And ifconfig output:
>>
>> wlan0: flags=8843 metric 0 mtu 1500
>> ether 64:70:02:f0:c8:03
>> inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255
>> inet6 fe80::6670:2ff:fef0:c803%wlan0 prefixlen 64 scopeid 0x6
>> nd6 options=61
>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
>> status: running
>> ssid UgH channel 11 (2462 MHz 11g) bssid 64:70:02:f0:c8:03
>> regdomain ETSI country DE indoor ecm authmode WPA2/802.11i
>> privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit
>> txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs
>>
>> I had previously been using 11ng but have just tried switching to see if 11g 
>> had the same problems (it seems to).
>>
>> I'm running 10.3-STABLE r302736.
>>
>> Any ideas?
>>
>> Thanks,
>>
>
> Maybe it is not related, maybe it is. I tried to use an Atheros AR938x
> card in AP mode on FreeBSD 10.3, r302295 and 11.0, r297415 for quite some
> time now. Of course I got the ``ath0: stuck beacon; resetting (bmiss count
> 4)`` over and over again. Beside this, I also observed the following
>   messages:
>
> Jul 12 11:15:47 kwik kernel: ath0: ath_edma_tx_processq: Q3: empty?
> Jul 12 11:15:47 kwik kernel: ath0: ath_edma_tx_processq: Q3: empty?
> Jul 12 12:13:33 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
> skipping
> Jul 12 15:10:19 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
> skipping
> Jul 12 16:10:32 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
> skipping
> Jul 12 18:40:01 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
> skipping
> Jul 12 18:42:36 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
> skipping
> Jul 12 19:52:05 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
> skipping
> Jul 12 20:11:45 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
> skipping
>
> and
>
> Jun  9 07:37:57 kwik kernel: ath0: stuck beacon; resetting (bmiss count 4)
> Jun  9 22:21:35 kwik kernel: ath0: hardware error; resetting
> Jun  9 22:21:35 kwik kernel: ath0: 0x 0x 0x, 
> 0x 0x 0x
> Jun  9 22:21:35 kwik kernel: ath0: hardware error; resetting
> Jun  9 22:21:35 kwik kernel: ath0: 0x 0x 0x, 
> 0x 0x 0x
> Jun  9 23:07:35 kwik kernel: ath0: stuck beacon; resetting (bmiss count 4)
>
> The Wifi was so unstable that I looked for a different solution.
>
>
> My card from dmesg:
>
> ath0:  mem 0xfbfe-0xfbff irq 16 at device 0.0 on pci1
> ar9300_attach: calling ar9300_hw_attach
> ar9300_hw_attach: calling ar9300_eeprom_attach
> ar9300_flash_map: unimplemented for now
> Restoring Cal data from DRAM
> Restoring Cal data from EEPROM
> ar9300_hw_attach: ar9300_eeprom_attach returned 0
> ath0: [HT] enabling HT modes
> ath0: [HT] enabling short-GI in 20MHz mode
> ath0: [HT] 1 stream STBC receive enabled
> ath0: [HT] 1 stream STBC transmit enabled
> ath0: [HT] 3 RX streams; 3 TX streams
> ath0: AR9380 mac 448.3 RF5110 phy 3779.2
> ath0: 2GHz radio: 0x; 5GHz radio: 0x
>
> 

Re: bf_next not NULL!

[Willem Offermans]

Hello FreeBSD friends,

On Sat, Jul 16, 2016 at 12:12:40PM +0200, Andrew Stevenson wrote:
> 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 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: bf_next not NULL!
> ath0: ath_tx_default_comp: bf 0xfe815bb0: seqno 553: bf_next not NULL!
> ath0: ath_tx_default_comp: bf 0xfe821160: seqno 554: bf_next not NULL!
> 
> That can go on for about 20 lines, plus the ubiquitous:
> 
> ath0: stuck beacon; resetting (bmiss count 4)
> ath0: stuck beacon; resetting (bmiss count 4)
> ath0: stuck beacon; resetting (bmiss count 4)
> 
> that seems to be pretty regular.
> 
> My card from dmesg:
> 
> ath0:  mem 0x4810-0x4810 irq 21 at device 0.0 on pci4
> ath0: [HT] enabling HT modes
> ath0: [HT] enabling short-GI in 20MHz mode
> ath0: [HT] 1 stream STBC receive enabled
> ath0: [HT] 1 stream STBC transmit enabled
> ath0: [HT] 2 RX streams; 2 TX streams
> ath0: Enabling register serialisation
> ath0: AR9227 mac 384.2 RF5133 phy 15.15
> ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0
> 
> And ifconfig output:
> 
> wlan0: flags=8843 metric 0 mtu 1500
> ether 64:70:02:f0:c8:03
> inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255 
> inet6 fe80::6670:2ff:fef0:c803%wlan0 prefixlen 64 scopeid 0x6 
> nd6 options=61
> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
> status: running
> ssid UgH channel 11 (2462 MHz 11g) bssid 64:70:02:f0:c8:03
> regdomain ETSI country DE indoor ecm authmode WPA2/802.11i
> privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit
> txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs
> 
> I had previously been using 11ng but have just tried switching to see if 11g 
> had the same problems (it seems to).
> 
> I'm running 10.3-STABLE r302736.
> 
> Any ideas?
> 
> Thanks,
> 

Maybe it is not related, maybe it is. I tried to use an Atheros AR938x 
card in AP mode on FreeBSD 10.3, r302295 and 11.0, r297415 for quite some 
time now. Of course I got the ``ath0: stuck beacon; resetting (bmiss count 
4)`` over and over again. Beside this, I also observed the following 
  messages:

Jul 12 11:15:47 kwik kernel: ath0: ath_edma_tx_processq: Q3: empty?
Jul 12 11:15:47 kwik kernel: ath0: ath_edma_tx_processq: Q3: empty?
Jul 12 12:13:33 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
skipping
Jul 12 15:10:19 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
skipping
Jul 12 16:10:32 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
skipping
Jul 12 18:40:01 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
skipping
Jul 12 18:42:36 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
skipping
Jul 12 19:52:05 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
skipping
Jul 12 20:11:45 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; 
skipping

and

Jun  9 07:37:57 kwik kernel: ath0: stuck beacon; resetting (bmiss count 4)
Jun  9 22:21:35 kwik kernel: ath0: hardware error; resetting
Jun  9 22:21:35 kwik kernel: ath0: 0x 0x 0x, 0x 
0x 0x
Jun  9 22:21:35 kwik kernel: ath0: hardware error; resetting
Jun  9 22:21:35 kwik kernel: ath0: 0x 0x 0x, 0x 
0x 0x
Jun  9 23:07:35 kwik kernel: ath0: stuck beacon; resetting (bmiss count 4)

The Wifi was so unstable that I looked for a different solution.


My card from dmesg:

ath0:  mem 0xfbfe-0xfbff irq 16 at device 0.0 on pci1
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_attach: calling ar9300_eeprom_attach
ar9300_flash_map: unimplemented for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
ar9300_hw_attach: ar9300_eeprom_attach returned 0
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] 3 RX streams; 3 TX streams
ath0: AR9380 mac 448.3 RF5110 phy 3779.2
ath0: 2GHz radio: 0x; 5GHz radio: 0x

wlan0: flags=8c43 metric 0 mtu 
1500
ether c4:6e:1f:1e:b6:32
inet 192.168.5.1 netmask 0xff00 broadcast 192.168.5.255
nd6 options=29
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng