panic: kmem_map too small

[Scott Long]

Stefan Bethke wrote:
> 
> Am 25.10.2006 um 19:36 schrieb Robert Watson:
> 
>>
>> On Wed, 25 Oct 2006, Stefan Bethke wrote:
>>
>>> We're consistely getting this panic even under smallish loads.  I've 
>>> experimented with various values for VM_KMEM_SIZE_MAX (384, 512, 768 
>>> and 1024 MB), but the boxes are still panicking after even short 
>>> periods (a few hours) just doing a buildworld, a few ports compiles, 
>>> or even when logging out of the console(?).
>>>
>>> Would logging vm.zone every few minutes help detecting a kernel 
>>> memory leak?
>>>
>>> I'm at a complete loss as to the actual cause of these.  The ACPI 
>>> errors precede the panic below by only a few seconds, so I'd guess 
>>> they're a symptom, not a cause.  We've tried with ACPI disabled in 
>>> the BIOS, but we also got these panics, so we re-enabled it.
>>>
>>> The hardware is a Tyan GT20 (2865) with a single-core Opteron, two 
>>> gigs of RAM and two or three SATA disks.
>>>
>>> Any ideas?
>>
>> Try the commands "show uma" and "show malloc" in DDB to print the 
>> memory allocations made by the uma(9) and malloc(9) kernel memory 
>> allocators.  This output may be sufficient to suggest to us where a 
>> kernel memory leak, if any, might be taking place.  Also, a stack 
>> trace ("trace") never hurts; if something is sitting there allocating 
>> a lot of memory at high speed, it could well be that the last call to 
>> the memory allocator is the one leaking.
> 
> Thanks, see below.  I'll let it sit in the debugger, if someone has some 
> more ideas for what to look at.
> 
> This panic was triggered by me trying to ssh into the box; it had been 
> sitting idle since the last reboot around 1900 CEST.  Note that I had to 
> break into the debugger manually.  I'm assuming that the memory shortage 
> is so severe that dumping cannot be initiated, so the kernel hangs...
> 
> Thanks,
> Stefan
> 

There are no obvious culprits from what you posted.  The kernel was only 
trying to allocate 60 bytes, and the 64-byte bucket didn't look to be
overly used.  None of the other zones look terribly over-used either.
The 'show malloc' command doesn't really give enough stats to be 
terribly useful, IMHO.  And neither of the commands can effectively
track things like contig memory allocator.  Can you try the following
two commands:

vmstat -m
sysctl hw.busdma

Also, what version of FreeBSD is this?

Scott