From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 06:22:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 214B0AB1 for ; Sun, 23 Dec 2012 06:22:37 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9608FC13 for ; Sun, 23 Dec 2012 06:22:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id qBN6MODF077928; Sun, 23 Dec 2012 17:22:25 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 23 Dec 2012 17:22:24 +1100 (EST) From: Ian Smith To: Sergey Kandaurov Subject: Re: 9.1 minimal ram requirements In-Reply-To: Message-ID: <20121223150954.B81991@sola.nimnet.asn.au> References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Marten Vijn , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 06:22:37 -0000 On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote: > On 23 December 2012 03:40, Marten Vijn wrote: > > On 12/23/2012 12:27 AM, Jakub Lach wrote: > >> > >> Guys, I've heard about some absurd RAM requirements > >> for 9.1, has anybody tested it? > >> > >> e.g. > >> > >> http://forums.freebsd.org/showthread.php?t=36314 > > > > > > jup, I can comfirm this with nanobsd (cross) compiled > > for my soekris net4501 which has 64 MB mem: > > > > from dmesg: real memory = 67108864 (64 MB) > > > > while the same config compiled against a 9.0 tree still works... Same as the first message in that forum thread, I tried installing from i386 9.1-RC3 memstick on a PIII-M with 128MB RAM (Thinkpad T23) and it panics just a few percent into extracting base.txz, much to my surprise. I had a 256MB stick and was going to try that instead, but was in a bit of a hurry so just added it for 384MB and have had no further trouble, but haven't done anything much with it yet, no X or other packages. However the same forum user 'Zav' later reports the same panic at 2.5d uptime with 320MB, after earlier panics with 192MB post-installation when 'trying to do something', so I'm wondering if even 256MB is enough for 9.1? .. scratch my ambition to upgrade an older maxed-out 160MB laptop that runs fine on 5.5 w/X, KDE and all, albeit using some swap. > This (i.e. the "kmem_map too small" message seen with kernel memory > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > quite a big kernel memory consumer. > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. I've just added that, thanks Sergey, but it's sadly not an option for installation. I guess it's too late for the release notes - which at RC3 made no mention of CAM CTL at all - but it's not yet clear to me whether even 256MB is enough to boot, install and run 9.1 GENERIC? > A longer term workaround could be to postpone those memory allocations > until the first call to CTL. Under what circumstances is CAM CTL needed? What would leaving it out of GENERIC cost, and whom? Is it loadable? dmesg.boot reports loading, but I don't see a module, nor can I find much information about CTL in cam(3|4) or /sys/conf/NOTES. apropos found ctladm and ctlstat, but I'm little the wiser as to when it may be needed, beyond CAM/SCSI debugging? > # cam ctl init allocates roughly 35 MB of kernel memory at once > # three memory pools, somewhat under M_DEVBUF, and memory disk > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > Type InUse MemUse HighUse Requests Size(s) > devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 > ctlmem 5062 10113K - 5062 64,2048 > ctlblk 200 800K - 200 4096 > ramdisk 1 4096K - 1 > ctlpool 532 138K - 532 16,512 > > -- > wbr, > pluknet cheers, Ian