Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uflorida!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.ultrix
Subject: `fifo overflow' & kernel printf (was ULTRIX problems, problems...)
Message-ID: <26334@mimsy.umd.edu>
Date: 2 Sep 90 14:46:51 GMT
References: <2039@gmuvax2.gmu.edu> <1990Aug30.131419.1831@dsuvax.uucp> <2121@gmuvax2.gmu.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 39

>>>"dhu0, line0: recv. fifo overflow"

In article <2121@gmuvax2.gmu.edu> rauletta@gmuvax2.gmu.edu (R. J. Auletta)
writes:
>I am still curious though about the meaning of the fifo error, why
>it is so important, and why some errors messages (from the kernel?)
>are not buffered to the console (polled character I/O?).

The `recv fifo overflow' (which used to be called a `silo overflow',
and still is in BSD kernels) means that the receive FIFO overflowed.
The receive FIFO is a FIFO that receives incoming characters, holding
them until the kernel gets around to reading them and putting them onto
the proper tty queue.  (For the truly uninformed :-) , `FIFO' stands
for `First In, First Out' and is a special kind of memory chip, or
[nowadays] part of a chip.)

In other words, at least one input character was lost.

>This problem use to crop up with NFS errors. For the 5 seconds it
>would take to print the error out at 30cps on a decwriter
>the kernel would hold the processor, then give you about a second
>to "do something" before the next error.

This is because these errors are (improperly) reported via the kernel
`printf' function:

	/*
	 * Scaled down version of C Library printf.
	 * Used to print diagnostic information directly on console tty.
	 * Since it is not interrupt driven, all system activities are
	 * suspended.  Printf should not be used for chit-chat.
	[rest deleted]

Modern kernels (including Ultrix, although there it is the horrendous
VMSoid `error log facility') have routines for logging `less important'
system errors, including silo overflows.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris