Date: Sat, 23 Aug 1997 18:49:37 +0200 From: Tor Egge <Tor.Egge@idi.ntnu.no> To: gordon@drogon.net Cc: hackers@FreeBSD.ORG Subject: Re: Problems with > 256MB of RAM [what worked & what didn't] Message-ID: <199708231649.SAA06260@pat.idi.ntnu.no> In-Reply-To: Your message of "Sat, 23 Aug 1997 14:46:46 %2B0100 (BST)" References: <Pine.LNX.3.95.970823144610.10666D-100000@unicorn>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Tor Egge <Tor.Egge@idi.ntnu.no> suggested: > > There are two main reasons for this type of panic > > > > 1. temporary shortage of free physical memory (cf PR#2431). > > > > Use sysctl to increase limits of reserved free physical > > memory, reducing the probability for running out of free memory. > > > > sysctl -w vm.v_free_reserved=1024 > > sysctl -w vm.v_free_min=1500 > > This worked. > > Tor also suggested: > > 2. permanent shortage of virtual memory allocated for pv entries. > > > > Increase the size of allocated virtual memory for pv entries > > by adding: > > > > options "PMAP_SHPGPERPROC=400" > > This didn't work. Upping it to 800 didn't work either. Same panic at the > same place. Both problems are capable of causing the panic by itself. Applying a workaround for problem #2 and not for problem #1 when problem #1 occurs will prevent the panic. problem #1 normally occurs during fork of a process with a large resident set (several hundred megabytes). problem #2 normally occurs when you have many processes with the same data mapped into memory (several hundred megabytes), and all the processes have accessed most of that data. If you have *very* many processes sharing the same data, the workaround for problem #2 might cause problem #3, reported in PR#1880 (panic: kmem_suballoc: bad status return of 3). > John S. Dyson <toor@dyson.iquest.net> suggested changing NKPDE in pmap.h > (DG's patch bumped this from 63 to 127). I upped it to 255. Didn't work. > Machine didn't even boot! Stopped at: > > Boot: > dosdev= 80, biosdrive = 0, unit = 0, maj = 0 > Booting 0:wd(0,a)/kernel @ 0x100000 > text=0x8f000 data=0xc000 bss=0xd484 symbols=[+0xb7c+0x4+0xc378+0x4+0x10169] > total=0x1c54e9 entry point=0x100000 > > Needed a hardware reset. But that is trying to apply a workaround for problem #3, not problem #2 or problem #1, which are the two problems related to `panic: get_pv_entry: cannot get a pv_entry_t'. If you bump NKPDE to 255, you need to change LOAD_ADDRESS to C0100000 in sys/i386/conf/Makefile.i386. Did you do that ? - Tor Egge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708231649.SAA06260>