Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Nov 2003 11:23:30 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        Kevin Oberman <oberman@es.net>
Cc:        current@freebsd.org
Subject:   Re: Kernel memory leak in ATAPI/CAM or ATAng?
Message-ID:  <Pine.NEB.3.96L.1031106111952.3700A-100000@fledge.watson.org>
In-Reply-To: <20031106160831.4D10F5D07@ptavv.es.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 6 Nov 2003, Kevin Oberman wrote:

> I have learned a bit more about the problems I have been having with
> the DVD drive on my T30 laptop. When I have run the drive for an
> extended time (like 2 or 3 hours), I invariably have my system lock up
> because it can't malloc kernel memory for the ATAPI/CAM or ATA
> device. (Usually it's both.)
> 
> The only recovery seems to be to reboot the system.

Is it possible to drop to DDB and generate a coredump at that point?  If
so, you can run vmstat on the core to look at memory use statistics in a
post-mortem way.  As to what to look for: "big numbers" is about the limit
of what I can suggest, I'm afraid :-).  Usually the activity of choice is
to compare vmstat statistics (with -m and -z) during normal operation and
when the leak has occurred, and look for any marked differences.  It's
worth observing that there are two failure modes here that appear almost
identical: (1) a memory leak resulting in address space exhaustion for the
kernel, and (2) a tunable maximum allocation being too high for the
available address space.  Note that (2) isn't a leak, simply a poorly
tuned value.  We've noticed a number of tuned memory limits were set when
memory sizes on systems were much lower, and so we've had to readjust the
tuning parameters for large memory systems.  Likewise, a number of
problems were observed when PAE was introduced, as some of the tuning
parameters scaled with the amount of physical memory, not with the
addressable space for the kernel.  So we probably want to be on the look
out for both of these possibilities.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031106111952.3700A-100000>