Kris Kennaway wrote, on 7/22/2008 12:12 PM: > Royce Williams wrote: > >> db> trace >> Tracing pid 71182 tid 100325 td 0xcc08b180 >> kdb_enter(c095f294) at kdb_enter+0x2b >> panic(c09768ad,1000,14000000,c145bc88,1000,...) at panic+0x127 >> kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 > > You forgot to include the panic
Is there is a way to get the panic after dropping into the debugger? This serial console setup has no scrollback, so I couldn't see the preceding text. > but this is probably the "kmem_map too small" panic. Ah, I see this now, at faq/book.html#KMEM-MAP-TOO-SMALL: "Compile your own kernel, and add the VM_KMEM_SIZE_MAX to your kernel configuration file, increasing the maximum size to 400 MB (options VM_KMEM_SIZE_MAX=419430400). 400 MB appears to be sufficient for machines with up to 6 GB of memory." > It says that your kernel ran out of memory, and the > solution is to fix that situation by giving more memory to the kernel. > Increase the vm.kmem_size tunable until your system stops running out of > memory on your workload. Comparing the FAQ, kern_malloc.c and your mentioning it as tunable, please clarify: is the Right Thing to do to use vm.kmem_size, or vm.kmem_size_max? I tried vm.kmem_size_max, which yields: # sysctl -a | grep kmem vm.kmem_size: 419430400 vm.kmem_size_max: 419430400 vm.kmem_size_scale: 3 Should I contribute some additional language to the FAQ, saying that the vm.kmem_size[_max] tunable can be used without recompiling the kernel? Royce -- Royce D. Williams - http://royce.ws/ Reproof should not exhaust its power upon petty failings. - S. Johnson _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
