>> [...loading segment registers in pmap_activate()...]

>> Detailed investigation indicated that when the loop reached 14 and
>> did the mtsrin for sr 14, the machine went out to lunch - it
>> apparently started trapping recursively through routines like
>> pte_spill.

>> [...skip saving and restoring SR 14 - just don't load it...]
>> made the problems go away.  But I have to wonder why this wasn't
>> done in the first place, which makes me think I'm missing something.
>> Am I?  Or is this really equivalent and I can forget the issue?

> I don't know what trouble/problems you had.

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.

> However, what you found on your detailed investigation has to be an
> artifact of that investigation!  Probably you used ddb for this
> investigation?

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.

> While your changed code effectively is the same and maybe even better
> (apart from, IMHO, style :-)),

Well, yes, I make no claims for the style.  (But then, I generally find
KNF a significant pain to read anyway, so I have little good to say
about the style of the original either.)

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

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

> The original saves and restores the original sr 14 value, while your
> code doesn't overwrite it in the first place (and therefor doesn't
> need the interrupt disable, which probably is a win).

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.

					der Mouse

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