Subject: None
To: None <amiga@netbsd.org>
From: Michael L. Hitch <osymh@gemini.oscs.montana.edu>
List: amiga
Date: 10/20/1994 09:51:18
On Oct 19,  9:31pm, "Chris G. Demetriou" wrote:
> strange as this may seem, one of the best ways to _reduce_ (i.e. not
> eliminate) silo overflows is to disable logging of them.
> 
> If you get a silo overflow, and log it via syslog and/or kernel
> printf(), a large amount of code will be run at spltty(), blocking
> more serial interrupts, and likely causing more silo overflows!

  I don't think this will help the Amiga silo overflows very much.  The
serial port interrupts at level 5, but spltty() runs at level 4.  The
level 5 interrupt routine just grabs the serial input data and stores it
into the circular input buffer and exits.  The stored data also includes
the status bits associated with the character, which includes the
receiver overrun flag, which generates the "silo overflow" message.  If
the ring buffer overflows at this level, a counter is incremented to
count the number of characters lost because the ring buffer was full. 
The ring buffer is processed by a routine called from the vertical blank
interrupt, which is at level 3.  That routine runs at spltty(), except
for a short period when it is updating the ring buffer pointer, which
is done at spl5().  Any "silo overflow" or "ring buffer overflow" is
logged in this routine, at spltty().  [The "ring buffer overflow"
message used to be logged in the serial input interrupt routine, which
did cause "cascade" overflows.  I moved the logging out of the interrupt
routine some time ago after running into it a few times.]

  Any silo overflows are going to be due in part to other parts of the
kernel running at spl5() or higher.  I don't know if any of the logging
stuff is done at these higher spl levels, so I don't know how much real
impact they will have.  I also don't know how much of the kernel might
be running at the higher spl levels either.  I haven't gone looking yet.
The other cause for silo overflows would be hardware considerations -
the GVP SCSI controller is a prime example of this, since it seems to
hog the Zorro II bus when doing DMA transfers.  I haven't ever had too
much trouble with the GVP controller, since I was always running with a
68040 and local 32 bit memory.

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA