Date: Sun, 7 Mar 2004 02:06:51 -1000 (HST) From: Vincent Poy <vince@oahu.WURLDLINK.NET> To: Andre Guibert de Bruet <andy@siliconlandmark.com> Cc: current@freebsd.org Subject: Re: -CURRENT kernel panic Message-ID: <20040307020010.N8264-100000@oahu.WURLDLINK.NET> In-Reply-To: <20040307052158.D21071@alpha.siliconlandmark.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 7 Mar 2004, Andre Guibert de Bruet wrote: > On Sun, 7 Mar 2004, Vincent Poy wrote: > > On Sun, 7 Mar 2004, Andre Guibert de Bruet wrote: > > > On Sat, 6 Mar 2004, Vincent Poy wrote: > > > > > > > > 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. ;-) > > > > Okay, here's a dumb question. If it uses the less of the two > > numbers, is there a reason to need to even define the VM_KMEM_SIZE_SCALE > > since wouldn't by default, it be 1/3rd of your RAM anyways? > > The SCALE value is there to protect in the case of systems that might have > memory amounts that change. If you had a set value for your KMEM which is > larger than the amount of memory available when RAM is pulled out, your > kernel would surely not boot. For short, the SCALE value lets you get > creative with the size assigned to your KMEM. Yeah but assuming the SCALE value was the default of 3 and you had 768MB of RAM, your SCALE would still be higher than the KMEM undefined which is 200MB. > You might find the following mail interesting: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2003-06/1599.html Actually, I read that portion already since I saw it in one of your posts in the archives. > > > 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 > > > > You're right that anything above 384MB using a scale of 2, the > > kernel would panic as soon as the Real Memory is posted in the boot. Did > > this problem actually exist recently because prior to February 28, I was > > on a September 26, 2003 -CURRENT and it has not had the problem. I'm > > using maxusers=512 in the kernel as well as 65536 NMBCLUSTERS, it used to > > be 32768 but I thought that was what was causing the panic. > > This problem has been around since at least June of last year, which is > the date that I first had a test system with more than 1GB running CURRENT > (All my production systems still track STABLE). When I searched the lists, it seemed to happen for people in January 2004 and later though. Maybe the problem wasn't as big though. June 14, 2003 was when I first installed -CURRENT on the machine and it originally did have 128MB only but then I got 2 1GB SODIMM's sometime in early September and the last -current I did was September 26 and the system had stayed up for atleast a month until I actually rebooted it. It wasn't until I did a -CURRENT upgrade beginning with the February 28, 2004 -CURRENT that seemed to have this issue. Maybe the newer -CURRENT's are just more sensitive to this problem. Hopefully this problem eventually gets fixed though. > > > As with everything, backup your data, put on your fire-retarding suit, and > > > YMMV. :-) > > > > Nah, the kernel one doesn't require backing up the data since the > > only reason I get the panic is because I'm dumping both / and /usr to > > another identical drive. It's only doing the /boot/loader.conf variable > > for kmem that's scary. ;) > > Loader tunables for this type of thing scare me too. I guess we're just > old school... Yeah, since there is no such thing as loading a /boot/loader.conf.old ;) Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040307020010.N8264-100000>