Date: Thu, 26 Oct 2006 14:37:39 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Stefan Bethke <stb@lassitu.de> Cc: Andreas Sons <sons@zs64.net>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: panic: kmem_map too small Message-ID: <20061026143337.L29443@fledge.watson.org> In-Reply-To: <E4AD8D20-E934-4E3E-9485-FE4985CDF57A@lassitu.de> References: <CD619308-6B7B-4B68-B011-CE979D67E0C1@lassitu.de> <20061025183308.L33725@fledge.watson.org> <838FCA83-20F8-4A09-A025-E69956032F86@lassitu.de> <45400286.9020402@samsco.org> <20061026091253.J69980@fledge.watson.org> <20061026111723.K33725@fledge.watson.org> <20152564-EC53-4210-9590-23817A6A3E42@lassitu.de> <E4AD8D20-E934-4E3E-9485-FE4985CDF57A@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Oct 2006, Stefan Bethke wrote: > acpica 3024 159K 20026966 ... > db> show uma > Zone Allocs Frees Used Cache > 64 9990754 9986054 4700 9980755 Looks like acpica has gone crazy performing allocation/freeing at a very high rate, and that for some reason, UMA is failing to properly reuse/release memory. So there are two bugs/problems here: whatever is causing ACPI to behave this way, and then the fact that UMA is failing to deal properly with its misbehavior. Alternatively, that we have a bug in the way statistics are handled. If you can generate a coredump, it would be quite useful to be able to run umstat (src/tools/tools/umastat in HEAD) on it. The tool probably needs a bit of tweaking to run on the core dump -- in particular, the first and second arguments of kvm_open() need to be the name of the kernel and dumpfile, rather than NULL. This would help confirm what actual state UMA is in. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061026143337.L29443>