> alternatively, splpmap() could be changed back to raising-or-lowering,
> but I'm sure there was a reason for changing it in the first place.

That is my doing. Back when the sun4m code was integrated, I attempted
to make configure() run with all interrupts blocked. splpmap() was
one thing that got in the way of that (the other is spltty()), as
it lowered the PIL when e.g. mapping in devices.

This problem has since be worked around differently, so splpmap()
might as well go back to plain splimp().


> the code that takes forever and causes the zs overruns is ctx_alloc().
> long ago this wasn't a problem, since the splpmap() inside ctx_alloc()
> would lower IPL to PIL_CLOCK, thus allowing zs interrupts thru.
> once splpmap() was changed to be raising-only, IPL inside ctx_alloc()
> remains at splhigh() (since it's called from cpu_switch(), called from
> mi_switch()).  since cpu_switch() is already changing IPL all over the place
> (it does the equivalent of "spl0(); splhigh();" right at the top,
> which should have been a tip-off), we simply need to make cpu_switch()
> lower IPL to PIL_CLOCK right before it calls ctx_alloc().
> (PIL_CLOCK is for both splclock() and splpmap().)

Thanks for having me look at that code again and realize that the
interrupt level is going to splhigh() again when the new process is
ready to run, which I had missed before.

Anyway, going to PIL_CLOCK before scanning the run-queue seems not right
either.  PIL_STATCLOCK should be used there..  not that it matters in
practice right now, since the sparc currently has no handlers that
call wakeup() above PIL_CLOCK.

-pk