From owner-freebsd-current Thu Jun 17 15:24:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 1676014FE0 for ; Thu, 17 Jun 1999 15:24:19 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id RAA24680; Thu, 17 Jun 1999 17:24:16 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id RAA16144; Thu, 17 Jun 1999 17:24:15 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id RAA22474; Thu, 17 Jun 1999 17:24:15 -0500 (CDT) Date: Thu, 17 Jun 1999 17:24:15 -0500 (CDT) From: Jonathan Lemon Message-Id: <199906172224.RAA22474@free.pcs> To: tich@ma.ikos.com, current@freebsd.org Subject: Re: 4GB dram X-Newsgroups: local.mail.freebsd-current In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >On Thu, 17 Jun 1999, David Schwartz wrote: >> > It's desperately painful to debug this, because as far as I know the >> > only way to get any kernel to boot is to power down the machine, >> > physically >> > unplug one of the dimms, power up again, install new kernel, power down, >> > plug the dimm back in ... If I could fit the kernel on a floppy the >> > debugging cycle would be much quicker, but it seems too big for that. >> >> Setting MAXMEM to 2Gb doesn't allow the kernel to boot? Perhaps there's >> something wrong with the way MAXMEM is implemented. >> >> DS > >I believe that MAXMEM doesn't work the way it used to - I think the trouble >is that getmemsize() now has a nested loop, and the way it looks at >Maxmem/MAXMEM doesn't do much to break it out of the outer loop. The outer loop walks through the list of physical memory segments. The inner loop walks through each page in the segment. The inner loop is terminated when we've hit the smaller of: 1. the end of one of the physical memory segments 2. our artifically constrained MAXMEM. The outer loop isn't terminated early, but if there are more physical segments after case 2 above, they are ignored, as the inner loop is completely skipped. Initially, we set Maxmem to the end of the last physical memory segment, so it's identical to case 1 above. I just built a kernel with a smaller MAXMEM than physical memory, and is appears to work as advertised, but then, I don't have 2-4G of memory in my machine. :-) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message