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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
