Re: More on oskit-mach booting troubles

[Roland McGrath]

> On Sat, Jul 21, 2001 at 09:57:44PM -0400, Roland McGrath wrote:
> > 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.
> 
> When I recompiled oskit without CDROM support, the kernel still didn't
> boot. This time it hund when it started reading the partition table.
> I think it's either the same or a similar problem as with the CDROM.
> It must be somewhere in the code communicating with the IDE controller.
> 
> > 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.
> 
> When I was tracing through the code at that place, i wound up in
> [oskit]/linux/include/asm-i386/semaphore.S::down(), and it looks
> like this after expanding several #ifdefs:
> 
> extern inline void down (struct semaphore *sem)
> {
>       asm volatile ("
>               decl (%0)
>               js 2f
>       1:      .section .text.lock,"ax"
>       2:      call __down_failed
>               jmp 1b
>               .previous"
>       : "c" (sem) : "memory");
> }

This is approximately:  while (--*(int*)sem < 0) __down_failed();

__down_failed blocks until something increments the semaphore.  This gets
into oskit/linux/shared/s_sched.c:__down, where it goes into the
osenv_sleep interface I mentioned before.  The `up' call that does this
should be from some place like ide_end_drive_cmd in
oskit/linux/src/drivers/block/ide.c (and other places--that's just an
example), that get called from ide_intr. 

You don't necessarily need to understand all this Linux driver nonsense.
This is the glue I was talking about before.  The upshot is that it's
waiting to get an interrupt, and the interrupt processing isn't happening
right.