I tried these, and they work great.

I couldn't test the kernel too thoroughly because it doesn't have ipfilter
or netatalk enabled, but the fifo overrun problem is not present at 38400.

Does this break something else, or is there some chance these changes will
make it into the tree?

Brad

At 2:37 PM -0800 10/29/97, Chuck Silvers wrote:
>after looking at it some more, it seems like we can get away without
>changing the interrupt level of statclock().  another way to look at
>the problem is that we already have a two-level interrupt scheme for
>the scheduler (the troublesome part of statclock()) on the sparc via
>the two different clock interrupts.  the bulk of the scheduler only
>needs to run at "splsched()" (which is documented in the spl manpage,
>defined on only the m68k-based ports, and not used at all).
>I propose to resurrect splsched() and use it to solve
>the zs overrun problem.  diffs based on this morning's sup are at
>
>	http://www.chuq.com/netbsd/splsched.diff
>
>and a GENERIC kernel with above diffs applied is at
>
>	http://www.chuq.com/netbsd/netbsd.splsched.gz
>
>(diffs only complete for sparc currently, other ports need merely
>add a definition for splsched(), or possibly correct an existing definition.)
>these changes eliminate zs fifo overruns on my sparc1 and IPX at 38400 baud.
>
>there's still a slight bit of funniness after these patches:
>p_usrpri, p_priority and curpriority are still accessed outside
>splstatclock() in arch/sparc/sparc/trap.c:userret(),
>but it's been like that all along so I left it alone for now.
>I don't know exactly what the different between these fields is anyway,
>can someone explain?
>
>-Chuck


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