At 1:46 AM +0100 11/15/97, Paul Kranenburg wrote:
>> 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.
>
I tried out the patch over the weekend, and it cured the fifo overrun
problem. I ran it for two days, without any bad side effects, but on a
relatively lightly used machine. It does a lot of NAT, but not much else.
My small but demanding user base is pleased.

It would be great if something like this made it into 1.3

I do recognize the advantages of waiting until it is fixed correctly, and
will wait patiently for that to happen. Well maybe not patiently, but I'll
wait. :-)

Brad

Stephen B. Salai                            Phone (716) 325-5553
Cumpston & Shaw                             Fax    (716) 262-3906
Two State Street                            email bsalai@tmonline.com
Rochester, NY 14614