Re: Buffering for serial consoles (was re: Quota exceeded...)

Tim Wright (timw@sequent.com)
Mon, 27 Jan 1997 15:21:35 PST

In message <ML-2.3.854282348.8565.davidm@fuzzbox.psrg.cs.usyd.edu.au>,David Mon
ro writes:
> > The solution on recent Sequent SMP systems was to add a daemon that takes
> > the equivalent of the printk()'s and buffers them. That way the console
> > (which is *always* a vt220 with a max baud of 19200) doesn't hold back
> > the kernel. You get an extra process with it's own thread of execution
> > doing the buffering.
> Yes, but - you loose one of the advantages of having the kernel talk direct t
> o
> the device, which is that the kernel messages get out to the console when the
> machine panics or whatever. With a daemon, the messages probably never make i
> t
> to the screen in this case, which is of course when you need it most.

No.
During sysinit and PANIC, the kernel still talks directly to the console
interface. At these points, you rather hope that you're not flooding the
console :-)

The reason for the change is that you don't want kernel code hanging around
waiting to send information to a 9600bps serial device. The kernel has a nice
fast circular buffer where it dumps information. The userland klogd tries to
suck out the data as fast as possible, and writes it to a disk file and writes,
non-blocking, to the console. If the console flowblocks, some of the output
will not appear, but it still gets to the file. If the kernel ends up
producing obscene amounts of information very quickly, the circular buffer
will overflow, but the fact is recorded, and when klogd catches up, it
records the fact that it dropped stuff.

t

--
Tim Wright, Worldwide Technical Services,         |  Email: timw@sequent.com
Sequent Computer Systems Inc., 15450,             |
SW Koll Parkway, Beaverton, Oregon 97006          |  Phone: +1-503-578-3822
"Applying computer technology is simply finding the right wrench to pound
in the correct screw"