From owner-freebsd-current Fri Nov 15 5: 2:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7611037B401 for ; Fri, 15 Nov 2002 05:02:08 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66E1A43E75 for ; Fri, 15 Nov 2002 05:02:07 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gAFD212q014085; Fri, 15 Nov 2002 05:02:01 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gAFD21Js014084; Fri, 15 Nov 2002 05:02:01 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Fri, 15 Nov 2002 05:02:01 -0800 From: David Schultz To: Bruce Evans Cc: Mitsuru IWASAKI , gallatin@cs.duke.edu, petry@NetMasters.Com, julian@elischer.org, sidcarter@symonds.net, current@FreeBSD.ORG Subject: Re: Kernel not booting....Immediate crash Message-ID: <20021115130201.GA14000@HAL9000.homeunix.com> Mail-Followup-To: Bruce Evans , Mitsuru IWASAKI , gallatin@cs.duke.edu, petry@NetMasters.Com, julian@elischer.org, sidcarter@symonds.net, current@FreeBSD.ORG References: <20021109214141.GA8555@HAL9000.homeunix.com> <20021115230332.L14273-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021115230332.L14273-100000@gamplex.bde.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Bruce Evans : > Perhaps the problem with int 0x12 is the same as the one with int 0x15. > Old implementations of int 0x12 just read the word at 0x40:0x13 in > real or vm86 mode. This only requires physical page 0 to be mapped > readable to work in vm86 calls. New implementations might want more. > They could reasonably expect all of the first MB of physical memory > to be mapped r/w into vm86 space. It's not clear that any BIOS call > works in vm86 mode. BIOS calls could unreasonably expect to access > all of memory as if in real mode (e.g., they could stash their variables > in extended memory and use the himem hack or a switch to protected > mode to access them). Could be. I would hope that mapping page 0, the BIOS data segment, and the EBDA would solve the problem, but there's still a chicken-and-egg problem with doing this in vm86 mode. I haven't heard any additional details from Iwasaki-san, but making the memory determination in vm86 mode seems fundamentally broken regardless. > > Also, you mentioneded earlier that Linux doesn't use int 12h > > anymore. But notice that they call 15:E820 in real mode, rather > > than turning on virtual memory and then temporarily mapping an > > arbitrary chunk of the first 640K of RAM. Why don't you just put > > the memory size detection code in locore.s? I'd be happy to help > > out with this, although my time is constrained after Monday. > > locore.s runs entirely in protected mode. It could switch between > real and protected mode like the boot code does, but that would defeat > the point of the (not very well designed) division of labour between > the boot code and locore -- the complications for real mode are > supposed to be limited to the boot code. Of course, they have been > replaced by larger complications and bugs for vm86 mode :-(. More > in another reply. That is why I'm surprised by your earlier post where you say that it's a bad idea to take the basemem value from the boot code. As it is, the kernel duplicates much of the memory determination code of the boot loader. I would think it could at least rely on bootinfo.bi_basemem when that field is nonzero. If these values in bootinfo are going to remain unused, they should be removed, but I think a far better solution is to start using them. In fact, the interface could be extended to pass the int 15h:e820h memory map to the kernel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message