Re: -CURRENT kernel panic

On Sat, 6 Mar 2004, Vincent Poy wrote:
> On Sat, 6 Mar 2004, Vincent Poy wrote:
> > 	It seems to do it on the dump of /usr and restoring to /mnt/usr.
> > I have tried the following but they panic the kernel as soon as the memory
> > size is displayed.
> >
> > added to kernel config:
> > options         VM_KMEM_SIZE_MAX=(768*1048576)
> > options         VM_KMEM_SIZE_SCALE=2
> >
> > Tried it on a kernel without the above but added in /boot/loader.conf
> >
> > vm.kmem_size=429391872
> >
> > and they both crashed at the same spot as well...
> >
> > CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.60GHz (2592.36-MHz 686-class CPU)
> >   Origin = "GenuineIntel"  Id = 0xf29  Stepping = 9
> >
> > Features=0xbfebf9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P
> > AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > real memory  = 2147360768 (2047 MB)
> > avail memory = 2095669248 (1998 MB)
> >
> > 	Any ideas how to fix this?
>
> 	I managed to get the system not panicing on bootup if I set the
> VM_KMEM_SIZE_MAX to 384MB.  At 512MB and 768MB, it would panic but anyone
> knows what the default VM_KMEM_SIZE_MAX size is?

That's the maximum amount of KMEM that your system can have. Let's say for
example that you have a system with 4GB of RAM. You set VM_KMEM_SIZE_MAX
to 1GB but VM_KMEM_SIZE_SCALE to 8 you get:

VM_KMEM_SIZE_MAX: 1024 MB of KMEM
VM_KMEM_SIZE_SCALE: 512 MB of KMEM (4096/8)

The algorithm uses the lesser of these two numbers. Remember that a whole
lot of things use the allocated memory so don't skimp! If you don't want
to use the memory in your system, take it out and set it on the desk. ;-)

I've found through personal experience and endless hours of experimenting
on fairly busy machines that the following values work for the various RAM
configurations (Lower values may also work depending upon disk, net and
load):

RAM		KMEM size
4.0GB		768MB
3.5GB		768MB
3.0GB		512MB
2.5GB 		384MB
2.0GB		384MB
1.5GB and below	256MB

As with everything, backup your data, put on your fire-retarding suit, and
YMMV. :-)

Regards,
Andy

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/    >