Date: Thu, 17 Jun 1999 16:04:45 -0500 (CDT) From: Jonathan Lemon <jlemon@americantv.com> To: tich@ma.ikos.com, current@freebsd.org Subject: Re: 4GB dram Message-ID: <199906172104.QAA22289@free.pcs> In-Reply-To: <local.mail.freebsd-current/99061716084400.14101@par28.ma.ikos.com> References: <local.mail.freebsd-current/199906171924.MAA09038@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-current/99061716084400.14101@par28.ma.ikos.com> you write: >On Thu, 17 Jun 1999, David Greenman wrote: >> >I still can't get a machine with 4GB dram to work. When was the last >> >time anyone succeeded in running -CURRENT on a machine with 4GB dram ? >> >This was working for me with 19990421-CURRENT, it doesn't work in >> >19990604-CURRENT. Since support for 4GB dram is the only reason >> >I'm running -CURRENT rather than -STABLE, I would really like to know >> >when this might get fixed. >> >> You need to provide more information - specifically, what happens when you >> try? >> >> -DG > >boot: kernel.4G -v >Too many holes in the physical address space, giving up This indicates too many discontinuties for the phys_avail[] array to handle; you can try increasing the array size in machdep.c. >As I've noted earlier, the getmemsize() code doesn't appear very safe >w.r.t. 4GB limits. I tried rewriting to simplify this code and avoid >these problems - with the rewritten version I got further, but then >had a different crash later (but that could be due to a bug in my >rewrite). The getmemsize() code first interrogates the BIOS in order to build up a map of physical memory; the BIOS returns the map as a 64bit quantity, which is then forced into vm_offset_t, a 32bit quantity on the x86. This map is then passed to some code which performs memory checking, and is given the chance to 'veto' some of the memory ranges (like where the kernel lives, or artificially by MAXMEM). The resulting map is stored in the phys_avail[] array, which is used by the rest of the pmap code. The older memsize code in effect only had two ranges: (page 1 - bottom of ISA hole), and (end of kernel - top of memory). The only significant difference for the new code is that it supports multiple ranges, so I'm a little unsure why it would be unsafe for 4GB. Can you capture the SMAP lines that are output during the boot process? The specific information regarding the kernel panic would help also. >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. > >Since the debugging is so painful, I would really like to find the latest >version that worked with 4GB, so that I can eyeball a minimal set of source >code changes. As dg said, can you bring the system up by limiting MAXMEM? (either build a custom kernel, or set MAXMEM with npx0 size). If I've inadverdently broken MAXMEM, I'd like to know about it. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906172104.QAA22289>