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

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>

en_US.ISO8859-1/books/faq/book.sgml

@@ -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>
 

en_US.ISO_8859-1/books/faq/book.sgml

@@ -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>