From f91a22dcd522570fb5bd913e675a4db48daa4af3 Mon Sep 17 00:00:00 2001
From: Murray Stokely <murray@FreeBSD.org>
Date: Thu, 12 Apr 2001 23:13:47 +0000
Subject: [PATCH] Update the FAQ to reflect the fact that we are no longer
 waiting for FreeBSD 3.0 to get out of beta.

---
 en_US.ISO8859-1/books/faq/book.sgml  | 13 ++++---------
 en_US.ISO_8859-1/books/faq/book.sgml | 13 ++++---------
 2 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/en_US.ISO8859-1/books/faq/book.sgml b/en_US.ISO8859-1/books/faq/book.sgml
index fb08f6033a..a3c5801ef2 100644
--- a/en_US.ISO8859-1/books/faq/book.sgml
+++ b/en_US.ISO8859-1/books/faq/book.sgml
@@ -14,7 +14,7 @@
 
     <corpauthor>The FreeBSD Documentation Project</corpauthor>
 
-    <pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.169 2001/04/11 01:44:24 murray Exp $</pubdate>
+    <pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.170 2001/04/12 23:04:43 murray Exp $</pubdate>
 
     <copyright>
       <year>1995</year>
@@ -11842,14 +11842,9 @@ Cc: current@FreeBSD.org</programlisting>
             table.</para>
 
           <para> The best way to track down the cause of a panic is by
-            capturing a crash dump, then using <command>gdb(1)</command>
-            to a stack trace on the crash dump. Of course, this depends
-            on <command>gdb(1)</command> in -CURRENT working correctly,
-            which I can't guarantee (I recall somebody saying that the new
-            ELF-ized <command>gdb(1)</command> didn't handle kernel crash
-            dumps correctly: somebody should check this before 3.0 goes out
-            of beta or there'll be a lot of red faces after the CDs
-            ship).</para>
+            capturing a crash dump, then using
+            <command>gdb(1)</command> to generate a stack trace on the
+            crash dump.</para>
 
           <para>In any case, the method I normally use is this:</para>
 
diff --git a/en_US.ISO_8859-1/books/faq/book.sgml b/en_US.ISO_8859-1/books/faq/book.sgml
index fb08f6033a..a3c5801ef2 100644
--- a/en_US.ISO_8859-1/books/faq/book.sgml
+++ b/en_US.ISO_8859-1/books/faq/book.sgml
@@ -14,7 +14,7 @@
 
     <corpauthor>The FreeBSD Documentation Project</corpauthor>
 
-    <pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.169 2001/04/11 01:44:24 murray Exp $</pubdate>
+    <pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.170 2001/04/12 23:04:43 murray Exp $</pubdate>
 
     <copyright>
       <year>1995</year>
@@ -11842,14 +11842,9 @@ Cc: current@FreeBSD.org</programlisting>
             table.</para>
 
           <para> The best way to track down the cause of a panic is by
-            capturing a crash dump, then using <command>gdb(1)</command>
-            to a stack trace on the crash dump. Of course, this depends
-            on <command>gdb(1)</command> in -CURRENT working correctly,
-            which I can't guarantee (I recall somebody saying that the new
-            ELF-ized <command>gdb(1)</command> didn't handle kernel crash
-            dumps correctly: somebody should check this before 3.0 goes out
-            of beta or there'll be a lot of red faces after the CDs
-            ship).</para>
+            capturing a crash dump, then using
+            <command>gdb(1)</command> to generate a stack trace on the
+            crash dump.</para>
 
           <para>In any case, the method I normally use is this:</para>