Date: Tue, 17 Dec 1996 18:55:12 +1100 From: Bruce Evans <bde@zeta.org.au> To: julian@whistle.com, terry@lambert.org Cc: eivind@dimaga.com, hackers@freebsd.org, jonny@mailhost.coppe.ufrj.br, tony@dell.com Subject: Re: Boot loader hacks was: Re: MAXMEM Message-ID: <199612170755.SAA13178@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> No; the kernel assumes what you tell it is true. If you use the >> MAXMEM option, you are eternally stuck with that memory for that >> particular kernel. Take it to a machine with more memory, and >> you don't use the extra; take it to a machine with less, and you >> are screwed. This has been fixed for a month or two. You can now set the memory size using `iosize npx0 whatever' in userconfig. >I added code to OSF1/x86 to look for more ram and add it to the ammount >reported by the bios.. it wasn't that hard!! > >the problem is that it needs to be done very early so that >an access to non-existant memory doesn't produce an NMI >when read from (on parity systems) or other similar problems.. The problem is that it can't be done in general. The main problem is that probing device memory may damage devices. Other problems include: - you have to distinguish read/write device memory from RAM. - you have to do something machine-dependent turn off the parity checking or handle NMIs very carefully. - you have to handle discontiguous memory. - you may have to handle mirrors (memory repeating every 256M or so). I'm not sure if this is a problem on 386 systems. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612170755.SAA13178>