From owner-freebsd-hackers Sat Jan 25 22:55:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA20328 for hackers-outgoing; Sat, 25 Jan 1997 22:55:34 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA20321 for ; Sat, 25 Jan 1997 22:55:31 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id RAA20345; Sun, 26 Jan 1997 17:49:48 +1100 Date: Sun, 26 Jan 1997 17:49:48 +1100 From: Bruce Evans Message-Id: <199701260649.RAA20345@godzilla.zeta.org.au> To: bde@zeta.org.au, dgy@rtd.com Subject: Re: suggestion for kernel printk() ? Cc: freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I use a serial console and `terminalprogram | tee foo' to capture >> the output. > >Yes, but I would have had to have built the kernel with COMCONSOLE >(which I didn't). COMCONSOLE hasn't been necessary for 2 years in -current (just boot with -h) but is still necessary in -stable. Sigh. >However, is it worthwhile for the mechanism that printk() ?? uses to >observe some kind of flow control? It did not recognize scroll_lock, >pause, ^S, etc. This would have at least enabled me to read some >(i.e. one screen full) of the messages to see what the kernel was >complaining about. Scroll lock and scrollback don't work until interrupts are enabled after probing all the devices. printf() doesn't have any flow control. It can't afford to pause once the system is up because that would freeze the whole system. Freezing for 1 msec per character to for output at 9600 bps is bad enough. Bruce