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

["Greg A. Woods" <woods%planix.com@localhost>]

The following reply was made to PR kern/38019; it has been noted by GNATS.

From: "Greg A. Woods" <woods%planix.com@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: NetBSD Kernel Technical Discussion List <tech-kern%NetBSD.org@localhost>, 
NetBSD/i386 Discussion List <port-i386%NetBSD.org@localhost>
Subject: Re: kern/38019: some kind of undetected deadlock slowly kills 
NetBSD-4.0_STABLE GENERIC.MP
Date: Fri, 04 Apr 2008 15:16:31 -0400

 --pgp-sign-Multipart_Fri_Apr__4_15:15:53_2008-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 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.
 #=20
 # 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.
 #=20
 # 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=3D"0xc0000000UL"     # start of kernel virtual space
 options KERNBASE=3D"0x80000000UL"
 
 
 
 --=20
                                                Greg A. Woods
                                                Planix, Inc.
 
 <woods%planix.com@localhost>     +1 416 489-5852 x122     
http://www.planix.com/
 
 --pgp-sign-Multipart_Fri_Apr__4_15:15:53_2008-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNATURE-----
 Version: PGPfreeware 5.0i for non-commercial use
 MessageID: NSl8FXdY2IO6In60dddHziKnfh5LoK2c
 
 iQA/AwUBR/Z+j2Z9cbd4v/R/EQJYxwCfflIQnfX2wogWSzX3f4nRjmXvZO8AoI1K
 e6Ou066f/O0d3moXgmr5DVxL
 =FkAm
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Fri_Apr__4_15:15:53_2008-1--