Date: Fri, 15 Nov 2002 05:02:01 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Bruce Evans <bde@zeta.org.au> Cc: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>, 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> In-Reply-To: <20021115230332.L14273-100000@gamplex.bde.org> References: <20021109214141.GA8555@HAL9000.homeunix.com> <20021115230332.L14273-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Bruce Evans <bde@zeta.org.au>: > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021115130201.GA14000>