Date: Tue, 20 Mar 2001 18:11:17 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: Noel Koethe <noel@koethe.net> Cc: Thomas Moestl <tmoestl@gmx.net>, freebsd-stable@freebsd.org Subject: Re: dmesg output Message-ID: <20010320181117.A2347@crow.dom2ip.de> In-Reply-To: <Pine.LNX.4.21.0103201727530.12266-100000@data.wipol.uni-bonn.de>; from noel@koethe.net on Tue, Mar 20, 2001 at 05:36:49PM %2B0100 References: <20010320172534.A1977@crow.dom2ip.de> <Pine.LNX.4.21.0103201727530.12266-100000@data.wipol.uni-bonn.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 20, 2001 at 05:36:49PM +0100, Noel Koethe wrote: > On Tue, 20 Mar 2001, Thomas Moestl wrote: > > > since some weeks my dmesg output is broken: > > > # dmesg > > > 2250 192.168.159.255:138 in via xl0 > > > > > > Maybe someone can give me a hint to fix it if the problem is located at my > > > machine. > > > > Try "dmesg -a". The messages are stored in a ring buffer, so the > > oldest ones will be overwritten if the buffer fills up. Additionally, > > dmesg will normally not show the console output that is also stored in > > the message buffer. This produces these effects. > > This is starting to become a FAQ... > > dmesg -a works. Thx. > But on another machine dmesg still works: > # dmesg > Copyright (c) 1992-2001 The FreeBSD Project. > ... > icmp-response bandwidth limit 522/200 pps > icmp-response bandwidth limit 861/200 pps > ad0: READ command timeout tag=0 serv=0 - resetting > ata0: resetting devices .. done > ad0: UDMA ICRC READ ERROR blk# 13939543 retrying > ad0: READ command timeout tag=0 serv=0 - resetting > ata0: resetting devices .. done > > Why it is here normal on one machine and cutted on the other? > And why does it work before ( I'm sure in December it doesn't work like > now )? OK, I'll go into details a little more. Not too long ago, a patch was MFCed that allows logging console output. To allow this, this ouput is written into the kernel message buffer, where it can be picked up by syslog using the /dev/klog interface. Normal kernel output is written to the message buffer as is, while console output is prefixed with a string in the form "<category>", where category is a number (118 in this case, LOG_CONSOLE|LOG_INFO). dmesg will ignore messages that start with such a string indicating that the message didn't come from the kernel unless it is invoked with the -a option. If syslogd is configured to echo some messages to the console, those messages will be appended to the kernel message buffer, and if this happens too often, this will overwrite all the kernel messages. A common situation is that a lot of kernel messages are generated that fill up the message buffer, syslog snarfs those a little later, writes them to the console and thus overwrites the original kernel messages in turn. dmesg will show nothing in this case, or, more often, a line that came from the console, but of which the first character(s) were overwritten by a new message (they don't start with a "<number>" magic string then, and dmesg will print them). So, dmesg will work as expected on machines that didn't generate enough messages yet, or on systems from before the MFC. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010320181117.A2347>