If I boot my system, there are copious messages.
For example:
md: Autodetecting RAID arrays.
md: autorun ...
md: considering hdc6 ...
md: adding hdc6 ...
md: hdc5 has different UUID to hdc6
md: hdc3 has different UUID to hdc6
md: hdc1 has different UUID to hdc6
md: adding hda6 ...
md: hda5 has different UUID to hdc6
md: hda3 has different UUID to hdc6
md: hda1 has different UUID to hdc6
md: hdi2 has different UUID to hdc6
md: hdi1 has different UUID to hdc6
md: hde2 has different UUID to hdc6
md: hde1 has different UUID to hdc6
md: created md5
md: bind<hda6>
md: bind<hdc6>
md: running: <hdc6><hda6>
md5: setting max_sectors to 128, segment boundary to 32767
raid1: raid set md5 active with 2 out of 2 mirrors
Now these messages are often uninteresting - but sometimes they are.
So just deleting them, or requiring a recompile or reboot is not good
enough.
Also, I noted that these messages were almost always grouped together.
Suppose these messages were removed from the normal output, but instead
stored in a buffer in the kernel.
Then, you could do
dmesg.raid
to get at the raid-messages,
and
dmesg.raid --clear
to clear the buffer.
The same goes for other groups of messages, like the whole APIC/IRQ
routing block, ide messages, usb messages etc.
Would this keep the interesting information, but cut down on the amount
of messages? I'm now at 22k of dmesg, including raid, usb, apic etc, for
a single CPU system.
I'd be interested in everyone's opinion on this!
Jurriaan
--
REAL LIFE MANAGEMENT 'DILBERT QUOTATIONS':
11: One day my Boss asked me to submit a status report to him concerning a
project I was working on. I asked him if tomorrow would be soon
enough. He said "If I wanted it tomorrow, I would have waited until
tomorrow to ask for it!" (New business manager, Hallmark Greeting
Cards.)
Debian (Unstable) GNU/Linux 2.6.0-test1-ac2 4112 bogomips load av: 1.00 1.00 1.00
On Fri, Jul 25, 2003 at 09:57:52PM +0200, Jurriaan wrote:
> of messages? I'm now at 22k of dmesg, including raid, usb, apic etc, for
> a single CPU system.
And you want more static buffers to store that in than now? Many people
won't like that.
You'd do better to have a boot time command line option to limit printk
messages to err, or above. Most of the printk messages have been given a
severity already, so this shouldn't be a problem, and it will probably
uncover some errors in the severity of certain messages.
Anyway, there are other ways to peel this union, including having the
messages to to tty2 instead of console (I've seen patches for this posted
before).
Quoth Jurriaan:
> If I boot my system, there are copious messages.
>
[...]
> Now these messages are often uninteresting - but sometimes they are.
> So just deleting them, or requiring a recompile or reboot is not good
> enough.
> Also, I noted that these messages were almost always grouped together.
>
> Suppose these messages were removed from the normal output, but instead
> stored in a buffer in the kernel.
How about the "quiet" kernel command line parameter, which quiets
down the boot process but still stores the messages in the ring
buffer?
Kurt
--
Support bacteria -- it's the only culture some people have!
Mike Fedyk <[email protected]> writes:
> You'd do better to have a boot time command line option to limit printk
> messages to err, or above. Most of the printk messages have been given a
> severity already, so this shouldn't be a problem, and it will probably
> uncover some errors in the severity of certain messages.
Right.
In fact I'd rather leave the console printing KERN_INFO and make sure
the (debug) messages are really KERN_DEBUG. This way we wouldn't have
much noise with normal boot, but we could see KERN_DEBUG when something
goes wrong (and the kernel is being told to print everything).
--
Krzysztof Halasa
Network Administrator