Re: kern/54908: kernel semi-lock-up

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

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

From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
To: Lars Reichardt <lars%paradoxon.info@localhost>, Andrew Doran <ad%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, martin%NetBSD.org@localhost
Subject: Re: kern/54908: kernel semi-lock-up
Date: Sat, 1 Feb 2020 10:30:55 +0000

 On 01/02/2020 07:59, Lars Reichardt wrote:
 [snip]
 
 > Most pools allocate from the kmem arena the non exhaustive list of
 > exceptions I remember are:
 > - the buffer caches do have a special pool_allocator backend
 > - execargs
 > - uarea
 
 I added pmap_l1tt_cache recently which has it's own pool_allocator
 
 http://src.illumos.org/source/xref/netbsd-src/sys/arch/arm/arm32/pmap.c#65=
 80
 
 Along with this new pool I dropped the page size from 8KB to 4KB.
 
 [snip]
 > Martin gave it try with the kmem arena limit raised
 > to 256mb but the system didn't boot which puzzels me as it seems to have
 > 2g kvm.
 
 I just tried with qemu and it booted with 256MB. I'll try real hardware.
 
 While working on the pmap_l1tt_cache/4KB page size change I noticed bugs
 in pmap_growkernel and in the initial kernel VM setup.  Maybe there are mo=
 re
 bugs here.
 
 
 > The reason for this is 128M for kmem isn't much for 2g physical memory
 > eg i386 raises this to about 320mb some others to 256mb.
 
 I'm happy to bump this for _ARM_ARCH_6, i.e. modern arm after fixing the
 problem Martin saw with it.
 
 Nick