>> And it would have been accessing i on the stack in any case - where
>> is the kernel stack kept on the macppc?
> What makes you think that the compiler is placing i on the stack?

It's supposed to; I think that kernel was built -g -O0, for the sake of
debugging.  (If correct operation depends on having the optimizer on, I
submit the code is broken - if something *must* be in a register, the
relevant code segment ought to be in assembly.)

> 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.

That's what I thought.

> What exactly does your JTAG device tell you after that?

It lost control of the CPU (it didn't re-halt automatically after I
told it to single-step); upon explicitly telling it to halt, it would
show a PC somewhere randomish in pte_spill or related trap code.
Continuing and re-halting would give another, similar, PC value.  I
don't know how much of this is a failing of the JTAG device itself and
how much is a failing of the interface software; the interface between
the two is woefully undocumented and the software in question is a
vendor binary-only Windows horror.

> 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.)

Could be; I think I'll write it off to that, absent further evidence to
the contrary.  But you've answered my major question, by confirming
that what I did to pmap_activate() shouldn't break anything.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B