Date: Mon, 25 Nov 2002 02:21:36 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Kenneth Culver <culverk@yumyumyum.org> Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Wierd message followed mem prob Message-ID: <3DE1F9B0.19CEAB5F@mindspring.com> References: <20021125044616.E24473-100000@alpha.yumyumyum.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kenneth Culver wrote: > This is in addition to my last mail. Just to reiterate, I'm using > FreeBSD 4.7-STABLE as of a few days ago, and I've never seen this problem > before. The wierd message comes from /usr/src/sys/i386/i386/machdep.c: > > "Too many holes in the physical address space, giving up" > > It prints before even the copyright message on bootup. Second is (I think > as a result of this message) My total memory is too small by over 100M (I > have 512M): Your physical memory map is laid out such that it has holes in; in general, the code, as written, can tolerate up to 7 holes... 8 discontiguous chunks. In a properly functioning system, you will not have more than that, and will generally have much less (the number goes up if 384K is remapped from expansion RAM to back-fill the "hole" above 640K; in general, you should turn this off in the BIOS, if you can, unless you are multibooting the system in DOS, and are using QEMM or a similar TSR to access expansion RAM). In general, the message is mostly harmless. What it means is that there is some physical memory that was not mapped into the address space as a known chunk, because of regions within memory that have been "mapped out" -- "holes". You lose access to chunks above the last chunk. If it's complaining about holes, rather than segments, then it means that "INT 15:E820" is succeeding without leaving anything out, but that the number of holes detected are larger than the number of holes that the BIOS knows about -- there is a mismatch -- and that the number of holes is greater than 8. The number of holes available to be mapped this way are limited to PHYS_AVAIL_ARRAY_END. By default, this will be 8... the maximum number supported is limited by the index for the declaration of the phys_avail[] array, minus 2 (default: 10). You can increase this number by modifying the "10" in the phys_avail[] array declaration. You may want to try jumping it up to 20, and recompiling the kernel (the declaration is around line 206 of /sys/i386/i386/machdep.c). In general, this is a bad way to work around the problem. If you have many detected holes like this in your address space, it is usually indicative of a hardware problem. This is usually either a brocken interior address line (but above a page worth of bits - bit 12) in the memory bus circuitry, or a broken RAM chip and/or bad connections on a SIMM. NB: Given address space layout on PC's, the algorithm would lose less total RAM in the situation where it has chunk issues like this, if it started from the top down, instead of the bottom up, since the "chunkiness" will be found below 540K and/or in the bus I/O address space. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE1F9B0.19CEAB5F>