[Madwifi-devel] Re: [PATCH] Stuck beacon (yet again)

[Iain F. <il...@bi...>]

Jonas Tärnström <jonas.tarnstrom <at> repeatit.se> writes:

> 
> Hi,
> I've done some experimenting with the new HAL and founded a neat little
> function called ath_hal_numtxpending which returns number of pending (not
> yet sent) TX descriptors for a hardware queue. Combining this with disabling
> the beacoon intterupt and scheduling a timer to restart it I've come up with
> something that should eliminate the stuck beacon problem.
> 
> The diff file is also attached and was created as "unified" (which someone
> told me was good) versus today's CVS build (not the BSD branch).
> 
> Enjoy
> 
> //Regards Jonas Tärnström
> Repeatit AB
> www.repeatit.se
> 

Jonas,

I've experimented with the patch and for my environment it's not doing the trick.

FYI, I'm running a custom AP using a Senao 5354MP Aries mini-PCI, with a
stripped down Debian and a kernel built from the 2.6.8-13 source. My madwifi
snapshot is from 26 Jan 2005, and the module versions are:

ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
wlan: 0.8.4.5 (EXPERIMENTAL)
ath_rate_onoe: 1.0
ath_pci: 0.9.4.12 (EXPERIMENTAL)

My two test clients use HP W400 and W500 cards (running Windows XP Pro, and
stock drivers for the cards).

I've tested the madwifi driver with and without the patch, and get different
results based on the mode:

802.11b:

No stuck beacons observed after pushing several thousand pings between the AP
and the clients (with and without the patch).

802.11g:

Stuck beacon problem arises after only a minute or two. I need to reboot the AP
to continue. This happens with and without the patch).

802.11a:

Same as 802.11g

I wonder if other people have the same experience (no stuck beacons in mode 2,
and lots of stuck beacons in modes 1 and 3)? I don't know the madwifi code, so
it would be foolish for me to speculate on the reason for this.

Thanks for making the patch, but it seems it's not the answer (at least, not the
whole answer).

Cheers, Iain