From nobody@FreeBSD.org  Thu May 13 14:02:22 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4F49A16A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 13 May 2004 14:02:22 -0700 (PDT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id BFDAF43D48
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 13 May 2004 14:02:21 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i4DL2LEQ006273
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 13 May 2004 14:02:21 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.11/8.12.11/Submit) id i4DL2LVj006272;
	Thu, 13 May 2004 14:02:21 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200405132102.i4DL2LVj006272@www.freebsd.org>
Date: Thu, 13 May 2004 14:02:21 -0700 (PDT)
From: Stefan Bethke <stb@lassitu.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Document fix for "kmem_map too small panics"
X-Send-Pr-Version: www-2.3

>Number:         66621
>Category:       docs
>Synopsis:       Document fix for "kmem_map too small panics"
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    roam
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          update
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 13 14:10:21 PDT 2004
>Closed-Date:    Sun Feb 27 13:55:44 GMT 2005
>Last-Modified:  Sun Feb 27 13:55:44 GMT 2005
>Originator:     Stefan Bethke
>Release:        5-current
>Organization:
>Environment:
FreeBSD majestix.tallence.de 5.2-CURRENT FreeBSD 5.2-CURRENT #5: Wed May 12 12:47:06 GMT 2004     root@majestix.tallence.de:/usr/obj/usr/src/sys/MAJESTIX  i386
>Description:
solution to "kmem_map too small" panics have been requested at least 5 times on -current in the past two months; fix is simple to implement, but hard to find :-)

Kris Kennaway graciously provided advice to limit VM_KMEM_SIZE_MAX to 400 MB; that seems to be working for everybody who enquired.
>How-To-Repeat:
      
>Fix:
Index: book.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/faq/book.sgml,v
retrieving revision 1.618
diff -u -C10 -r1.618 book.sgml
cvs diff: conflicting specifications of output style
*** book.sgml   11 May 2004 13:29:47 -0000      1.618
--- book.sgml   13 May 2004 20:55:09 -0000
***************
*** 3082,3101 ****
--- 3082,3125 ----
          <question id="asusk7v-boot-failure">
            <para>The boot floppy hangs on a system with an ASUS K7V
              motherboard.  How do I fix this?</para>
          </question>
  
          <answer>
            <para>Go into the BIOS setup and disable the <quote>boot virus
              protection</quote>.</para>
          </answer>
        </qandaentry>
+ 
+       <qandaentry>
+         <question id="kmem-map-too-small">
+           <para>My system has more than 1 GB of RAM, and I'm getting panics
+             with <quote>kmem_map too small</quote> messages. What is
+             wrong?</para>
+         </question>
+ 
+         <answer>
+           <para>Normally, FreeBSD determines a number of kernel parameters,
+             such as the maximum number of open files that can be opened
+             concurrently, from the amount of memory installed in the
+             system.  On systems with one gigabyte of RAM or more, this
+             <quote>auto-sizing</quote> mechanism may choose values that are
+             too large, leading to poor performance, or even to
+             panics.</para>
+           <para>In this particular case, the kernel memory allocation map
+             is too small for the amount of memory the kernel believes it
+             should be able to allocate, hence the panic. Compile your own
+             kernel, and add the <option>VM_KMEM_SIZE_MAX</option> to your
+             kernel configuration file. Limiting the maximum size to 400 MB
+             (<option>VM_KMEM_SIZE_MAX 419430400</option>).  </para>
+         </answer>
+       </qandaentry>
      </qandaset>
    </chapter>
  
    <chapter id="troubleshoot">
      <title>Troubleshooting</title>
  
      <qandaset>
        <qandaentry>
          <question id="awre">
            <para>What do I do when I have bad blocks on my hard drive?</para>

>Release-Note:
>Audit-Trail:

From: Stefan Bethke <stb@lassitu.de>
To: Kris Kennaway <kris@obsecurity.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-doc@FreeBSD.org
Subject: Re: docs/66621: Document fix for "kmem_map too small panics"
Date: Thu, 13 May 2004 23:19:16 +0200

 Kris, would you mind looking over my write-up of the problem and the 
 work-around/solution?
 
 Since I was nagging so badly four weeks ago, I figured I'd do my part 
 to let others find the info faster :-)
 
 Thanks,
 Stefan
 
 -- 
 Stefan Bethke <stb@lassitu.de>   Fon +49 170 346 0140
 

