Kernel: ath0: stuck beacon; resetting (bmiss count 4)

jimp

Not much in that message implies that the stuck beacon message will really improve with a different driver. He talks about some features that haven't been ported yet, and that some chips may not improve at all (or may get worse) with a new driver.

That said, if you load a driver's .ko file from /boot/loader.conf.local it can override the in-kernel version of the driver.

But if you want to try the debug kernel options mentioned in that message, you'll have to run off a whole custom kernel (may as well make a custom iso/update) and the builder works fine for me. I just setup another builder today and had no trouble getting through the ports and such.

wallabybob

Other people have reported in these forums that they have successfully used a driver in a loadable module to override the driver in the kernel. I haven't tried it myself so can't verify this from personal experience.

If you care to follow this path you will need to load the module form of the driver at boot time by adding a line like if_ath_load="YES" to /boot/loader.conf.local

I would also suggest you add a printf() call to the attach function in your driver (for example, printf("bartgrefte's ath attach function\n");) so you can be sure the system is using your driver and not the driver in the kernel.

bartgrefte

Hmm, okay.
Read about that, did not new that method could override a driver integrated in the kernel

Well, if the MODULES_OVERRIDE option jimp mentioned in a different topic does not work, I'll try that :)

bartgrefte

@wallabybob:

Other people have reported in these forums that they have successfully used a driver in a loadable module to override the driver in the kernel. I haven't tried it myself so can't verify this from personal experience.
**If you care to follow this path you will need to load the module form of the driver at boot time by adding a line like if_ath_load="YES" to /boot/loader.conf.local

I would also suggest you add a printf() call to the attach function in your driver (for example, printf("bartgrefte's ath attach function\n");) so you can be sure the system is using your driver and not the driver in the kernel.**

Tried that, can't tell if it worked. Not seeing that sentence pop up anywhere in dmesg.
Note: loader.conf.local did not exist, so I created one with Vi.

offtopic: Why does pfSense not have Nano instead of Vi? Nano is easier to use.

jimp

vi is better. ;D

ee is there if you need an easy editor.

bartgrefte

Matter of personal opinion I guess :P
I kinda prefer Nano, because with that you don't have to look up the commands, they are on the screen ;D

jimp

ee is the same way, it wastes a lot of screen area on listing commands and menus and such. Me, I'd rather be editing than looking at that. :-)

johbra

I just want to share my experience with this problem. I was running PfSense 1.2.3 with a ath card and no problems. When i upgraded to "2.0-RC1 (i386) built on Sat Feb 26 15:30:26 EST 2011" wireless stopped working (with the same error).

The only setting i changed to get this working was channel (wireless channel).

bartgrefte

Changing the channel has worked for some people, but all channels are busy here and I have tried all of them without luck.

Right know I'm considering switching to a Linux based alternative for pfSense, hoping that the Linux equivalent of the Atheros driver does not contain this bug and because that one does (as far as I know) offer support for the N standard.

fthomasr

I have the same issue: kernel: ath0: stuck beacon; resetting (bmiss count 4)

Alix 6E1 board, .99H BIOS, Mikrotik r52h Atheros 5414 chipset card.

On startup mine also reports it as this:
ath0: <atheros 5413="">mem 0xe0080000-0xe008ffff irq 9 at device 12.0 on pci0
ath0: [ITHREAD]
ath0: AR5413 mac 10.5 RF5413 phy 6.1

Which I thought might be significant.

I'm trying the tunables suggested below as we speak to see if it gets better:

@UrbanSk:

Hi!
I have had this for a while also.

Try setting hw.ath.bstuck to 8 in system/advanced/system tunables (add new row).

I also added hw.ath.longcal and value 30.

For me WiFi now works better.

/UrbanSk</atheros>

bartgrefte

Tunables? That setting is not present here, or is only present in pfSense 2?

And to quote myself:
@bartgrefte:

Changing the channel has worked for some people, but all channels are busy here and I have tried all of them without luck.

Right know I'm considering switching to a Linux based alternative for pfSense, hoping that the Linux equivalent of the Atheros driver does not contain this bug and because that one does (as far as I know) offer support for the N standard.

I haven't been able to find a decent alternative for pfSense….

