Hi Andrew,
Here is the output with the symbols inserted. I can reproduce this memory leak very reliable now, by just activating the vis server (didn't do that with the logs I've posted before) in a couple of minutes. free is showing a nice countdown then :).
For kmemleak... I'm using 2.6.30.10 here and I think Torvalds merged it into 2.6.33 a month ago. Anyone having a 2.6.33 kernel running at the moment, patches for kmemleak in 2.6.30 or another idea of how to debug this in 2.6.30?
"Debug slab memory allocations" (CONFIG_DEBUG_SLAB) and "Memory leak debugging" (DEBUG_SLAB_LEAK) are activated on the kernel I'm using here, but they are not of any use, are they?
Cheers, Linus
On Sat, Jan 23, 2010 at 07:10:48PM +0100, Andrew Lunn wrote:
On Sat, Jan 23, 2010 at 06:46:16PM +0100, Linus L??ssing wrote:
Hey guys,
I've been installing a 9 node setup here in our cellar. They are all running B.A.T.M.A.N. adv 0.2.1-beta r1545 (so the current batman-adv maintance version in OpenWRT).
The result over night:
- 1x: bat_events: page allocation failure
This looks like a memory leak somewhere. It could be anywhere, batman or some other part of the kernel.
Can you build your kernel with the kernel memory leak detector enabled? It is under the Kernel Hacking options. You probably also need to build the kernel with symbols, which will help with ksymopps anyway. Documentation for kmemleak is in Documentation/kmemleak.txt. I've never used it myself, so i've no idea how good it actually is...
Interestingly, did you notice the warnings:
batman-adv:The newly added mac address (00:24:01:b7:6a:d2) already exists on: eth0.2 batman-adv:It is strongly recommended to keep mac addresses unique to avoid +problems!
I guess this is because you are using VLANs. Have you seen these problems without using VLANs?
Andrew