lkml.org 
[lkml]   [2003]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectLarger circular printk log message buffer for kernel?
From
Date
Please CC me for responses.

I'm willing to make a patch if it is likely to be accepted into the
kernel. Since we have so many subsystems that spit out kilobytes of
messages, by the time my system has booted up I have already lost some
of the most important boot messages! (APIC, for example)

I found the important part located in kernel/printk.c as follows in
2.4.21-pre3-ac2:

#if defined(CONFIG_MULTIQUAD) || defined(CONFIG_IA64)
#define LOG_BUF_LEN (65536)
#elif defined(CONFIG_ARCH_S390)
#define LOG_BUF_LEN (131072)
#elif defined(CONFIG_SMP)
#define LOG_BUF_LEN (32768)
#else
#define LOG_BUF_LEN (16384) /* This must be a power of two */
#endif

I changed the last one to 32768 and now I see all my boot messages. I
imagine that people would be against doubling the last two buffers (that
is, SMP = 64k, else = 32k) on all systems. But 16k is simply too small
for anyone using RAID or USB or APIC or other "noisy" subsystems.
RAID/md is by far the noisiest boot-time subsystem I have configured.

Ideas? Perhaps a kernel config multiplier defaulting to "1" that can be
changed in "make config" to 2, 4, 8, ...? I'm willing to do the work
for this, but only if it seems likely to be accepted. Are there other,
better options?

On systems with large amounts of memory, surely we can afford to give
more of it to the kernel's log message buffer!


Eddie

--
Eddie Kuns | Home: ekuns@kilroy.chi.il.us
--------------/ URL: (none at the moment)
"Ah, savory cheese puffs, made inedible by time and fate." -- The Tick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.074 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site