From owner-freebsd-hackers Mon Dec 16 23:58:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA07226 for hackers-outgoing; Mon, 16 Dec 1996 23:58:02 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA07220 for ; Mon, 16 Dec 1996 23:57:55 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id SAA13178; Tue, 17 Dec 1996 18:55:12 +1100 Date: Tue, 17 Dec 1996 18:55:12 +1100 From: Bruce Evans Message-Id: <199612170755.SAA13178@godzilla.zeta.org.au> To: julian@whistle.com, terry@lambert.org Subject: Re: Boot loader hacks was: Re: MAXMEM Cc: eivind@dimaga.com, hackers@freebsd.org, jonny@mailhost.coppe.ufrj.br, tony@dell.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> 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