os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add an entry about rpc.stad not using 256MB of memory.

Browse source 
PR:		docs/25340
Submitted by:	Dima Dorfman <dima@unixfreak.org>

Explain what the "unknown: <PNP....> can't assign resources" message
means.

PR:		docs/25317
Submitted by:	Michael Lucas <mwlucas@blackhelicopters.org>
This commit is contained in:
Nik Clayton 2001-02-24 12:18:04 +00:00
parent 896c50c530
commit 9358f220b4
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=8832
2 changed files with 80 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
en_US.ISO8859-1/books/faq/book.sgml
View file

@ -11,7 +11,7 @@
<corpauthor>The FreeBSD Documentation Project</corpauthor>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.143 2001/02/06 00:32:37 nik Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.144 2001/02/17 01:07:43 nik Exp $</pubdate>
<abstract>
<para>This is the FAQ for FreeBSD versions 2.X, 3.X, and 4.X.
@ -5871,6 +5871,21 @@ C:\="DOS"</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question id="pnp-resources">
<para>I get messages like: <errorname>unknown: &lt;PNP0303> can't
assign resources</errorname> on boot</para>
</question>
<answer>
<para>These indicate Plug-and-Play devices that the current
kernel doesn't have drivers for. They're harmless.</para>
<para>If you dislike these messages, the FreeBSD Project
will happily accept driver contributions via send-pr.</para>
</answer>
</qandaentry>
<qandaentry>
<question id="user-quotas">
@ -6795,6 +6810,30 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
&man.rc.conf.5; man page for more information on rc.conf.</para>
</answer>
</qandaentry>
<qandaentry>
<question id="statd-mem-leak">
<para>There is a memory leak in &man.rpc.statd.8;! It is using
256 Mbytes of memory!</para>
</question>
<answer>
<para>No, there is no memory leak, and it's not using 256 Mbytes
of memory. It simply likes to (i.e., always does) map an
obscene amount of memory into its address space for convenience.
There is nothing terribly wrong with this from a technical
standpoint; it just throws off things like &man.top.1; and
&man.ps.1;.</para>
<para>&man.rpc.statd.8; maps its status file (resident on
<filename>/var</filename>) into its address space; to save
worrying about remapping it later when it needs to grow, it maps
it with a generious size. This is very evident from the source
code, where one can see that the length argument to &man.mmap.2;
is <literal>0x10000000</literal>, or one sixteenth of the
address space on an IA32, or exactly 256MB.</para>
</answer>
</qandaentry>
</qandaset>
</chapter>

41
en_US.ISO_8859-1/books/faq/book.sgml
View file

@ -11,7 +11,7 @@
<corpauthor>The FreeBSD Documentation Project</corpauthor>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.143 2001/02/06 00:32:37 nik Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.144 2001/02/17 01:07:43 nik Exp $</pubdate>
<abstract>
<para>This is the FAQ for FreeBSD versions 2.X, 3.X, and 4.X.
@ -5871,6 +5871,21 @@ C:\="DOS"</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question id="pnp-resources">
<para>I get messages like: <errorname>unknown: &lt;PNP0303> can't
assign resources</errorname> on boot</para>
</question>
<answer>
<para>These indicate Plug-and-Play devices that the current
kernel doesn't have drivers for. They're harmless.</para>
<para>If you dislike these messages, the FreeBSD Project
will happily accept driver contributions via send-pr.</para>
</answer>
</qandaentry>
<qandaentry>
<question id="user-quotas">
@ -6795,6 +6810,30 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
&man.rc.conf.5; man page for more information on rc.conf.</para>
</answer>
</qandaentry>
<qandaentry>
<question id="statd-mem-leak">
<para>There is a memory leak in &man.rpc.statd.8;! It is using
256 Mbytes of memory!</para>
</question>
<answer>
<para>No, there is no memory leak, and it's not using 256 Mbytes
of memory. It simply likes to (i.e., always does) map an
obscene amount of memory into its address space for convenience.
There is nothing terribly wrong with this from a technical
standpoint; it just throws off things like &man.top.1; and
&man.ps.1;.</para>
<para>&man.rpc.statd.8; maps its status file (resident on
<filename>/var</filename>) into its address space; to save
worrying about remapping it later when it needs to grow, it maps
it with a generious size. This is very evident from the source
code, where one can see that the length argument to &man.mmap.2;
is <literal>0x10000000</literal>, or one sixteenth of the
address space on an IA32, or exactly 256MB.</para>
</answer>
</qandaentry>
</qandaset>
</chapter>