tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/38019: some kind of undetected deadlock slowly kills NetBSD-4.0_STABLE GENERIC.MP



I think I may have been mistaking two different problems on my Dell
server.  I think my ongoing problems with lockups may actually be due to
possible starvation of kernel virtual space on large-memory (i386)
systems, while other crashes (PR# 38246, for example) are possibly
locking and/or SA related.

I was going though an old 3.0 kernel config for a client machine,
preparing to build it on the netbsd-4 and noted that I had applied the
3.0 LAST_MINUTE hack to adjust KERNBASE_LOCORE as that machine has 4GB
of RAM.  Remembering this, noting that my PE2650 also has 4GB of RAM,
and given that the last few hangs always show processes stuck in
vmmapva, I've begun to wonder if maybe this hack might still be
necessary in netbsd-4 too.

I'm rebuilding my netbsd-4 and wrstuden-fixsa kernels now with the
following in hopes it helps my machine make it safely through the
nightly cron jobs.

I would welcome any comments on this issue, especially suggestions as to
whether or not I might be on the right track here....

# Machines configured with more than 2 GB of physical memory may
# experience hangs due to running out of kernel virtual space, which
# is needed for kernel data structures such as file system metadata
# buffers.  Various kernel subsystems (including the file system
# metadata cache) automatically adjust their memory usage based on the
# amount of physical memory in the system, but this method
# over-allocates the available kernel virtual space (1 GB) when the
# amount of physical memory greatly exceeds the amount of kernel
# virtual space.
# 
# The only reliable workaround currently known for this problem is to
# increase the amount of virtual space available to the kernel by
# adding the following line to the kernel config file.
# 
# This will increase the kernel virtual space to 2 GB, but this has
# the drawback that the application virtual space is decreased from 3
# GB to 2 GB (since the 32-bit address space supported by the hardware
# must be shared between the kernel and application on this
# architecture).
#
#options KERNBASE="0xc0000000UL"        # start of kernel virtual space
options KERNBASE="0x80000000UL"



-- 
                                                Greg A. Woods
                                                Planix, Inc.

<woods%planix.com@localhost>     +1 416 489-5852 x122     http://www.planix.com/

Attachment: pgpVau_NR_mg2.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index