ath0 / wlan0 on 8.0

[Sam Leffler]

Marten Vijn wrote:
> hi all,
>
> When benchmarkmarking an ath0 card an I get these errors.
> After a could (~10) no traffic is possible anymore.
>   

"no traffic is possible" doesn't say enough.  Do you see beacons from 
the ap?  Are interrupts being received on the ap?  Are you out of 
resources like mbufs?  I have seen, for example, things like nightly 
cron scripts accidentally left to run and kill operation.

> What does this message mean?
>
> ath0: stuck beacon; resetting (bmiss count 4)
> ath0: stuck beacon; resetting (bmiss count 4)
> ath0: stuck beacon; resetting (bmiss count 4)
>   

It means 4 consecutive beacon intervals went by w/o the ap being able to 
xmit a beacon frame.  When this happens the driver does a h/w reset of 
the chip and continues.  You can raise this threshold but if it's 
happening a lot you should understand why.

>
> # uname -a 
> FreeBSD  8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Jun 29 21:44:19 CEST
> 2009     root at master:/usr/obj/nanobsd.node_ap_64M/usr/src/sys/KERNEL
> i386
> #
>
> My benmark setup is dbs with 9 clients, and a ap in bridging mode.
>
> see  http://bsd.wifisoft.org/trac/wiki/wireless_benchmark for more info.
>
> All nodes run FreeBSD..
>   
The only 8.0 log under "crashes" does not point to a system crash.

I didn't see information on the wireless setup (e.g. ifconfig commands 
to setup and/or status to show final operating syste).  Does this happen 
on all channels?  What else is running on the machine with the ap?  What 
is the network traffic mix (e.g. tx vs rx)?

I know several groups using the Alix board in similar configs to run 
production ap's with >10 users but you will need to tune the system for 
best operation.  Under extreme wireless network load the PCI bus becomes 
a bottleneck and causes the host to be unable to setup each beacon frame 
in real-time to satisfy NextTBTT requirements.  Look at how the SWBA 
mechanism works in the driver and the hw.ath.hal.sw_brt and 
hw.ath.hal.dma_brt tunables.

Otherwise stuck beacon conditions can be caused by the ap not getting 
access to the wireless medium due to it being busy.  You should sniff 
traffic around the time of a problem for clues.  There are also h/w 
registers you can observe (e.g. with athregs) to see how busy the medium 
is from the POV of the ap.  There have been chip bugs related to this 
condition but doing a reset should always restore operation.  If this 
isn't happening should be able to diagnose what's going with the 
existing facilities (e.g. athdebug msgs).  Understand however that 
building a product ap is nontrivial and the FreeBSD ath driver can 
easily be optimized better for this purpose.

    Sam