>Number:         25860
>Category:       kern
>Synopsis:       MSGBUFSIZE > 512K generates many bytes of 0xff in message buffer
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 07 15:26:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Ross Patterson
>Release:        1.6
>Organization:
CatchFIRE Systems, Inc
>Environment:
NetBSD devo.rap.catchfs.com 1.6 NetBSD 1.6 (GENERIC) #0: Sun Sep  8 19:43:40 UTC 2002     autobuild@tgm.daemon.org:/autobuild/i386/OBJ/autobuild/src/sys/arch/i386/compile/GENERIC i386
>Description:
If you configure and build a kernel with MSGBUFSIZE larger than 512KB, the kernel only appears to use the first 512KB.  That's bad, but not too bad.  Unfortunately, /dev/klog and the KERN_MSGBUF sysctl retrieve the entire buffer.  The unused bytes are delivered as gigantic runs of 0xff. 

NetBSD 1.6 exhibits the problem, 1.5 does not.

There doesn't seem to be a documented limit to MSGBUFSIZE ("man 4 optoins" doesn't list one, nor do any .h files we've checked).  I've built kernels with up to 2MB reserved for the buffer (for intensive kernel debugging), and everything is fine except that the kernel won't use more than 512KB.

I suspect there's something implicit in Intel x86 memory segmenting, but  I can't glean enough information from  kern/subr_log.c, arch/i386/i386/machdep.c and arch/i386/i386/pmap.c to be certain.
>How-To-Repeat:
Build a kernel with 

options                MSGBUFSIZE="(2*1024*1024)"

Boot, gernerate a lot of kernel printf's and then "dmesg" or list peruse /var/log/messages.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: