Stef Walter wrote:
Boris Kochergin wrote:
_______________________________________________
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"
More information: I upgraded it to a 7.2-STABLE with August 20th sources
and increased kern.ipc.nmbclusters to 65536 in hopes of getting the
panic less often. I managed to catch it in a state where there were a
bunch of "ath0: ath_rx_proc: no mbuf!" messages in the kernel buffer.
One line of "vmstat -m" stood out as the leak:
80211node 12677 101401K - 120901 16,512
"ifconfig ath0 down" freed the memory. Is there any other useful
information I can provide if I catch it again? Someone suggested the
output of "vmstat -z" off list, and I will have that next time.
This might be a long shot:
Back when I deployed some similar devices on FreeBSD 6.0 there was a
leak when using oddball ath_rate driver. I believe it went away when I
used ath_rate_sample. But according to 'man 4 ath' nothing else besides
ath_rate_sample exists anymore.
Cheers,
Stef
_______________________________________________
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"
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:
#!/bin/sh
memory=`vmstat -m | grep "80211node " | tr -s ' ' | cut -f4 -d' ' | sed
's/[^0-9]//g'`
if [ $memory -gt 200 ]; then
ifconfig ath0 down && ifconfig ath0 up
fi
-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"
