[ath5k-devel] Backoff persistence and threshold
Hi, I have been browsing the driver code for some backoff related stuff. Specifically, I am looking for a way to count the number of backoffs on AR5212 based cards. I have seen a backoff count register for AR5210 but cannot find any such thing for AR5212. Also, what is Backoff persistence factor and Backoff threshold? I understand what backoff is but I have no idea what persistence means here. Apparently, the driver does not make use of this register and trying to look for some more information in Sam's openhal didn't help. I would really appreciate if someone can provide me more information about these registers and whether it is possible to count the number of backoffs on AR5212 cards. #*define* AR5K_DCU_MISC_BACKOFF_PERSIST http://wifi-dev:8080/source/s?refs=AR5K_DCU_MISC_BACKOFF_PERSISTproject=/wireless-testing 0x1000 /* Persistent backoff */ #*define* AR5K_DCU_MISC_BACKOFF http://wifi-dev:8080/source/s?refs=AR5K_DCU_MISC_BACKOFFproject=/wireless-testing 0x003f /* Mask for backoff threshold */ Thanks, -Qasim ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] MORE INFO: ath5k and .local dropout
Some new observations: If I restart avahi the .local computers are once again accessable (pingable). If I ping nimby.local (the computer with ath5k wireless card) it will work for about 120 seconds (aka 2 minutes). Then nimby.local is no longer resolvable to a IP address. Is 2 minutes or 120 seconds important somewhere in the ath5k code? (The amount of time is the same if running ping on nimby.local rather pinging nimby.local.) Output of ping: 64 bytes from nimby.local (192.168.1.6): icmp_seq=113 ttl=64 time=2.78 ms 64 bytes from nimby.local (192.168.1.6): icmp_seq=114 ttl=64 time=3.52 ms 64 bytes from nimby.local (192.168.1.6): icmp_seq=115 ttl=64 time=3.65 ms 64 bytes from nimby.local (192.168.1.6): icmp_seq=116 ttl=64 time=1.79 ms 64 bytes from 192.168.1.6: icmp_seq=117 ttl=64 time=2.17 ms 64 bytes from 192.168.1.6: icmp_seq=118 ttl=64 time=1.56 ms ^C64 bytes from 192.168.1.6: icmp_seq=119 ttl=64 time=1.91 ms --- nimby.local ping statistics --- 119 packets transmitted, 118 received, 0% packet loss, time 134157ms rtt min/avg/max/mdev = 1.266/36.055/2297.948/242.227 ms, pipe 3 $ ping nimby.local ping: unknown host nimby.local Thanks again! C. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k and .local dropout
On Mon, Nov 02, 2009 at 07:09:29PM -0500, CSights wrote: Hello, I'm having a problem with the ath5k module found in kernel 2.6.31.5 and accessing .local addresses on the network. I'm not too familiar with avahi but I guess the .local is some kind of multicast thing... does this help? I can't think of a good reason to zero the mcast hash after a reset. diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c index 1287ded..1e6e0b6 100644 --- a/drivers/net/wireless/ath/ath5k/base.c +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -1125,7 +1125,6 @@ ath5k_mode_setup(struct ath5k_softc *sc) /* configure operational mode */ ath5k_hw_set_opmode(ah); - ath5k_hw_set_mcast_filter(ah, 0, 0); ATH5K_DBG(sc, ATH5K_DEBUG_MODE, RX filter 0x%x\n, rfilt); } -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k and .local dropout
I'm not too familiar with avahi but I guess the .local is some kind of multicast thing... does this help? I can't think of a good reason to zero the mcast hash after a reset. diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c index 1287ded..1e6e0b6 100644 --- a/drivers/net/wireless/ath/ath5k/base.c +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -1125,7 +1125,6 @@ ath5k_mode_setup(struct ath5k_softc *sc) /* configure operational mode */ ath5k_hw_set_opmode(ah); - ath5k_hw_set_mcast_filter(ah, 0, 0); ATH5K_DBG(sc, ATH5K_DEBUG_MODE, RX filter 0x%x\n, rfilt); } YES! At least I am able to ping for longer than 2 minutes. :) I'll keep running the modified code and see if any other problem crops up. Thanks! C. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
