Date: Sun, 26 Jan 1997 01:35:50 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, dgy@rtd.com, freebsd-hackers@freefall.freebsd.org Subject: Re: suggestion for kernel printk() ? Message-ID: <199701260835.BAA01692@seagull.rtd.com> In-Reply-To: <199701260649.RAA20345@godzilla.zeta.org.au> from "Bruce Evans" at Jan 26, 97 05:49:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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. Hmmm... this is a 2.1R box. I'll have to check next time I reboot... > >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 Yes, that's what I had suspected. > 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. But would it actually *break* anything? Perhaps I'll hack in a two line patch next time I rebuild a kernel and see what happens... Thx! --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701260835.BAA01692>