chris@mimsy.umd.edu (Chris Torek) (09/02/90)
>>>"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