Hi,

> In connection with the porting effort I mentioned a while ago, I had
> some trouble which I eventually traced to pmap_activate(), in
> powerpc/powerpc/pmap.c.  I find the following code sequence (compressed
> by snipping comments and blank lines)
> 
> 		__asm __volatile("mfsr %0,14" : "=r"(ksr) :);
> 		rpm = pcb->pcb_pmreal;
> 		for (i = 0; i < 16; i++) {
> 			seg = rpm->pm_sr[i];
> 			__asm __volatile("mtsrin %0,%1"
> 			    :: "r"(seg), "r"(i << ADDR_SR_SHFT));
> 		}
> 		__asm __volatile("mtsr 14,%0" :: "r"(ksr));
> 
> 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.
> 
> Changing it to
> 
> 		rpm = pcb->pcb_pmreal;
> 		for (i = 0; i < 16; i++) if (i != 14) {
> 			seg = rpm->pm_sr[i];
> 			__asm __volatile("mtsrin %0,%1"
> 			    :: "r"(seg), "r"(i << ADDR_SR_SHFT));
> 		}
> 
> 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.  However, what you found on
your detailed investigation has to be an artifact of that investigation!
Probably you used ddb for this investigation?

While your changed code effectively is the same and maybe even better
(apart from, IMHO, style :-)), 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.  This is so, since access to kernel
virtual memory is done via sr 14 (surprise! :-)).  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).

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