[lkml]   [2003]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: Linux 2.4.22-pre10
On Fri, Aug 01, 2003 at 01:19:11PM -0300, Marcelo Tosatti wrote:
> Hello,
> Here goes -pre10, hopefully the last -pre of 2.4.22.
> It contains a bunch of important fixes, detailed below.
> Please help testing.

Hi Marcelo,

First, one word : Congratulations !

This is the _first_ vanilla 2.4 kernel which I can run _unpatched_ on my
customer's firewalls. This one was stressed all the day at 4000 hits/s.
Subsystems and drivers include aic7xxx, cpqarray, bonding, tulip, eepro100,
sunhme, PIII / PPro SMP, netfilter. Everything looks fine and smooth even at a
sustained write rate of 900 kB/s (logs). I only loose and corrupt significant
number of firewall logs above 3000 lines/s if I don't extend the log buffer
size. I've been using the fairly simple attached patch for a few months now
with success (no loss up to 5600 lines/s). I believe Randy Dunlap has already
got nearly the same one included in 2.5/2.6, so may want to include it too
since it's not really intrusive, although my customer can survive with one
patch :-)

Second, I'm writing this mail from my alpha :

bash-2.03$ uname -a
Linux alpha 2.4.22-pre10 #1 Fri Aug 1 23:20:31 CEST 2003 alpha unknown

It compiled without a glitch and I've got no error in the logs yet. The
previous stable version on this machine was 2.4.21-rc3 + aic7xxx from Justin.
For the record, this one is an NFS server on reiserfs on soft raid5 on aic7xxx.

Third, my VAIO likes it a lot since I can now power it off without holding the
button during 4 seconds !

So for me, it looks like the cleanest 2.4 to date. I will only tell you in 450
days if it's as much reliable as have been my old ones for the last 450 days of
interrupted service :-)

I hope we'll get other positive records so that we can quickly get 2.4.22.

Thanks to you and all others in $ChangeLog for this good version !

patch : make LOG_BUF_LEN configurable at config time

diff -urN wt10-pre3/Documentation/ wt10-pre3-log-buf-len/Documentation/
--- wt10-pre3/Documentation/ Wed Mar 19 09:58:25 2003
+++ wt10-pre3-log-buf-len/Documentation/ Tue Mar 25 08:20:35 2003
@@ -25231,6 +25231,19 @@
output to the second serial port on these devices. Saying N will
cause the debug messages to appear on the first serial port.

+Kernel log buffer length shift
+ The kernel log buffer has a fixed size of :
+ 64 kB (2^16) on MULTIQUAD and IA64,
+ 128 kB (2^17) on S390
+ 32 kB (2^15) on SMP systems
+ 16 kB (2^14) on UP systems
+ You have the ability to change this size with this parameter which
+ fixes the bit shift used to get the buffer length (which must be a
+ power of 2). Eg: a value of 16 sets the buffer to 64 kB (2^16).
+ The default value of 0 uses standard values above.
Disable pgtable cache
Normally the kernel maintains a `quicklist' of preallocated
diff -urN wt10-pre3/arch/i386/ wt10-pre3-log-buf-len/arch/i386/
--- wt10-pre3/arch/i386/ Wed Mar 19 09:58:25 2003
+++ wt10-pre3-log-buf-len/arch/i386/ Tue Mar 25 08:25:12 2003
@@ -508,6 +508,8 @@
string ' Initial kernel command line' CONFIG_CMDLINE "root=301 ro"

+int 'Kernel messages buffer length shift (0 = default)' CONFIG_LOG_BUF_SHIFT 0

source lib/
diff -urN wt10-pre3/kernel/printk.c wt10-pre3-log-buf-len/kernel/printk.c
--- wt10-pre3/kernel/printk.c Wed Mar 19 09:58:20 2003
+++ wt10-pre3-log-buf-len/kernel/printk.c Tue Mar 25 08:14:55 2003
@@ -29,6 +29,7 @@

#include <asm/uaccess.h>

+#if !defined(CONFIG_LOG_BUF_SHIFT) || (CONFIG_LOG_BUF_SHIFT - 0 == 0)
#if defined(CONFIG_MULTIQUAD) || defined(CONFIG_IA64)
#define LOG_BUF_LEN (65536)
#elif defined(CONFIG_ARCH_S390)
@@ -37,6 +38,9 @@
#define LOG_BUF_LEN (32768)
#define LOG_BUF_LEN (16384) /* This must be a power of two */


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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