Re: [PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Tue, Feb 20, 2001 at 02:53:04PM -0600, Thomas Dodd wrote:
> Robert Read wrote:
>
> Why not just make the config option in Kbytes.
> and do:
>
> #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024)
>
This is good idea, but I believe LOG_BUF_LEN needs to be a power of
2. A bitmask is used in several places to wrap around the end of the
ring buffer. For example
#define LOG_BUF_MASK (LOG_BUF_LEN-1)
printk() {
log_buf[(log_start+log_size) & LOG_BUF_MASK] = *p;
}
I think LOG_BUF_LEN could be defined to round up (or down) at compile
time, but my post-lunch-sleepy brain can't think of the trick to do
it.
robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Robert Read wrote: > I have used 128k and larger buffer sizes, and I just noticed this > fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: > > I am encouraged to try a large buffer then. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Thomas Dodd wrote: > > Robert Read wrote: > > > > Ok, here is a simple patch to add a config option, I'm compiling it > > now, so it's not tested yet. One question: what is the best way to > > force this option to be a power of 2? > > Why not just make the config option in Kbytes. > and do: > > #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024) > > since the config option has a default option and will > always be defined, is the #ifdef check really needed? Oops... It's not needed if all arch's have the config option added. Only parisc uses a different file, config.common instead of config.in Would this break any thing? -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Robert Read wrote: > > On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote: > > Robert Read wrote: > > > > > > On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: > > > > > > > > Has anyone tried 128K buffer size in kernel/printk.c > > > > and still have the kernel boot (without > > > > hard to notice memory corruption problems and other subtle bugs)? > > > > Any hints and tips will be appreciated. > > > > > > I have used 128k and larger buffer sizes, and I just noticed this > > > fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: > > > > I think this should be a config option. > > Ok, here is a simple patch to add a config option, I'm compiling it > now, so it's not tested yet. One question: what is the best way to > force this option to be a power of 2? Why not just make the config option in Kbytes. and do: #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024) since the config option has a default option and will always be defined, is the #ifdef check really needed? -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote: > Robert Read wrote: > > > > On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: > > > > > > Has anyone tried 128K buffer size in kernel/printk.c > > > and still have the kernel boot (without > > > hard to notice memory corruption problems and other subtle bugs)? > > > Any hints and tips will be appreciated. > > > > I have used 128k and larger buffer sizes, and I just noticed this > > fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: > > I think this should be a config option. Ok, here is a simple patch to add a config option, I'm compiling it now, so it's not tested yet. One question: what is the best way to force this option to be a power of 2? robert diff -ru linux-2.4.2-pre4/arch/i386/config.in linux-2.4.2-pre4-logbuf/arch/i386/config.in --- linux-2.4.2-pre4/arch/i386/config.inMon Jan 8 13:27:56 2001 +++ linux-2.4.2-pre4-logbuf/arch/i386/config.in Tue Feb 20 12:10:19 2001 @@ -366,4 +366,5 @@ #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ +int 'Printk buffer size (must be power of 2)' CONFIG_PRINTK_BUF_LEN 16384 endmenu Only in linux-2.4.2-pre4-logbuf/arch/i386: config.in~ Only in linux-2.4.2-pre4-logbuf/include: asm Only in linux-2.4.2-pre4-logbuf/include/linux: autoconf.h Only in linux-2.4.2-pre4-logbuf/include/linux: modules diff -ru linux-2.4.2-pre4/kernel/printk.c linux-2.4.2-pre4-logbuf/kernel/printk.c --- linux-2.4.2-pre4/kernel/printk.cTue Feb 20 11:56:31 2001 +++ linux-2.4.2-pre4-logbuf/kernel/printk.c Tue Feb 20 11:59:35 2001 @@ -23,7 +23,11 @@ #include -#define LOG_BUF_LEN(16384) +#ifdef CONFIG_PRINTK_BUF_LEN +# define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN) +#else +# define LOG_BUF_LEN (16384) +#endif #define LOG_BUF_MASK (LOG_BUF_LEN-1) static char buf[1024];
Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Robert Read wrote: > > On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: > > > > Has anyone tried 128K buffer size in kernel/printk.c > > and still have the kernel boot (without > > hard to notice memory corruption problems and other subtle bugs)? > > Any hints and tips will be appreciated. > > I have used 128k and larger buffer sizes, and I just noticed this > fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: I think this should be a config option. I use software RADI (md.o) and with 9 md devices, the 16k buffer overflows, and I get md6-md0 in the logs, but nothing prior to md6 being detected/started. I bumbed it upo to 32K and checked the size ofter boot and it's ~26K right now. If I add more partitions/disks to the arrays, or more arrays, that'll be too small. A dynamic size would be even better. Start with 1M or so and add a dmesg hook to rezize it to 8-16K and frre up the rest, so init scripts can save the boot buffer, then keep a smaller buffer during normal use. If you have problems you can change the dmesg call to not change the buffer, and keep the bigger buffer or perhaps make it even bigger. Has anyone tried this before? -Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: > > Has anyone tried 128K buffer size in kernel/printk.c > and still have the kernel boot (without > hard to notice memory corruption problems and other subtle bugs)? > Any hints and tips will be appreciated. I have used 128k and larger buffer sizes, and I just noticed this fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: --- linux/kernel/printk.c.orig Sun Jan 28 20:24:13 2001 +++ linux/kernel/printk.c Wed Jan 31 23:21:25 2001 @@ -22,7 +22,11 @@ #include -#define LOG_BUF_LEN(16384) +#if CONFIG_TUX_DEBUG +# define LOG_BUF_LEN (16384*128) +#else +# define LOG_BUF_LEN (16384) +#endif #define LOG_BUF_MASK (LOG_BUF_LEN-1) static char buf[1024]; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Subject: kernel/printk.c: increase the buffer size to capture devfsd debug messages. Short Question: Can I use (128*1024) for the buffer size in kernel/printk.c and still boot the kernel using loadlin? Long question and background: I have been trying to track down a subtle anomaly (not a fatal bug, but an annoying feature) of devfs device name registration. I am using scsi devices, and the problem is (quoting from my earlier post): >Namely the name "generic" or "disc" seem to >exist from the start (after bootup), but >the entry "cd" doesn't exist until I do something >about accessing the CD somehow. >(It seems that I fail the initial >attempt to mount due to the missing name.) Strange thing is that "generic" is registered right from the start by the time I try to list the device entries under a particular LUN of a multi-CD changer device. (Doug Gilbert was kind enough to look over my config files, and he could not find anomaly in my setup.) Anyway, by enabling the devfs debug message generation in the kernel, I can follow what devfs (and devfsd) are doing during the bootup and subsequent multi-user transition phase, etc.. By tracing the messages, I am hoping I learn how the devfs and devfsd interact in a real world setting. There may be a thing or two that may have been overlooked during the transition to the final 2.4.x kernel. However, during this effort, I noticed one problem. printk() uses rather smallish buffer (16K by default. Actually large enough for ordinary use, I think.) Since devfs generates large amount of messages (depending on the boot command line option.), the initial part of messages is gone from dmesg output. I have learned to used "-s" option of dmesg to use a non-default value of the kernel buffer that stores the messages that dmesg prints out. 16K is too small for devfs debugging. I increased the kernel message size in kernel/printk.c to 32KB. Still no luck. Then to 64K. I still don't see the initial part of boot up message in dmesg. (However, I am now seeing the interesting part where somehow "generic" is registered where "sr" names aren't. lookup of "sr" names are done just prior to SCSI listing in the dmesg whereas "generic" registration happens after the listing. I am trying to figure out why.) Now I used the following loadlin command line. c:\loadlin\loadlin c:\loadlin\241-64k.dbg -noheap \ devfs=mount,dmod,dreg,dilookup root=/dev/sda6 ro vga=3 \ scsihosts=sym53c8xx:tmscsim (No linebreaks in the real bat file.) Now I have a big question about the dmesg message buffer, or rather its size. Can I use an arbitrary value for buffer size in kernel/printk.c? That is, does the size need to be in the form of 2**N (two to the power of some integer number)? I vaguely recall having read something about this. I checked the code, and the code in printk.c itself doesn't seem to have such a restrction. But you never know. I am worried because - if such restrction is there, the next value I can try is 128K, which is rather large for a static kernel data structure, and - at 128KB, I am wondering if that large buffer size may have issues with loader program loadlin.exe invoked from DOS. (I am not sure if the big area used by such a large array may interfere with the initial memory allocation done by loadlin.exe. The bzipped kernel image is already slight ly over 700Kb. I have heard some problems hitting memory size limit during loading, etc.) Has anyone tried 128K buffer size in kernel/printk.c and still have the kernel boot (without hard to notice memory corruption problems and other subtle bugs)? Any hints and tips will be appreciated. Happy Hacking, Chiaki Ishikawa PS: FYI, I am quoting my initial question to see if anyone has experienced something similar. Maybe the strange beast (multi-LUN CD changer) is to blame. --- (Below is a partially edited quote of an e-mail I sent to linux-scsi mailing list.) I have begun using devfs for about a couple of weeks now and thank you for the great addition to linux. Now I am happy to see the device names on the scsi chain which won't be changed just because I add/delete a device. However, I noticed that there seems to be a subtle interaction of devfs (+devfsd) and the device names that appear under luns for a scsi chain. Namely the name "generic" or "disc" seem to exist from the start (after bootup), but the entry "cd" doesn't exist until I do something about accessing the CD somehow. (It seems that I fail the initial attempt to mount due to the missing name.) > Below is the more detailed problem about devfs > name recognition thing. > Has anyone seen something like this before? > > I am not entirely sure where to report this. > (It might as well be the scsi system problem...) > Help will be appreciated where to send the bug reports, etc.. > (Forwarding will be fine.) > > Happy Hacking, > > Chiaki > > --- > I us