From: Stefan Bethke <stb@lassitu.de>
To: FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: Re: docs/66621: Document fix for "kmem_map too small panics"
Date: Thu, 13 May 2004 23:22:56 +0200

 Correct syntax for options line.
 
 Index: book.sgml
 ===================================================================
 RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/faq/book.sgml,v
 retrieving revision 1.618
 diff -u -C10 -r1.618 book.sgml
 cvs diff: conflicting specifications of output style
 *** book.sgml   11 May 2004 13:29:47 -0000      1.618
 --- book.sgml   13 May 2004 21:22:14 -0000
 ***************
 *** 3082,3101 ****
 --- 3082,3125 ----
            <question id="asusk7v-boot-failure">
              <para>The boot floppy hangs on a system with an ASUS K7V
                motherboard.  How do I fix this?</para>
            </question>
 
            <answer>
              <para>Go into the BIOS setup and disable the <quote>boot 
 virus
                protection</quote>.</para>
            </answer>
          </qandaentry>
 +
 +       <qandaentry>
 +         <question id="kmem-map-too-small">
 +           <para>My system has more than 1 GB of RAM, and I'm getting 
 panics
 +             with <quote>kmem_map too small</quote> messages. What is
 +             wrong?</para>
 +         </question>
 +
 +         <answer>
 +           <para>Normally, FreeBSD determines a number of kernel 
 parameters,
 +             such as the maximum number of open files that can be 
 opened
 +             concurrently, from the amount of memory installed in the
 +             system.  On systems with one gigabyte of RAM or more, this
 +             <quote>auto-sizing</quote> mechanism may choose values 
 that are
 +             too large, leading to poor performance, or even to
 +             panics.</para>
 +           <para>In this particular case, the kernel memory allocation 
 map
 +             is too small for the amount of memory the kernel believes 
 it
 +             should be able to allocate, hence the panic. Compile your 
 own
 +             kernel, and add the <option>VM_KMEM_SIZE_MAX</option> to 
 your
 +             kernel configuration file. Limiting the maximum size to 
 400 MB
 +             (<option>options 
 VM_KMEM_SIZE_MAX=419430400</option>).</para>
 +         </answer>
 +       </qandaentry>
        </qandaset>
      </chapter>
 
      <chapter id="troubleshoot">
        <title>Troubleshooting</title>
 
        <qandaset>
          <qandaentry>
            <question id="awre">
              <para>What do I do when I have bad blocks on my hard 
 drive?</para>
 
 
 -- 
 Stefan Bethke <stb@lassitu.de>   Fon +49 170 346 0140
 
State-Changed-From-To: open->feedback 
State-Changed-By: roam 
State-Changed-When: Tue Jul 13 16:06:41 GMT 2004 
State-Changed-Why:  
Does this also apply to 4.x-STABLE?  Both the VM_KMEM_SIZE_MAX option 
and autosizing support (maxusers 0) are present in -STABLE, too. 
In this case - or actually, in any case - wouldn't it be better if 
your excellent explanation replaced the current question 5.11, 
'panic-kmemmap-too-small', which seems to pertain to pre-maxusers 
kernels? 


Responsible-Changed-From-To: freebsd-doc->roam 
Responsible-Changed-By: roam 
Responsible-Changed-When: Tue Jul 13 16:06:41 GMT 2004 
Responsible-Changed-Why:  
I'll take care of this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=66621 

From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=)
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: docs/66621
Date: Mon, 27 Sep 2004 10:03:13 +0200

 As far as I can tell from reading the code, the text proposed in the
 PR is incorrect.  On i386, VM_KMEM_SIZE_MAX defaults to 320 MB;
 setting it to 400 MB in the kernel config increases rather than
 decreases it (which is what you want, since you ran out of it!).
 Increasing the default limit may harm systems with less memory,
 though, so what we really need to do is fix the scaling algorithm so
 it takes less on machines with little memory and more on machines with
 much memory.
 
 DES
 --=20
 Dag-Erling Sm=F8rgrav - des@des.no

