More on oskit-mach booting troubles

[Igor Khavkine]

This is a summary of what I've learned about the segmentation fault
that occurs during oskit-mach bootup.

The fault occurs in oskit, in the file [oskit]/linux/dev/init.c:
Program received signal SIGSEGV, Segmentation fault.
0x00159163 in oskit_linux_dev_init () at init.c:129
129             x = *((unsigned *)(kaddr + 0x104));

The address kaddr + 0x104 = 0x104, falls within the zeroth page
of virtual memory. This page has been specifically unmapped to
trap NULL pointer references. This was done in
[gnumach]/oskit/x86/main.c::machine_init(). Also note that,
in that function, part or all of the zeroth page (physical) is
remapped into the address space of the zone subsystem, so I assume
the information that was contained in the zeroth page is now lost.

What the oskit code is trying to do is to access the entries 0x41 and
0x46 in the initial interrupt vector table (IVT), they correspond to
physical addresses 0x104 and 0x118 respectively. These entries in the
IVT contain SEG:OFF type addresses of two 16byte blocks containing
information the BIOS has provided about the first two IDE drives.

Here's a back trace leading up to oskit_linux_dev_init():
#0  oskit_linux_dev_init () at init.c:81
#1  0x0014c4eb in oskit_linux_driver_register (drv=0x262228) at
driver.c:32
#2  0x00158fd7 in oskit_linux_init_ide () at ide.c:356
#3  0x00145d3f in oskit_linux_init_blk () at init_blk.c:24
#4  0x00145d2b in oskit_linux_init_devs () at init_all.c:22
#5  0x00112ec3 in ds_osenv_init () at ../gnumach/oskit/ds_osenv.c:61
#6  0x0012bdee in ds_init () at ../gnumach/oskit/ds_routines.c:211
#7  0x0012b215 in device_service_create ()
    at ../gnumach/device/device_init.c:62
#8  0x00129022 in start_kernel_threads () at
../gnumach/kern/startup.c:217
#9  0x00103799 in thread_continue (old_thread=0x0)
    at ../gnumach/kern/sched_prim.c:843

Note that the stack base contains the address of start_kernel_threads(),
which is called rather late in the boot process. Specifically, after
paging and virtual memory have been activated, and the zeroth page was
unmapped.

The linux driver code obviously needs this informaation that it's trying
to get, but by the time it tries to access it, the information is no
longer available.

The following are possible solutions to this problem:
1) Copy the information provided by the BIOS to a safe place
   early in the boot process (this is what linux does). This
   will have to be done either in the oskit bootup code, or
   before virtual memory is activated in oskit-mach.
   The downside is that the oskit linux driver initialization
   code will have to be made aware of this special arrangement.
2) Call oskit_linux_dev_init(), before virtual memory is activated
   by oskit-mach. There maybe a problem if that function expects
   any facilities that have not been activated yet to be available.
3) When initializing the virtual memory map, map the 0th physical
   to the 1st virtual page, 1st physical to 2nd virtual, and so on.
   Then unmap the 0th virtual page like before. This way NULL pointer
   references are still trapped, but the contents of the 0th physical
   page are not lost. This will imply setting the global variable
   phys_mem_va to PAGE_SIZE as opposed to zero, so that
   osenv_mem_map_phys() can map kaddr to the appropriate value in
   the code above.

Which solution is best in this case? I'll be looking into 2 and 3
because they don't involve any modification to the oskit codebase.

And one more thing that I'm puzzled by, why was this bug not occuring
when I was linking against the debian binary version of oskit libs?

Igor