[PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[David Ford]

Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
4/5 systems I have now overflow the buffer during boot before init is
even launched.

--- linux/kernel/printk.c~    Fri Jan 26 18:50:28 2001
+++ linux/kernel/printk.c     Fri Jan 26 23:59:31 2001
@@ -22,7 +22,7 @@

 #include <asm/uaccess.h>

-#define LOG_BUF_LEN    (16384)
+#define LOG_BUF_LEN    (32768)
 #define LOG_BUF_MASK   (LOG_BUF_LEN-1)

 static char buf[1024];

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[Alan Cox]

> Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> 4/5 systems I have now overflow the buffer during boot before init is
> even launched.

Thats just an indication that 2.4.x is currently printking too much crap on
boot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[Maciej W. Rozycki]

On Wed, 31 Jan 2001, Alan Cox wrote:

> > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> > 4/5 systems I have now overflow the buffer during boot before init is
> > even launched.
> 
> Thats just an indication that 2.4.x is currently printking too much crap on
> boot

 We could probably get rid of much of the crap for i386 by #undef
APIC_DEBUG in include/asm-i386/apic.h.  Too bad broken SMP systems get
reported every now and then and the crap proves useful in getting what
actually is wrong. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[David Ford]

"Maciej W. Rozycki" wrote:

> On Wed, 31 Jan 2001, Alan Cox wrote:
>
> > > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> > > 4/5 systems I have now overflow the buffer during boot before init is
> > > even launched.
> >
> > Thats just an indication that 2.4.x is currently printking too much crap on
> > boot
>
>  We could probably get rid of much of the crap for i386 by #undef
> APIC_DEBUG in include/asm-i386/apic.h.  Too bad broken SMP systems get
> reported every now and then and the crap proves useful in getting what
> actually is wrong.

The largest bodies of text come from scsi, irda, usb, and udf.

The LP/parport could stand being trimmed too.

The fatfs barfs out bogus cluster size messages when I don't have any FAT type
filesystems.

Question is, If I submit patches to tidy up the boot messages, when will(can)
they be applied?  2.4 or 2.5?

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[Gabor Lenart]

On Wed, Jan 31, 2001 at 05:06:07PM +0000, Alan Cox wrote:
> > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> > 4/5 systems I have now overflow the buffer during boot before init is
> > even launched.
> 
> Thats just an indication that 2.4.x is currently printking too much crap on
> boot

Would it be possible to grow and shring that buffer on demand? Let's say
we have a default size and let it grow to a maximum value. After some
timeout, buffer size can be shrinked to default value if it's enough at
that moment. Or something similar.

-- 
 --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]--[ lgb@supervisor.hu ]--
 U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
 -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[Rik van Riel]

On Wed, 31 Jan 2001, Gabor Lenart wrote:
> On Wed, Jan 31, 2001 at 05:06:07PM +0000, Alan Cox wrote:
> > > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> > > 4/5 systems I have now overflow the buffer during boot before init is
> > > even launched.
> > 
> > Thats just an indication that 2.4.x is currently printking too much crap on
> > boot
> 
> Would it be possible to grow and shring that buffer on demand?
> Let's say we have a default size and let it grow to a maximum
> value. After some timeout, buffer size can be shrinked to
> default value if it's enough at that moment. Or something
> similar.

And when you can't allocate memory for expanding the
printk() ringbuffer?  Print a message? ;)

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[Mark Hahn]

> > Would it be possible to grow and shring that buffer on demand?
> > Let's say we have a default size and let it grow to a maximum
> > value. After some timeout, buffer size can be shrinked to
> > default value if it's enough at that moment. Or something
> > similar.
> 
> And when you can't allocate memory for expanding the
> printk() ringbuffer?  Print a message? ;)

;)
but seriously, we normally need a big printk buffer only because 
of boot messages.  no reason I know we couldn't shrink it down
to something quite modest (4k?  plenty for a few oopses) after boot.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[Paul Gortmaker]