From: Kris Kennaway <kris@obsecurity.org>
To: freebsd-gnats-submit@FreeBSD.org, stb@lassitu.de
Cc:  
Subject: Re: docs/66621
Date: Tue, 4 Jan 2005 16:54:20 -0800

 --nVMJ2NtxeReIH9PS
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Can we get this committed, with des' correction?  (The solution to
 running out of available kmem is to increase the amount of available
 kmem).  This bug is regularly reported.
 
 Kris
 
 --nVMJ2NtxeReIH9PS
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.6 (FreeBSD)
 
 iD8DBQFB2zq8Wry0BWjoQKURAnt5AKCmpz6/xA8KsARvoNwTbw8TCkfEmACgje9y
 pfn0lOEoc5FS0IcnYBUMK8A=
 =v3Ku
 -----END PGP SIGNATURE-----
 
 --nVMJ2NtxeReIH9PS--

From: Stefan Bethke <stb@lassitu.de>
To: Kris Kennaway <kris@obsecurity.org>, des@FreeBSD.org
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: docs/66621
Date: Wed, 5 Jan 2005 02:55:55 +0100

 Am 05.01.2005 um 01:54 schrieb Kris Kennaway:
 
 > Can we get this committed, with des' correction?  (The solution to
 > running out of available kmem is to increase the amount of available
 > kmem).  This bug is regularly reported.
 
 DES wrote:
 > As far as I can tell from reading the code, the text proposed in the
 >  PR is incorrect.  On i386, VM_KMEM_SIZE_MAX defaults to 320 MB;
 >  setting it to 400 MB in the kernel config increases rather than
 >  decreases it (which is what you want, since you ran out of it!).
 
 So why is the "answer" part of this FAQ wrong then? It's specifically 
 about large-memory systems, and what to do when the auto-sizing fails; 
 it's not about changing the default in GENERIC, but rather compiling 
 your own custom kernel. Or is DES suggesting that decreasing it will 
 fix the auto-sizing, so it should be set to say 240 MB?
 
 >  Increasing the default limit may harm systems with less memory,
 >  though, so what we really need to do is fix the scaling algorithm so
 >  it takes less on machines with little memory and more on machines with
 >  much memory.
 
 Fixing the auto-sizing code would be most welcome.
 
 If anyone can think of a better explanation or suggestion, please feel 
 free!
 
 
 Cheers,
 Stefan
 
 -- 
 Stefan Bethke <stb@lassitu.de>   Fon +49 170 346 0140
 

From: Stefan Bethke <stb@lassitu.de>
To: Kris Kennaway <kris@obsecurity.org>, roam@FreeBSD.org
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: docs/66621
Date: Wed, 5 Jan 2005 03:01:21 +0100

 (I'm afraid the additions by roam@ and des@ got eaten by my spam 
 filter, so excuse me for only reacting now.)
 
 Am 05.01.2005 um 01:54 schrieb Kris Kennaway:
 
 > Can we get this committed, with des' correction?  (The solution to
 > running out of available kmem is to increase the amount of available
 > kmem).  This bug is regularly reported.
 
 roam wrote:
 > Does this also apply to 4.x-STABLE?  Both the VM_KMEM_SIZE_MAX option
 > and autosizing support (maxusers 0) are present in -STABLE, too.
 > In this case - or actually, in any case - wouldn't it be better if
 > your excellent explanation replaced the current question 5.11,
 > 'panic-kmemmap-too-small', which seems to pertain to pre-maxusers
 > kernels?
 
 I have no experience with -stable on machines with more that 512 MB 
 RAM, so I can't tell whether that's an issue there as well, and whether 
 the change would help there, too.
 
 
 Cheers,
 Stefan
 
 -- 
 Stefan Bethke <stb@lassitu.de>   Fon +49 170 346 0140
 

From: Kris Kennaway <kris@obsecurity.org>
To: Stefan Bethke <stb@lassitu.de>
Cc: Kris Kennaway <kris@obsecurity.org>, des@FreeBSD.org,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: docs/66621
Date: Tue, 4 Jan 2005 18:07:25 -0800

 --1yeeQ81UyVL57Vl7
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wed, Jan 05, 2005 at 02:55:55AM +0100, Stefan Bethke wrote:
 > Am 05.01.2005 um 01:54 schrieb Kris Kennaway:
 >=20
 > >Can we get this committed, with des' correction?  (The solution to
 > >running out of available kmem is to increase the amount of available
 > >kmem).  This bug is regularly reported.
 >=20
 > DES wrote:
 > >As far as I can tell from reading the code, the text proposed in the
 > > PR is incorrect.  On i386, VM_KMEM_SIZE_MAX defaults to 320 MB;
 > > setting it to 400 MB in the kernel config increases rather than
 > > decreases it (which is what you want, since you ran out of it!).
 >=20
 > So why is the "answer" part of this FAQ wrong then? It's specifically=20
 > about large-memory systems, and what to do when the auto-sizing fails;=20
 > it's not about changing the default in GENERIC, but rather compiling=20
 > your own custom kernel. Or is DES suggesting that decreasing it will=20
 > fix the auto-sizing, so it should be set to say 240 MB?
 
 I think he found your wording confusing, although maybe you and he are
 trying to say the same thing.
 
 Kris
 
 --1yeeQ81UyVL57Vl7
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.6 (FreeBSD)
 
 iD8DBQFB20vcWry0BWjoQKURAumBAKC35WHO5VCPy/LD+qxwEdCJRcrm9QCfQhFF
 8wVgUuKNU6FFPEkSvs6u/+E=
 =Woa5
 -----END PGP SIGNATURE-----
 
 --1yeeQ81UyVL57Vl7--

