Sam Leffler wrote:
Boris Kochergin wrote:
Stef Walter wrote:
Boris Kochergin wrote:
I, too, recall the days when you had multiple rate-control algorithms to
choose from, but that doesn't appear to be the case anymore. As a
workaround, I wrote a little script that checks if that part of the
driver is using more than 200 KiB of memory and run it every minute via
cron. It seems to be doing its job so far:
You can still select the ath rate control module. Static kernel config
is unchanged; for modules you must export ATH_RATE=onoe or similar
(check modules/ath/Makefile). Please file a PR if this does not work.
Sam
(I had to go do some other stuff, but better late than never?)
Thanks. That does indeed work, but the problem persists with other
rate-control algorithms (I've upgraded most of the access points to
8.0-R, where the problem does not appear to exist, and upgraded one to
7.3-R for continued testing--this is where it still happens). I've
instrumented the memory-allocation bits in the ath and net80211 code
where MALLOC/malloc was called with a type of M_80211_NODE. I've tracked
the leak down to one of two allocations never being freed:
Line 595 of /usr/src/sys/net80211/ieee80211_node.c:
MALLOC(ni, struct ieee80211_node *, sizeof(struct ieee80211_node),
M_80211_NODE, M_NOWAIT | M_ZERO);
Line 3164 of /usr/src/sys/dev/ath/if_ath.c:
an = malloc(space, M_80211_NODE, M_NOWAIT|M_ZERO);
It looks like both are supposed to be freed by node_free() in
/usr/src/sys/net80211/ieee80211_node.c, but there is some code path
where that doesn't happen, and should. Hopefully, this helps someone
familiar with the code track it down. I may try it at some point, but it
intimidates me somewhat.
-Boris
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
