Re: More on oskit-mach booting troubles

[Roland McGrath]

Ah, well you know the test machine I had when I was writing oskit-mach
didn't have a CDROM, so that code may never have been exercised.  Certainly
just avoid the CDROM driver if you want to just debug one thing at a time.

The code you cited is doing some form of "sleep until interrupt", waiting
for an interrupt from the IDE controller.  It should be going through
various levels of Linux driver and oskit glue and eventually getting into
the oskit-mach/oskit/osenv_sleep.c code.  That part probably works, but
I bet you are seeing a problem with the interrupts getting through properly.

The low-level interrupt handling is in Mach's code.  You can do some hack
in that code to see how far up the interrupt is getting (e.g.  a hard-wired
test for your IDE controller's irq number and a printf there).  First,
check that ivect/iunit are set up for the irq; this should have been done
in oskit-mach/oskit/osenv_irq.c:irq_alloc in a callback from the IDE
driver's initial setup code.  Then you can try to see if the irq_handler
function in osenv_irq.c is getting called from the Mach (interrupt.S) code.

>From there up it gets pretty hairy and subtle.  I don't really recall many
of the details.  What I do recall is that it was by far the most difficult
part of working on oskit-mach, with subtle ways to get it wrong and think
it was right until some more complex case came up, and that I concluded the
oskit's interfaces really should be a lot better for this stuff.  Since
that time, I have not closely tracked of the details of oskit development
and so there may well have been subtle changes that I'm not aware of.