From owner-freebsd-hackers Mon Jan 27 21:09:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18409 for hackers-outgoing; Mon, 27 Jan 1997 21:09:56 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18402 for ; Mon, 27 Jan 1997 21:09:46 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id XAA01957 for ; Mon, 27 Jan 1997 23:09:38 -0600 (CST) Received: (from driley@localhost) by crocodile.vale.com (8.8.3/8.7.3) id XAA24269; Mon, 27 Jan 1997 23:09:38 -0600 (CST) Date: Mon, 27 Jan 1997 23:09:38 -0600 (CST) From: Dan Riley To: freebsd-hackers@freefall.freebsd.org Subject: Re: suggestion for kernel printk() ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think this question may be slightly related to this topic or maybe not, but in any event, after compiling a new kernel (based on a cp of LINT) I never not get any output to the screen while booting the new kernel. What option in LINT disables the boot messages from the kernel so that the first thing(only thing) you see is the login prompt after a restart? The messages are ther once I login and dmesg or check messages... This never seems to happen when I start with a kernel based on the GENERIC example. Thanks On Mon, 27 Jan 1997, Simon Shapiro wrote: > > Hi Don Yuniskis; On 25-Jan-97 you wrote: > > 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. > > I may be offbase here, but scroll-lock, etc. are INPUT, while printk is > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to > a circular buffer andanother mechanism dumps it to ``the console''. > If you like ugly, (if memory serves), you can either pass an additional arg > to the output routine (A la Linux) or designate the first character in the > string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. > > Simon >