Re: [Madwifi-devel] AP stops sending beacons

[Benoit P. <ben...@fr...>]

Emanuele Colombo wrote:
> Hi! I'm testing the current trunk version of madwifi, as I'm
> experiencing some problems with the older madwifi stable version.
> 
> What now happens is that, after the creation of an access point
> interface, it stops sending beacons very soon. With CALIBRATE debug
> active, it prints:
> 
> wifi0: ath_calibrate: Channel 2432/c0 - periodic recalibration
> wifi0: ath_calibrate: Channel 2432 [flags=00c0] -- IQ not done.
> wifi0: ath_calibrate: Channel 2432/c0 - periodic recalibration
> wifi0: ath_calibrate: Channel 2432 [flags=00c0] -- IQ not done.
> wifi0: ath_calibrate: Channel 2432/c0 - periodic recalibration
> wifi0: ath_calibrate: Forcing reset() for (ath_hal_getrfgain(ah) ==
> HAL_RFGAIN_NEED_CHANGE)
> wifi0: ath_calibrate: Channel 2432 [flags=00c0] -- IQ not done.
> 
> Looking at the code, it appears that ath_calibrate calls the ath_reset()
> function, and this one calls ath_beacon_config(). Adding some additional
> output I discovered that in ath_beacon_config() the "tfs" variable is
> set to 1; I can't understand what that means, but as I deduced that "tfs
> == 0" means "reset tfs", I added the following line of code:
> 
>   hw_tsf = ath_hal_gettsf64(ah);
>   tsf = le64_to_cpu(ni->ni_tstamp.tsf);
>   hw_tsftu = hw_tsf >> 10;
>   tsftu = tsf >> 10; /* NB: 64 -> 32. See note above. */
> + if (tsf == 1) tsf = 0;	/* FORCE TSF RESET */
> 
> This is only a debug test, but with this line of code the access point
> interface now works correctly, in fact after the ath_reset() beacons
> continue to be correctly sent.
> 
> I don't know how this bug can be solved correctly, I hope someone on
> this mailing list can help to find a solution, as access point mode
> currently doesn't works.
> 
> I found this problem on IXP425 boards with Atheros 5212 cards, but I
> also reproduced it on a standard PC with the same Atheros cards. The
> madwifi versions I tested are trunk revisions 3550 and 3559.
> 
> Thanks
> Emanuele Colombo

Interesting. I have similar problem with regular data queue (not beacon 
queue). In case of data queue, the linux networking code detects the 
lockups within 5s and restart the queue. Apparently, this is not 
detected/handled by ath_reset().

tsf=1 means : TSF has already been reset. It is to make sure we reset 
TSF only once and not every time the function is called. This is 
critical for IBSS synchronisation for instance.

By the way, do you get "stuck beacon" error messages?

My feeling is that ath_reset() or related might be the culprit since it 
reset the TXDP (Transmit Queue Head Pointer) of each queue... probably 
including beacon queue.

Regards,
Benoit