From owner-freebsd-hackers  Sat Jan 25 12:32:34 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA16195
          for hackers-outgoing; Sat, 25 Jan 1997 12:32:34 -0800 (PST)
Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA16190
          for <freebsd-hackers@freefall.freebsd.org>; Sat, 25 Jan 1997 12:32:31 -0800 (PST)
Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id NAA20427; Sat, 25 Jan 1997 13:32:19 -0700 (MST)
From: Don Yuniskis <dgy@rtd.com>
Message-Id: <199701252032.NAA20427@seagull.rtd.com>
Subject: Re: suggestion for kernel printk() ?
To: bde@zeta.org.au (Bruce Evans)
Date: Sat, 25 Jan 1997 13:32:19 -0700 (MST)
Cc: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org
In-Reply-To: <199701240824.TAA07251@godzilla.zeta.org.au> from "Bruce Evans" at Jan 24, 97 07:24:43 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

It seems that Bruce Evans said:
> 
> >     I just spent some time fighting a kernel that died miserably
> >on boot  :-(  I was inundated with an endless stream of kernel
> >messages (in highlighted text) followed promptly by a hard reset.
> >It was quite frustrating to find that there doesn't seem to be a
> >mechanism to pause the display at this point!
> 
> 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).

> >     OK, reboot from /kernel.old and look through the logs.  Hmmm...
> >nothing here!  Probably the filesystem wasn't even functional when
> >the boot ran into trouble.
> 
> Boot messages are supposed to be preserved in the message buffer
> across reboots.  However, many PC BIOSes and/or memory systems do
> something that invalidates the message buffer even for a soft reboot.

Well, I wasn't observant enough to notice what type of restart the
PC went through (two different varieties here -- one of which actually
rampages through memory, etc.) but suspect this is the problem.

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.

Thanks!
--don