I just started running netbsd on my IPX a few weeks ago. When I installed
1.2.1 I didn't have any fifo overruns at 38.4, and the transfer rates were
very good for my not all that clean dialup 28.8 connection.

The problems appeared when I "upgraded" to 1.2G to take advantage of some
of the new stuff (netatalk support especially).

Something must have happened recently to cause this.

Is there anyone running -current on a sparc who isn't seeing this problem?

Brad

>At 6:24 PM -0700 10/23/97, Chuck Silvers wrote:
>I ran into this a couple years ago.
>I originally had a sparc 1 and had all kinds of problems with
>"fifo overrun"s at 38400 baud.  I put some instrumentation in
>the zs driver to figure out what it was doing right before the
>zs interrupts were processed, and it was usually the instruction
>right after the splx() in the middle of tsleep().
>
>I hacked up the interrupt level usage stuff to not use level 14
>for the statclock (doubling up on level 10 instead), and changed
>a number of splhigh()s to splstatclock() in various places
>(6 in kern_synch.c and 2 in sys_generic.c) and the problem went away.
>pk didn't like my fix tho, and I upgraded to an IPX and didn't
>see the problem with an unpatched kernel anymore, so I let it drop.
>later it started happening again on the IPX, but shortly after that
>I got ISDN and a router, so again I didn't care.
>
>I think some changes went in to address this same problem
>on the i386 some time back, but I guess that didn't
>solve things for the sparc.
>
>I can post the diffs for my changes (based on -current of
>over a year ago, unfortunately) if anyone's interested.
>
>-Chuck
>
>
>In message <199710232054.QAA29986@bach.mc.com>, "Gordon W. Ross" writes:
>> > Date: Thu, 23 Oct 1997 13:42:45 -0400
>> > From: Steven Grunza <steveng@formail.formation.com>
>>
>> > Same here, except they were zs0b:  fifo overrun.  I had a 14.4 modem on
>> > ttyb with RTS/CTS flow control.  The SPARC is a SPARCstation 1.
>>
>> Oh...  I was confused.  When there is a problem with H/W flow control,
>> (i.e. crtscts not turned on, or wrong cable wiring) then the message
>> one will see is "ring overrun", not "fifo overrun" as I had thought.
>> (Maybe "fifo overrun" should be "chip overrun" instead.)
>>
>> The cause of "fifo overrun" message is excessive latency in servicing
>> interrupts from the ZS chip.  The cause of that could be anywhere,
>> i.e. interrupts disabled too long somewhere, or who knows what.
>> What else was going on in the system at the time?
>>
>> Lower baud rates will probably eliminate the "fifo overrun" problem.
>> Have you tried that?  What is the highest rate that makes the fifo
>> overrun errors become infrequent?
>>
>> Gordon
>>


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