Re: bf_next not NULL!

[Andrew Stevenson]

On 05 Aug 2016, at 21:22, Andrew Stevenson <and...@ugh.net.au> 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!

[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!

[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!

[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!

[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!

[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!

[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"

bf_next not NULL!

[Andrew Stevenson]

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,

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"