Date: Fri, 15 Nov 2002 23:24:27 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Schultz <dschultz@uclink.Berkeley.EDU> 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: <20021115230332.L14273-100000@gamplex.bde.org> In-Reply-To: <20021109214141.GA8555@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Nov 2002, David Schultz wrote: > Thus spake Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>: > > Hmmm, I didn't notice that there is a BIOS which requires > > memory area below 640K even when calling INT 15H/E820. > > > > We cannot trust that today's BOISes have INT 12H, so it's > > difficult to determine base memory size w/o INT 15H/E820. > > You keep saying this, which really surprises me, because the int > 12h interface has been standard for over two decades. I have not > heard any great clammoring that DOS and NetBSD fail to boot on > modern machines, and yet they both use int 12h. Are you *sure* > int 12h is really broken, or do you think perhaps the breakage > you're seeing is a side-effect of another bug? Does int 12h work > in real mode? Exactly what hardware has this problem? 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). > 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. Bruce 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?20021115230332.L14273-100000>