stephenw10

The system tunables table is only present in the 2.0 GUI. You can still set that stuff manually though.
My experience is that changing the channel works for a short time and then the stuck beacon messages start again. I am in an area of very high wifi density however and I'm sure people changing their channel or getting new hardware could account for that.

I have found that selecting a seemingly empty channel does not necessarily help. E.g. right now I am using channel 1 without errors but there are 6 other APs shown under status>>wireless on that channel.

It's also worth noting that I have never actually had a problem with wifi, just with hundreds of messages clogging the logs.

I'll try setting the tunables. Edit: hw.ath.longcal already set to 30 (default)

Steve

fthomasr

So far in one day of testing the two tunable entries, the error has not returned. I'm going to observe it until Monday in the lab, however IMO at this point already it would have produced a new error so I think it's resolved.

stephenw10

Good to hear. :)
Are we not just masking the problem though? It looks like hw.ath.bstuck just defines the number of beacons before an error is shown. I can't find a good description of the sysctls though.

Steve

Edit: From the source:


static	int ath_bstuck_threshold = 4;		/* max missed beacons */
SYSCTL_INT(_hw_ath, OID_AUTO, bstuck, CTLFLAG_RW, &ath_bstuck_threshold,
	    0, "max missed beacon xmits before chip reset");


/*
 * Reset the hardware after detecting beacons have stopped.
 */
static void
ath_bstuck_proc(void *arg, int pending)
{
	struct ath_softc *sc = arg;
	struct ifnet *ifp = sc->sc_ifp;

	if_printf(ifp, "stuck beacon; resetting (bmiss count %u)\n",
		sc->sc_bmisscount);
	sc->sc_stats.ast_bstuck++;
	ath_reset(ifp);
}

By setting the value to 8 all we are doing is increasing the number of missed beacons before the hardware is reset. There shouldn't ever be any missed beacons, this is a symptom not a cause.

bartgrefte

@stephenw10:

The system tunables table is only present in the 2.0 GUI. You can still set that stuff manually though.
My experience is that changing the channel works for a short time and then the stuck beacon messages start again. I am in an area of very high wifi density however and I'm sure people changing their channel or getting new hardware could account for that.

I have found that selecting a seemingly empty channel does not necessarily help. E.g. right now I am using channel 1 without errors but there are 6 other APs shown under status>>wireless on that channel.

It's also worth noting that I have never actually had a problem with wifi, just with hundreds of messages clogging the logs.

I'll try setting the tunables. Edit: hw.ath.longcal already set to 30 (default)

Steve

Okay.
Changing the channel still does not do anything here, lot's of errors no matter what setting and no access to my WLAN.
But I haven't tried RC3 yet, maybe that will make a difference. But still miss support for 802.11n, so I'm continuing looking for a Linux based alternative for pfSense.

I'm in a very high density area as well:

This was a few months a go and I only ran inSSIDer while standing at the back of my house (didn't check the front), I am expecting a lot more networks if I run inSSIDer again right now. Partially because the local (tv-)cable internet provider is issuing cablemodems with build-in router and AP at the moment.

stephenw10

RC3 made no difference to me, I don't think the ath driver has changed for a while. There are updates in the head code for FreeBSD though.
'Ravens Lair', nice! ;D

Steve

fthomasr

I have a also read that if you drop back to 802.11b the problem is gone. I know this is probably not desirable for most but I thought I'd throw it out there for some as an alternative:

http://forum.pfsense.org/index.php?topic=30355.0

bartgrefte

@stephenw10:

RC3 made no difference to me, I don't think the ath driver has changed for a while. There are updates in the head code for FreeBSD though.
'Ravens Lair', nice! ;D

Steve

Hmm, okay.
Got tired of my Hotmail account that mostly receives spam, so got my own domain name :).
(If you trigger the custom 404, you will see where I got the "Raven" part from ;) )

stephenw10

Since setting hw.ath.bstuck to 8 this problem has almost completely disappeared for me.
I have had less than 10 stuck beacon reports in the last 4 days which, although still not great, means the logs are readable again.
At least they would be if they weren't full of messages from hostapd! ::)
These need their own log section.

Steve