Thus spake Bruce Evans <[EMAIL PROTECTED]>: > 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
