Hi,

> I'm not sure either.  I suspect that as soon as SR 14 was replaced, the
> kernel found itself unable to execute because it wasn't mapped.

No, that's not the problem.  All the PowerPC ports map all of memory
1:1 between virtual and physical address space, while running in the
kernel.  This is done via the BAT mechanism.  However, sometimes the
kernel allocates virtual address range before backing it with physical
memory (like with malloc, the user struct or the buffer cache).  For
this, the area mapped via SR 14 is reserved.

> No.  It was a debugging box that uses the JTAG interface on the cpu to
> permit such things as stopping the CPU or single-stepping it.  Kind of
> like an in-circuit emulator but not quite as sophisticated.

Hmm, I don't know what made your box fail then.  It shouldn't fail at all,
certainly not at the point you indicate below.  What exactly is the type
of device you are using?

> > you might note that the original code goes out of its way to
> > guarrantee that there is no access to kernel virtual memory while
> > this loop is running.
> 
> It tries, perhaps, but what about the instruction stream?  (I didn't
> investigate that in detail at the time, and I'm not near the hardware
> now and hence can't check; it could be that the PC was in the area
> mapped by BAT0 rather than the region mapped by SR14.)

See above.

> And it would have been accessing i on the stack in any case - where is
> the kernel stack kept on the macppc?  (I suspect this wasn't what was
> going wrong, because when doing instruction-level single-stepping, it
> went wonky as soon as I told it to step through the mtsrin, before it
> had occasion to try to do anything with i.)

What makes you think that the compiler is placing i on the stack?  The
processor has 32 general purpose registers, there certainly is one of them
that can be made good use of by placing i into it, don't you think? :-)

Hmm, there shouldn't be any memory access after the mtsrin, except to
the instruction stream of course.  But that one isn't mapped via SR 14.

What exactly does your JTAG device tell you after that?

> There's no way interrupts could cause trouble if they strike with the
> vmspace partially switched into the harwdare?  I left the interrupt
> disabling in place, since I wasn't sure and figured it was safer to
> leave it than mess with it.

Note that all of the above code, and of course any interrupt handler
is in the kernel address space.  Switching pmaps is only relevant to
userland code, as the kernel runs in its own pmap, which always stays
the same.  Since there is no preemption of kernel code in favour of
userland, there obviously cannot be a problem here.

Anyway, I'm not sure what you are observing here.  Might be some odd
interaction with the JTAG device (yes, I'm seeing some counter-intuitive
things happening when using a similar device.)

Ciao,
Wolfgang
-- 
ws@TooLs.DE     Wolfgang Solfrank, TooLs GmbH 	+49-228-985800