Re: oskit-mach won't boot

[Roland McGrath]

> I've just pulled the oskit-mach source from CVS build it and tried to
> boot it. Unfortunately, it didn't work. 

Well, I'm very glad that you are trying and are interested in debugging it.

> I've managed to track down the problem to spl0() (defined in
> i386/i386/spl.S). Here's how it happens:
> main -> setup_main -> cpu_launch_first_thread ->
>   load_context -> Load_context -> Thread_continue ->
>       thread_continue -> spl0
>
> And then the computer just restarts. spl0() is an assembly routine
> that means I can't just put debug printf's in the middle of it, like
> I didn in other places along the way. And after looking at the code
> I fail to see where the problem could lie. (Partly because my
> assembly skills are rather limited.)

It is probably safe to insert:

        pushl %eax
        call debug_beep
        popl %eax

between instructions in spl0 and narrow it down that way.  I'm sure that
will cause severe problems later on if we were to get that far, but it
might help us figure out how to get past the first time this function runs.
(Note that the #ifdef LINUX_DEV parts should not be getting compiled in for
oskit-mach.)

You shouldn't have a problem inserting printfs in one of the calling C
functions to see the state of all the variables that affect spl0 (curr_ipl,
softclkpending, pic_mask).  You can derive from those values what code path
ought to be taken, and look at where that ends up (e.g. softclock, spl1).


I'm sure I've asked you this before.  Do you have a second machine with a
serial port?  Nothing beats gdb over serial line for oskit kernels.  I
think that when you are getting this far, you should be able to actually
step/stepi through all of this in gdb (from main onwards).


I am not really surprised that the interrupt handling is broken somehow.  I
remember when I was integrating the mach interrupting handling code with
the oskit interfaces, it was very tricky getting it right and I had some
issues I where I wanted to change the oskit interfaces at some point
because of contortions I'd had to do in oskit-mach.  I don't really recall
the details at all any more.  I hope I wrote some comments. ;-) I have not
been tracking the oskit closely since around the time I wrote oskit-mach,
and there has been continuing development going on at Utah.  It could be
that the oskit interfaces involved have changed in some subtle ways that
broke oskit-mach.  

I'm afraid I won't be a whole lot of help with this until I am set up with
a machine I can test on and use gdb myself.  I might get inspired to read
through all the code and think through the issues without having my fingers
on a hot system, but probably not.