[-- Attachment #1: Type: text/plain, Size: 6195 bytes --]

Gabor Lenart wrote:
> 
> On Wed, Jan 31, 2001 at 05:06:07PM +0000, Alan Cox wrote:
> > > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> > > 4/5 systems I have now overflow the buffer during boot before init is
> > > even launched.
> >
> > Thats just an indication that 2.4.x is currently printking too much crap on
> > boot
> 
> Would it be possible to grow and shring that buffer on demand? Let's say
> we have a default size and let it grow to a maximum value. After some
> timeout, buffer size can be shrinked to default value if it's enough at
> that moment. Or something similar.

I agree that 16k is too much crap being dumped to the console, as people 
will just zone out as it scrolls by at 100lines/sec.  However, it is 
possible to cut it down in size - here is something I have in store for 
2.5 (posted a while ago, the zero initializer for bootlog_buf can go).

Paul.

|Date: Mon, 21 Aug 2000 05:36:18 -0400
|From: Paul Gortmaker <p_gortmaker@yahoo.com>
|To: linux-kernel@vger.kernel.org
|Subject: [PATCH] resizeable printk ring buffer

The printk ring buffer has doubled in size several times to accomodate
the amount of boot messages spewed out by kernels with lots of drivers.
This always seemed like a bit of a waste to me since after the boot
messages had been logged to disk, the original 4k buffer is more than
adequate during normal operation.  To others, the idea of having a big
128k ring buffer might be appealing.  Hence this patch.

The buffer used at bootstrap is marked initdata and an initcall is
used to bounce the messages into a kmalloc'd region before the
initdata is freed.  With a minor extension to the dmesg program (and
kernel syscall) the admin can resise the ring buffer from 4k to 128k.
Messages in the buffer are preserved if the buffer hasn't wrapped
yet and if they will fit in the new size.

To resize without yet having the modified dmesg, you essentially do:

 i = syscall(103 /*syslog*/ , 9, NULL, kbytes);

where kbytes is 4, 8, 16 ... 128.

I'm not advocating this for 2.4 as it isn't a bugfix, but thought
others might want to play with it between now and 2.5.x

Paul.

--- linux~/kernel/printk.c	Fri Jul  7 03:47:57 2000
+++ linux/kernel/printk.c	Tue Aug 15 05:17:24 2000
@@ -12,18 +12,20 @@
  * Modified for sysctl support, 1/8/97, Chris Horn.
  * Fixed SMP synchronization, 08/08/99, Manfred Spraul 
  *     manfreds@colorfullife.com
+ * Dynamically resizeable printk ring buffer, 07/2000, Paul Gortmaker.
  */
 
 #include <linux/mm.h>
 #include <linux/tty_driver.h>
 #include <linux/smp_lock.h>
 #include <linux/console.h>
+#include <linux/slab.h>
 #include <linux/init.h>
 
 #include <asm/uaccess.h>
 
-#define LOG_BUF_LEN	(16384)
-#define LOG_BUF_MASK	(LOG_BUF_LEN-1)
+#define BOOTLOG_BUF_LEN	(16384)
+#define LOG_BUF_MASK	(log_buf_len-1)
 
 static char buf[1024];
 
@@ -46,7 +48,9 @@
 spinlock_t console_lock = SPIN_LOCK_UNLOCKED;
 
 struct console *console_drivers = NULL;
-static char log_buf[LOG_BUF_LEN];
+static char bootlog_buf[BOOTLOG_BUF_LEN] __initdata = {0, };
+static unsigned int log_buf_len = BOOTLOG_BUF_LEN;
+static char *log_buf = bootlog_buf;
 static unsigned long log_start;
 static unsigned long logged_chars;
 struct console_cmdline console_cmdline[MAX_CMDLINECONSOLES];
@@ -119,13 +123,13 @@
  * 	6 -- Disable printk's to console
  * 	7 -- Enable printk's to console
  *	8 -- Set level of messages printed to console
+ *	9 -- Set ring buffer size in kB (4k -> 128k, 2^n)
  */
 int do_syslog(int type, char * buf, int len)
 {
 	unsigned long i, j, limit, count;
-	int do_clear = 0;
-	char c;
-	int error = -EPERM;
+	int error, do_clear = 0;
+	char c, *new_buf;
 
 	error = 0;
 	switch (type) {
@@ -175,8 +179,8 @@
 		if (error)
 			goto out;
 		count = len;
-		if (count > LOG_BUF_LEN)
-			count = LOG_BUF_LEN;
+		if (count > log_buf_len)
+			count = log_buf_len;
 		spin_lock_irq(&console_lock);
 		if (count > logged_chars)
 			count = logged_chars;
@@ -191,7 +195,7 @@
 		 */
 		for(i=0;i < count;i++) {
 			j = limit-1-i;
-			if (j+LOG_BUF_LEN < log_start+log_size)
+			if (j+log_buf_len < log_start+log_size)
 				break;
 			c = log_buf[ j  & LOG_BUF_MASK ];
 			spin_unlock_irq(&console_lock);
@@ -236,6 +240,30 @@
 		spin_unlock_irq(&console_lock);
 		error = 0;
 		break;
+	case 9:	
+		error = -EINVAL;
+		i = 128;
+		while (i != len && i != 4) i>>=1;
+		if (i != len)
+			goto out;
+		error = -ENOMEM;
+		new_buf = kmalloc(len*1024, GFP_KERNEL);
+		if (new_buf == NULL) 
+			goto out;
+		memset(new_buf, 0, len*1024);
+		spin_lock_irq(&console_lock);
+		limit = log_start + log_size;
+		/* Copy iff it hasn't wrapped & will fit.  */
+		if (limit < log_buf_len && logged_chars <= len*1024)
+			memcpy(new_buf, log_buf, logged_chars);
+		else
+			logged_chars = log_size = log_start = 0;
+		kfree(log_buf);
+		log_buf = new_buf;
+		log_buf_len = len*1024;
+		spin_unlock_irq(&console_lock);
+		error = 0;
+		break;
 	default:
 		error = -EINVAL;
 		break;
@@ -285,7 +313,7 @@
 		line_feed = 0;
 		for (; p < buf_end; p++) {
 			log_buf[(log_start+log_size) & LOG_BUF_MASK] = *p;
-			if (log_size < LOG_BUF_LEN)
+			if (log_size < log_buf_len)
 				log_size++;
 			else
 				log_start++;
@@ -495,3 +523,26 @@
 		tty->driver.write(tty, 0, msg, strlen(msg));
 	return;
 }
+
+/*
+ * Kernel boot messages are 1st stored in __initdata, then copied to
+ * kmalloc so you can use do_syslog() above to resize buffer later.
+ */
+static int __init printk_ring_copy(void)
+{
+	char *new_buf;
+	unsigned long flags;
+
+	new_buf = kmalloc(BOOTLOG_BUF_LEN, GFP_KERNEL);
+	if (new_buf == NULL) {
+		printk(KERN_EMERG "No memory for new printk buffer!?!\n");
+		return -ENOMEM;
+	}
+	spin_lock_irqsave(&console_lock, flags);
+	memcpy(new_buf, log_buf, BOOTLOG_BUF_LEN);
+	log_buf = new_buf;
+	spin_unlock_irqrestore(&console_lock, flags);
+	return 0;
+}
+
+__initcall(printk_ring_copy);





_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[Ion Badulescu]

On Sat, 27 Jan 2001 08:01:14 +0000, David Ford <david@linux.com> wrote:
> Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> 4/5 systems I have now overflow the buffer during boot before init is
> even launched.

Hmm, are you sure? man dmesg:
[...]
       -sbufsize
              use  a  buffer  of bufsize to query the kernel ring
              buffer.  This is 8196 by default (this matches  the
              default  kernel  syslog  buffer  size in 2.0.33 and
              2.1.103).  If you have set  the  kernel  buffer  to
              larger  than  the  default  then this option can be
              used to view the entire buffer.

So try dmesg -s 16384. That's good enough for me on a 4-way SMP
box with lots of SCSI on-board (and trust me, SMP generates a *huge*
amount of kernel logging).


Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[David Ford]

Ion Badulescu wrote:

> On Sat, 27 Jan 2001 08:01:14 +0000, David Ford <david@linux.com> wrote:
> > Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
> > 4/5 systems I have now overflow the buffer during boot before init is
> > even launched.
>
> Hmm, are you sure? man dmesg:
> [...]
>        -sbufsize
>               use  a  buffer  of bufsize to query the kernel ring
>               buffer.  This is 8196 by default (this matches  the
>               default  kernel  syslog  buffer  size in 2.0.33 and
>               2.1.103).  If you have set  the  kernel  buffer  to
>               larger  than  the  default  then this option can be
>               used to view the entire buffer.
>
> So try dmesg -s 16384. That's good enough for me on a 4-way SMP
> box with lots of SCSI on-board (and trust me, SMP generates a *huge*
> amount of kernel logging).

Well, as I said, the (current) 16K buffer is overflowed before init is
started.  Being that I'd like to review the first page or two of boot
messages, I have to increase this limit all the time.  The above man page
needs updated, the buffer size in 2.4.0 is 16K and it doesn't matter how
large you set the dmesg -s parameter, the kernel's buffer size is the most
you can retrieve from it.

-d


--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH/REQ] Increase kmsg buffer from 16K to 32K, kernel/printk.c

[Chris Adams]

Once upon a time, David Ford  <david@linux.com> said:
>The largest bodies of text come from scsi, irda, usb, and udf.

Don't forget software RAID.  You get gobs of output from autodetect and
startup of each filesystem (so if you have 6 or so RAID filesystems, you
can get over 13kB of messages).
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/