Re: rtfree: 0xc5caad98 has 2 refs

Hi Attila,

Attila Nagy wrote:
> Hello,
>
> I have an i386 7.0-PRERELEASE #12: Thu Dec 27 17:46:49 CET 2007, with 
> an em and two fxp interfaces in an IPv4-only setup with some jails and 
> a pf route-to (if that counts) line.
>
> The machine itself runs some mail related stuff (postfix, cyrus, 
> openldap, etc) on a ZFS pool.
>
> The problem is with the default kernel I get tons of similar messages:
> Dec 27 12:38:40 artax kernel: rtfree: 0xc5caad98 has 1 refs
> Dec 27 12:39:03 artax last message repeated 24 times
> Dec 27 12:39:03 artax kernel: rtfree: 0xc5caad98 has 2 refs
> Dec 27 12:39:03 artax kernel: rtfree: 0xc5caad98 has 1 refs
> Dec 27 12:39:04 artax last message repeated 64 times
> Dec 27 12:39:04 artax kernel: rtfree: 0
> Dec 27 12:39:04 artax kernel: xc5caad98 has 1 refs
> Dec 27 12:39:04 artax kernel:
> Dec 27 12:39:04 artax kernel: rtfree: 0xc5caad98
> Dec 27 12:39:04 artax kernel: has 1 refs
> Dec 27 12:39:04 artax kernel:
> Dec 27 12:39:04 artax kernel: rtfree: 0xc5caad98 has 1 refs
> Dec 27 12:39:04 artax kernel:
> Dec 27 12:39:04 artax kernel: rtfree: 0xc5caad98 h
> Dec 27 12:39:04 artax kernel: s 1 refs
> Dec 27 12:39:04 artax kernel:
> Dec 27 12:39:04 artax kernel: rtfree
> Dec 27 12:39:04 artax kernel: 0xc5caad98 has 1 refs
>
> Besides these messages fill up the logs and are annoying, the machine 
> crashes minutes after it has been started.
> I found out that replacing rtfree() calls in the kernel to 
> RTFREE_LOCKED() not only makes the above messages disappear, but helps 
> the machine to survive and run for days.
Look at this: http://www.freebsd.org/cgi/query-pr.cgi?pr=117913
>
> The only places where there are plain rtfree calls are in the kernel 
> (and where I've replaced them to RTFREE_LOCKED):
> net/route.c
> netinet/if_ether.c
> netinet6/nd6_nbr.c
> netinet6/in6_ifattach.c
> netinet6/in6_gif.c
>
> Question: is the above approach right and if it is, do anyone care to 
> make this replacement?
>
> BTW, how could I find out what causes these?
If it's not a production server and/or you can afford downtime add 
kbd_backtrace() to rtfree (in src/sys/net/route.c)
and you will see what cause the problem in your case.