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

Replace all foo(1) with proper man entities

Browse source
This commit is contained in:
Udo Erdelhoff 2001-05-22 17:15:12 +00:00
parent 9a9106675f
commit d9a9145319
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=9484
2 changed files with 40 additions and 40 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
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.200 2001/05/20 23:04:46 ue Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.201 2001/05/22 17:13:11 ue Exp $</pubdate>
<copyright>
<year>1995</year>
@ -677,7 +677,7 @@
and <ulink
URL="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
query</ulink>
interfaces. The <command>send-pr(1)</command> command can
interfaces. The &man.send-pr.1; command can
also be used to submit problem reports and change requests via
electronic mail.</para>
</answer>
@ -4907,7 +4907,7 @@ kern.timecounter.hardware: TSC -&gt; i8254</screen>
<para>Use the package installation menu in
<filename>/stand/sysinstall</filename> (under the
post-configuration menu item) or invoke the
<command>pkg_add(1)</command> command on the specific package
&man.pkg.add.1; command on the specific package
files you're interested in installing. Package files can
usually be identified by their <filename>.tgz</filename> suffix
and CDROM distribution people will have a
@ -11331,7 +11331,7 @@ raisechar=^^</programlisting>
<para>Two hundred to complain about the color of the bicycle
shed;</para>
<para>Three to point out that the patch breaks style(9);</para>
<para>Three to point out that the patch breaks &man.style.9;;</para>
<para>Seventeen to complain that the proposed new lightbulb is
under GPL;</para>
@ -11897,7 +11897,7 @@ Cc: current@FreeBSD.org</programlisting>
<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 generate a stack trace on the
&man.gdb.1; to generate a stack trace on the
crash dump.</para>
<para>In any case, the method I normally use is this:</para>
@ -11941,19 +11941,19 @@ Cc: current@FreeBSD.org</programlisting>
<filename>kernel.debug</filename>. <filename>kernel</filename>
was installed as <filename>/kernel</filename>, while
<filename>kernel.debug</filename> can be used as the source of
debugging symbols for gdb(1).</para>
debugging symbols for &man.gdb.1;.</para>
<para>To make sure you capture a crash dump, you need edit
<filename>/etc/rc.conf</filename> and set
<literal>dumpdev</literal> to point to your swap
partition. This will cause the <command>rc(8)</command> scripts
to use the <command>dumpon(8)</command> command to enable crash
dumps. You can also run <command>dumpon(8)</command> manually.
partition. This will cause the &man.rc.8; scripts
to use the &man.dumpon.8; command to enable crash
dumps. You can also run &man.dumpon.8; manually.
After a panic, the crash dump can be recovered using
<command>savecore(8)</command>; if
&man.savecore.8;; if
<literal>dumpdev</literal> is set in
<filename>/etc/rc.conf</filename>, the <command>rc(8)</command>
scripts will run <command>savecore(8)</command> automatically
<filename>/etc/rc.conf</filename>, the &man.rc.8;
scripts will run &man.savecore.8; automatically
and put the crash dump in
<filename>/var/crash</filename>.</para>
@ -11963,7 +11963,7 @@ Cc: current@FreeBSD.org</programlisting>
64MB of RAM, you will get a 64MB crash dump. Therefore you
must make sure there's enough space in
<filename>/var/crash</filename> to hold the dump.
Alternatively, you run <command>savecore(8)</command>
Alternatively, you run &man.savecore.8;
manually and have it recover the crash dump to another
directory where you have more room. It's possible to limit
the size of the crash dump by using <literal>options
@ -11975,25 +11975,25 @@ Cc: current@FreeBSD.org</programlisting>
</note>
<para>Once you have recovered the crash dump, you can get a
stack trace with <command>gdb(1)</command> as follows:</para>
stack trace with &man.gdb.1; as follows:</para>
<screen>&prompt.user; <userinput>gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0</userinput>
<prompt>(gdb)</prompt> <userinput>where</userinput></screen>
<para>Note that there may be several screens worth of
information; ideally you should use
<command>script(1)</command> to capture all of them. Using the
&man.script.1; to capture all of them. Using the
unstripped kernel image with all the debug symbols should show
the exact line of kernel source code where the panic occured.
Usually you have to read the stack trace from the bottom up in
order to trace the exact sequence of events that lead to the
crash. You can also use <command>gdb(1)</command> to print out
crash. You can also use &man.gdb.1; to print out
the contents of various variables or structures in order to
examine the system state at the time of the crash.</para>
<para>Now, if you're really insane and have a second computer,
you can also configure <command>gdb(1)</command> to do remote
debugging such that you can use <command>gdb(1)</command> on
you can also configure &man.gdb.1; to do remote
debugging such that you can use &man.gdb.1; on
one system to debug the kernel on another system, including
setting breakpoints, single-stepping through the kernel code,
just like you can do with a normal user-mode program. I haven't
@ -12086,8 +12086,8 @@ SECTIONS
.interp : { *(.interp) }</programlisting>
<para>Then reconfig and rebuild your kernel. You will probably
have problems with <command>ps(1)</command>,
<command>top(1)</command> and the like; <command>make
have problems with &man.ps.1;
&man.top.1; and the like; <command>make
world</command> should take care of it (or a manual rebuild of
<filename>libkvm</filename>,
<command>ps</command> and <command>top</command>

40
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.200 2001/05/20 23:04:46 ue Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.201 2001/05/22 17:13:11 ue Exp $</pubdate>
<copyright>
<year>1995</year>
@ -677,7 +677,7 @@
and <ulink
URL="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
query</ulink>
interfaces. The <command>send-pr(1)</command> command can
interfaces. The &man.send-pr.1; command can
also be used to submit problem reports and change requests via
electronic mail.</para>
</answer>
@ -4907,7 +4907,7 @@ kern.timecounter.hardware: TSC -&gt; i8254</screen>
<para>Use the package installation menu in
<filename>/stand/sysinstall</filename> (under the
post-configuration menu item) or invoke the
<command>pkg_add(1)</command> command on the specific package
&man.pkg.add.1; command on the specific package
files you're interested in installing. Package files can
usually be identified by their <filename>.tgz</filename> suffix
and CDROM distribution people will have a
@ -11331,7 +11331,7 @@ raisechar=^^</programlisting>
<para>Two hundred to complain about the color of the bicycle
shed;</para>
<para>Three to point out that the patch breaks style(9);</para>
<para>Three to point out that the patch breaks &man.style.9;;</para>
<para>Seventeen to complain that the proposed new lightbulb is
under GPL;</para>
@ -11897,7 +11897,7 @@ Cc: current@FreeBSD.org</programlisting>
<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 generate a stack trace on the
&man.gdb.1; to generate a stack trace on the
crash dump.</para>
<para>In any case, the method I normally use is this:</para>
@ -11941,19 +11941,19 @@ Cc: current@FreeBSD.org</programlisting>
<filename>kernel.debug</filename>. <filename>kernel</filename>
was installed as <filename>/kernel</filename>, while
<filename>kernel.debug</filename> can be used as the source of
debugging symbols for gdb(1).</para>
debugging symbols for &man.gdb.1;.</para>
<para>To make sure you capture a crash dump, you need edit
<filename>/etc/rc.conf</filename> and set
<literal>dumpdev</literal> to point to your swap
partition. This will cause the <command>rc(8)</command> scripts
to use the <command>dumpon(8)</command> command to enable crash
dumps. You can also run <command>dumpon(8)</command> manually.
partition. This will cause the &man.rc.8; scripts
to use the &man.dumpon.8; command to enable crash
dumps. You can also run &man.dumpon.8; manually.
After a panic, the crash dump can be recovered using
<command>savecore(8)</command>; if
&man.savecore.8;; if
<literal>dumpdev</literal> is set in
<filename>/etc/rc.conf</filename>, the <command>rc(8)</command>
scripts will run <command>savecore(8)</command> automatically
<filename>/etc/rc.conf</filename>, the &man.rc.8;
scripts will run &man.savecore.8; automatically
and put the crash dump in
<filename>/var/crash</filename>.</para>
@ -11963,7 +11963,7 @@ Cc: current@FreeBSD.org</programlisting>
64MB of RAM, you will get a 64MB crash dump. Therefore you
must make sure there's enough space in
<filename>/var/crash</filename> to hold the dump.
Alternatively, you run <command>savecore(8)</command>
Alternatively, you run &man.savecore.8;
manually and have it recover the crash dump to another
directory where you have more room. It's possible to limit
the size of the crash dump by using <literal>options
@ -11975,25 +11975,25 @@ Cc: current@FreeBSD.org</programlisting>
</note>
<para>Once you have recovered the crash dump, you can get a
stack trace with <command>gdb(1)</command> as follows:</para>
stack trace with &man.gdb.1; as follows:</para>
<screen>&prompt.user; <userinput>gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0</userinput>
<prompt>(gdb)</prompt> <userinput>where</userinput></screen>
<para>Note that there may be several screens worth of
information; ideally you should use
<command>script(1)</command> to capture all of them. Using the
&man.script.1; to capture all of them. Using the
unstripped kernel image with all the debug symbols should show
the exact line of kernel source code where the panic occured.
Usually you have to read the stack trace from the bottom up in
order to trace the exact sequence of events that lead to the
crash. You can also use <command>gdb(1)</command> to print out
crash. You can also use &man.gdb.1; to print out
the contents of various variables or structures in order to
examine the system state at the time of the crash.</para>
<para>Now, if you're really insane and have a second computer,
you can also configure <command>gdb(1)</command> to do remote
debugging such that you can use <command>gdb(1)</command> on
you can also configure &man.gdb.1; to do remote
debugging such that you can use &man.gdb.1; on
one system to debug the kernel on another system, including
setting breakpoints, single-stepping through the kernel code,
just like you can do with a normal user-mode program. I haven't
@ -12086,8 +12086,8 @@ SECTIONS
.interp : { *(.interp) }</programlisting>
<para>Then reconfig and rebuild your kernel. You will probably
have problems with <command>ps(1)</command>,
<command>top(1)</command> and the like; <command>make
have problems with &man.ps.1;
&man.top.1; and the like; <command>make
world</command> should take care of it (or a manual rebuild of
<filename>libkvm</filename>,
<command>ps</command> and <command>top</command>