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

Update the FAQ to reflect the fact that we are no longer waiting for

Browse source 
FreeBSD 3.0 to get out of beta.
This commit is contained in:
Murray Stokely 2001-04-12 23:13:47 +00:00
parent 703d60fd8f
commit f91a22dcd5
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=9182
2 changed files with 8 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

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

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

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