Bug 66621
| Summary: | Document fix for "kmem_map too small panics" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Documentation | Reporter: | Stefan Bethke <stb> | ||||
| Component: | Books & Articles | Assignee: | Peter Pentchev <roam> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Stefan Bethke
2004-05-13 22:10:21 UTC
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 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 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 I'll take care of this. 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 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 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 (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 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.
Kris
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 Last patch committed, thanks! |
