bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More on oskit-mach booting troubles


From: Igor Khavkine
Subject: Re: More on oskit-mach booting troubles
Date: Sat, 21 Jul 2001 10:29:41 -0400
User-agent: Mutt/1.3.18i

On Fri, Jul 20, 2001 at 04:27:40PM -0400, Roland McGrath wrote:
> I suspect that what changed since the time it worked was that the oskit
> didn't always consult the BIOS information.  But that's just a guess and I
> haven't looked at the change histories.
> 
> I would be pretty intimidated by the idea of changing phys_mem_va to !=0.
> It would probably be fine in all the oskit stuff, but might well break vm.
> 
> I think the thing to do is save physical page 0 (not reuse it) and map it
> in some other part of the kernel va.  Then special-case that page in the
> oskit_mem_map_phys callback.

Although I favor creating a relative offset between the physical and
virtual memory, that's a bit more complicated to implement. I would
have to familiarize myself more with Mach's VM system, and to make
sure that phys_mem_va != 0 doesn't actually break anything.

So I tried remapping the 0th physical page elsewhere and special
casing that in osenv_phys_mem_map(). I pulled in the file
[oskit]/dev/mem.c from oskit and modified that function (otherwize
the linker would try to suck in mem.o from oskit's libs, and there
would be a symbol conflict).

The kernel does not crash at the same place anymore, but it still doesn't
boot. It hangs somewhere in oskit's (originally linux's)
ide_revalidate_disk() while initializing the CDROM (which it had trouble
recognizing earlier in the boot process). I'll try to step through
that and see what happens exactly. I'll keep everyone posted.

This problem might be related to the earlier one, or it might not be.
Could the information that the BIOS stored in the 0th page be unreliable
by the time it's used by the linux drivers?

Igor



reply via email to

[Prev in Thread] Current Thread [Next in Thread]