From: Stefan Bethke <stb@lassitu.de>
To: Kris Kennaway <kris@obsecurity.org>
Cc: des@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Subject: Re: docs/66621
Date: Wed, 5 Jan 2005 03:24:10 +0100

 Am 05.01.2005 um 03:07 schrieb Kris Kennaway:
 
 > On Wed, Jan 05, 2005 at 02:55:55AM +0100, Stefan Bethke wrote:
 >> Am 05.01.2005 um 01:54 schrieb Kris Kennaway:
 >>
 >>> Can we get this committed, with des' correction?  (The solution to
 >>> running out of available kmem is to increase the amount of available
 >>> kmem).  This bug is regularly reported.
 >>
 >> DES wrote:
 >>> As far as I can tell from reading the code, the text proposed in the
 >>> PR is incorrect.  On i386, VM_KMEM_SIZE_MAX defaults to 320 MB;
 >>> setting it to 400 MB in the kernel config increases rather than
 >>> decreases it (which is what you want, since you ran out of it!).
 >>
 >> So why is the "answer" part of this FAQ wrong then? It's specifically
 >> about large-memory systems, and what to do when the auto-sizing fails;
 >> it's not about changing the default in GENERIC, but rather compiling
 >> your own custom kernel. Or is DES suggesting that decreasing it will
 >> fix the auto-sizing, so it should be set to say 240 MB?
 >
 > I think he found your wording confusing, although maybe you and he are
 > trying to say the same thing.
 
 Ah, he was confusign me then :-) How about this?
 
 <para>Normally, FreeBSD determines a number of kernel parameters, such 
 as the maximum number of open files that can be opened concurrently, 
 from the amount of memory installed in the system.  On systems with one 
 gigabyte of RAM or more, this <quote>auto-sizing</quote> mechanism may 
 choose values that are too large, leading to poor performance, or even 
 to panics.</para>
 
 <para>In this particular case, the kernel memory allocation map is too 
 small for the amount of memory the kernel believes it should be able to 
 allocate, hence the panic. Compile your own kernel, and add the 
 <option>VM_KMEM_SIZE_MAX</option> to your kernel configuration file. 
 Limiting the maximum size to 400 MB (<option>options 
 VM_KMEM_SIZE_MAX=419430400</option>).</para>
 
 New:
 
 <para>Normally, FreeBSD determines a number of kernel parameters, such 
 as the maximum number of files that can be open concurrently, from the 
 amount of memory installed in the system.  On systems with one gigabyte 
 of RAM or more, this <quote>auto sizing</quote> mechanism may choose 
 values that are too high: while starting up, the kernel allocates 
 various tables and other structures that fill up most of the available 
 kernel memory. Later on, while the system is running, the kernel has no 
 more space left for dynamic memory allocations, and panics.</para>
 
 <para>Compile your own kernel, and add the 
 <option>VM_KMEM_SIZE_MAX</option> to your kernel configuration file, 
 increasing the maximum size to 400 MB (<option>options 
 VM_KMEM_SIZE_MAX=419430400</option>). 400 MB appears to be sufficient 
 for machines with up to 6 GB of memory.</para>
 
 
 Better?
 
 
 Cheers,
 Stefan
 
 -- 
 Stefan Bethke <stb@lassitu.de>   Fon +49 170 346 0140
 
State-Changed-From-To: feedback->closed 
State-Changed-By: roam 
State-Changed-When: Sun Feb 27 13:54:02 GMT 2005 
State-Changed-Why:  
Last patch committed, thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=66621 
>Unformatted:
