svn commit: r44838 - head/en_US.ISO8859-1/books/faq
Dru Lavigne
dru at FreeBSD.org
Thu May 15 00:14:10 UTC 2014
Author: dru
Date: Thu May 15 00:14:09 2014
New Revision: 44838
URL: http://svnweb.freebsd.org/changeset/doc/44838
Log:
Remove most of the leftover instances of "you".
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/faq/book.xml
Modified: head/en_US.ISO8859-1/books/faq/book.xml
==============================================================================
--- head/en_US.ISO8859-1/books/faq/book.xml Wed May 14 21:45:28 2014 (r44837)
+++ head/en_US.ISO8859-1/books/faq/book.xml Thu May 15 00:14:09 2014 (r44838)
@@ -6438,37 +6438,33 @@ ATDT1234567</programlisting>
can be displayed using the <literal>show hdlc</literal>
command.</para>
- <para>If your link is bad (or if your serial driver is
- dropping packets), you will see the occasional FCS error.
+ <para>If the link is bad or if the serial driver is
+ dropping packets, it will produce the occasional FCS error.
This is not usually worth worrying about although it does
- slow down the compression protocols substantially. If you
- have an external modem, make sure your cable is properly
- shielded from interference — this may eradicate the
- problem.</para>
-
- <para>If your link freezes as soon as you have connected and
- you see a large number of FCS errors, this may be because
- your link is not 8-bit clean. Make sure your modem is not
- using software flow control (XON/XOFF). If your datalink
- <emphasis>must</emphasis> use software flow control, use
- the command <literal>set accmap 0x000a0000</literal> to
+ slow down the compression protocols substantially.</para>
+
+ <para>If the link freezes as soon as it connects and
+ produces a large number of FCS errors, make sure the modem is not
+ using software flow control (XON/XOFF). If the link
+ must use software flow control, use
+ <literal>set accmap 0x000a0000</literal> to
tell &man.ppp.8; to escape the <literal>^Q</literal> and
<literal>^S</literal> characters.</para>
- <para>Another reason for seeing too many FCS errors may be
+ <para>Another reason for too many FCS errors may be
that the remote end has stopped talking
- <acronym>PPP</acronym>. You may want to enable
- <literal>async</literal> logging at this point to
+ <acronym>PPP</acronym>. In this case, enable
+ <literal>async</literal> logging to
determine if the incoming data is actually a login or
- shell prompt. If you have a shell prompt at the remote
+ shell prompt. If it is a shell prompt at the remote
end, it is possible to terminate &man.ppp.8; without
- dropping the line by using <command>close lcp</command> (a
- following <command>term</command>) will reconnect you to
+ dropping the line by using <command>close lcp</command> followed by
+ <command>term</command>) to reconnect to
the shell on the remote machine.</para>
- <para>If nothing in your log file indicates why the link
- might have been terminated, you should ask the remote
- administrator (your ISP?) why the session was
+ <para>If nothing in the log file indicates why the link
+ was terminated, ask the remote
+ administrator or ISP why the session was
terminated.</para>
</answer>
</qandaentry>
@@ -6480,12 +6476,11 @@ ATDT1234567</programlisting>
</question>
<answer>
- <para>If all else fails, send as much information as you
- can, including your config files, how you are starting
- &man.ppp.8;, the relevant parts of your log file and the
- output of <command>netstat -rn</command> (before and after
- connecting) to the &a.questions; and someone should point
- you in the right direction.</para>
+ <para>If all else fails, send the details of the error, the
+ configuration files, how
+ &man.ppp.8; is being started, the relevant parts of the log file, and the
+ output of <command>netstat -rn</command>, before and after
+ connecting, to the &a.questions;.</para>
</answer>
</qandaentry>
</qandaset>
@@ -6542,38 +6537,34 @@ ATDT1234567</programlisting>
<answer>
<para>As the &os; kernel boots, it will probe for the serial
- ports in your system for which the kernel was configured.
- You can either watch your system closely for the messages
- it prints or run this command after your system is up and
+ ports for which the kernel is configured.
+ Either watch the boot messages closely
+ or run this command after the system is up and
running:</para>
- <screen>&prompt.user; <userinput>dmesg | grep -E "^sio[0-9]"</userinput></screen>
-
- <para>Here is some example output from the above
- command:</para>
-
- <programlisting>sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
+ <screen>&prompt.user; <userinput>dmesg | grep -E "^sio[0-9]"</userinput>
+sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
-sio1: type 16550A</programlisting>
+sio1: type 16550A</screen>
- <para>This shows two serial ports. The first is on
- IRQ 4, is using port address
+ <para>This example shows two serial ports. The first is on
+ IRQ4, port address
<literal>0x3f8</literal>, and has a 16550A-type UART chip.
The second uses the same kind of chip but is on
- IRQ 3 and is at port address
+ IRQ3 and is at port address
<literal>0x2f8</literal>. Internal modem cards are
- treated just like serial ports — except that they
- always have a modem <quote>attached</quote> to the
+ treated just like serial ports, except that they
+ always have a modem attached to the
port.</para>
<para>The <filename>GENERIC</filename> kernel includes
support for two serial ports using the same IRQ and port
address settings in the above example. If these settings
- are not right for your system, or if you have added modem
- cards or have more serial ports than your kernel is
- configured for, just reconfigure your kernel. See section
- <link linkend="make-kernel">about building a kernel</link>
+ are not right for the system, or if there are more modem
+ cards or serial ports than the kernel is
+ configured for, reconfigure using the instructions in
+ <link linkend="make-kernel">building a kernel</link>
for more details.</para>
</answer>
</qandaentry>
@@ -6584,28 +6575,28 @@ sio1: type 16550A</programlisting>
</question>
<answer>
- <para>The third serial port, <filename>sio2</filename> (see
- &man.sio.4;, known as <filename>COM3</filename> in DOS),
+ <para>The third serial port, <filename>sio2</filename>,
+ or <filename>COM3</filename>,
is on <filename>/dev/cuad2</filename> for dial-out
devices, and on <filename>/dev/ttyd2</filename> for
dial-in devices. What is the difference between these two
classes of devices?</para>
- <para>You use <filename>ttydX</filename> for dial-ins. When
+ <para>When
opening <filename>/dev/ttydX</filename> in blocking mode,
a process will wait for the corresponding
<filename>cuadX</filename>
device to become inactive, and then wait for the carrier
- detect line to go active. When you open the
- <filename>cuadX</filename> device, it makes sure the
+ detect line to go active. When the
+ <filename>cuadX</filename> device is opened, it makes sure the
serial port is not already in use by the
<filename>ttydX</filename>
device. If the port is available, it
- <quote>steals</quote> it from the
+ steals it from the
<filename>ttydX</filename> device. Also, the
<filename>cuadX</filename> device does not care about
carrier detect. With this scheme and an auto-answer
- modem, you can have remote users log in and you can still
+ modem, remote users can log in and local users can still
dial out with the same modem and the system will take care
of all the conflicts.</para>
</answer>
@@ -6613,14 +6604,14 @@ sio1: type 16550A</programlisting>
<qandaentry>
<question xml:id="enable-multiport-serial">
- <para>How do I enable support for a multiport serial
+ <para>How do I enable support for a multi-port serial
card?</para>
</question>
<answer>
- <para>Again, the section on kernel configuration provides
- information about configuring your kernel. For a
- multiport serial card, place an &man.sio.4; line for each
+ <para>The section on kernel configuration provides
+ information about configuring the kernel. For a
+ multi-port serial card, place an &man.sio.4; line for each
serial port on the card in the &man.device.hints.5; file.
But place the IRQ specifiers on only one of the entries.
All of the ports on the card should share one IRQ. For
@@ -6688,7 +6679,7 @@ hint.sio.7.irq="12"</programlisting>
</question>
<answer>
- <para>You can find this information in the <link
+ <para>This information is in the <link
xlink:href="&url.books.handbook;/term.html">Terminals</link>
section of the &os; Handbook.</para>
</answer>
@@ -6701,18 +6692,18 @@ hint.sio.7.irq="12"</programlisting>
</question>
<answer>
- <para>On your system, the programs &man.tip.1; and
- &man.cu.1; can only access the
+ <para>The built-in &man.tip.1; and
+ &man.cu.1; utilities can only access the
<filename>/var/spool/lock</filename> directory via user
<systemitem class="username">uucp</systemitem> and group
- <systemitem class="groupname">dialer</systemitem>. You
- can use the group <systemitem
- class="groupname">dialer</systemitem> to control who has
- access to your modem or remote systems. Just add yourself
- to group <systemitem
+ <systemitem class="groupname">dialer</systemitem>.
+ Use the <systemitem
+ class="groupname">dialer</systemitem> group to control who has
+ access to the modem or remote systems by adding user accounts
+ to <systemitem
class="groupname">dialer</systemitem>.</para>
- <para>Alternatively, you can let everyone on your system run
+ <para>Alternatively, everyone can be configured to run
&man.tip.1; and &man.cu.1; by typing:</para>
<screen>&prompt.root; <userinput>chmod 4511 /usr/bin/cu</userinput>
@@ -6741,8 +6732,8 @@ hint.sio.7.irq="12"</programlisting>
<para>Note that while &os; is proactive in this regard, it
does not arbitrarily decide to swap pages when the system
- is truly idle. Thus you will not find your system all
- paged out when you get up in the morning after leaving it
+ is truly idle. Thus, the system will not be all
+ paged out after leaving it
idle overnight.</para>
</answer>
</qandaentry>
@@ -6755,7 +6746,7 @@ hint.sio.7.irq="12"</programlisting>
<answer>
<para>The simple answer is that free memory is wasted
- memory. Any memory that your programs do not actively
+ memory. Any memory that programs do not actively
allocate is used within the &os; kernel as disk cache.
The values shown by &man.top.1; labeled as
<literal>Inact</literal>, <literal>Cache</literal>, and
@@ -6778,9 +6769,9 @@ hint.sio.7.irq="12"</programlisting>
<answer>
<para>Symlinks do not have permissions, and by default,
&man.chmod.1; will follow symlinks to change the
- permissions on the source file, if possible. So if you
- have a file, <filename>foo</filename>, and a symlink to
- that file, <filename>bar</filename>, then this command
+ permissions on the source file, if possible. For
+ the file, <filename>foo</filename> with a symlink named
+ <filename>bar</filename>, this command
will always succeed.</para>
<screen>&prompt.user; <userinput>chmod g-w bar</userinput></screen>
@@ -6789,7 +6780,7 @@ hint.sio.7.irq="12"</programlisting>
will not have changed.</para>
<para>When changing modes of the file hierarchies rooted in
- the files instead of the files themselves, you have to use
+ the files instead of the files themselves, use
either <option>-H</option> or <option>-L</option> together
with <option>-R</option> to make this work. See
&man.chmod.1; and &man.symlink.7; for more
@@ -6799,14 +6790,14 @@ hint.sio.7.irq="12"</programlisting>
<para><option>-R</option> does a
<emphasis>recursive</emphasis> &man.chmod.1;. Be
careful about specifying directories or symlinks to
- directories to &man.chmod.1;. If you want to change the
+ directories to &man.chmod.1;. To change the
permissions of a directory referenced by a symlink, use
&man.chmod.1; without any options and follow the symlink
with a trailing slash (<filename>/</filename>). For
example, if <filename>foo</filename> is a symlink to
- directory <filename>bar</filename>, and you want to
+ directory <filename>bar</filename>, to
change the permissions of <filename>foo</filename>
- (actually <filename>bar</filename>), you would do
+ (actually <filename>bar</filename>), do
something like:</para>
<screen>&prompt.user; <userinput>chmod 555 foo/</userinput></screen>
@@ -6825,18 +6816,18 @@ hint.sio.7.irq="12"</programlisting>
</question>
<answer>
- <para>Yes, you can use <package>emulators/doscmd</package>,
- a DOS emulation program, available in the &os; Ports
+ <para>Yes. A DOS emulation program, <package>emulators/doscmd</package>,
+ is available in the &os; Ports
Collection.</para>
<para>If <application>doscmd</application> will not suffice,
- the add-on utility <package>emulators/pcemu</package>
+ <package>emulators/pcemu</package>
emulates an 8088 and enough BIOS services to run many DOS
- text mode applications. It requires the X Window
+ text-mode applications. It requires the X Window
System.</para>
- <para>You may also try <package>emulators/dosbox</package>
- from the &os; Ports Collection. The main focus of this
+ <para>The Ports Collection also has <package>emulators/dosbox</package>.
+ The main focus of this
application is emulating old DOS games using the local
file system for files.</para>
</answer>
@@ -6886,7 +6877,7 @@ hint.sio.7.irq="12"</programlisting>
</listitem>
</itemizedlist>
- <para>Other advice to help your mail reach its destination
+ <para>Other advice to help mail reach its destination
include:</para>
<itemizedlist>
@@ -6904,7 +6895,7 @@ hint.sio.7.irq="12"</programlisting>
</itemizedlist>
<para>If you still have trouble with email infrastructure at
- <systemitem class="fqdomainname">FreeBSD.org</systemitem>
+ <systemitem class="fqdomainname">FreeBSD.org</systemitem>,
send a note with the details to
<email>postmaster at freebsd.org</email>; Include a
date/time interval so that logs may be reviewed —
@@ -6953,7 +6944,7 @@ hint.sio.7.irq="12"</programlisting>
<quote>beastie</quote> is pronounced
<quote>BSD</quote>.</para>
- <para>You can learn more about the BSD daemon on his <link
+ <para>More about the BSD daemon is available on his <link
xlink:href="http://www.mckusick.com/beastie/index.html">home
page</link>.</para>
</answer>
@@ -6966,15 +6957,15 @@ hint.sio.7.irq="12"</programlisting>
<answer>
<para>Perhaps. The BSD daemon is copyrighted by Marshall
- Kirk McKusick. You will want to check his <link
+ Kirk McKusick. Check his <link
xlink:href="http://www.mckusick.com/beastie/mainpage/copyright.html">Statement
on the Use of the BSD Daemon Figure</link> for detailed
usage terms.</para>
- <para>In summary, you are free to use the image in a
+ <para>In summary, the image can be used in a
tasteful manner, for personal use, so long as appropriate
- credit is given. If you want to use him commercially, you
- must contact &a.mckusick.email;. More details are
+ credit is given. Before using the logo commercially,
+ contact &a.mckusick.email; for permission. More details are
available on the <link
xlink:href="http://www.mckusick.com/beastie/index.html">BSD
Daemon's home page</link>.</para>
@@ -6987,7 +6978,7 @@ hint.sio.7.irq="12"</programlisting>
</question>
<answer>
- <para>You will find eps and Xfig drawings under
+ <para>Xfig and eps drawings are available under
<filename>/usr/share/examples/BSD_daemon/</filename>.</para>
</answer>
</qandaentry>
@@ -7005,7 +6996,9 @@ hint.sio.7.irq="12"</programlisting>
Glossary</link>.</para>
</answer>
</qandaentry>
-
+ </qandaset>
+ </chapter>
+<!---
<qandaentry>
<question xml:id="bikeshed-painting">
<para>Why should I care what color the bikeshed is?</para>
@@ -7087,7 +7080,7 @@ hint.sio.7.irq="12"</programlisting>
</qandaentry>
</qandaset>
</chapter>
-<!---
+
<chapter xml:id="funnies">
<title>The &os; Funnies</title>
@@ -7445,7 +7438,7 @@ hint.sio.7.irq="12"</programlisting>
</question>
<answer>
- <para>Yes, you can do this <emphasis>without</emphasis>
+ <para>Yes, this can be done <emphasis>without</emphasis>
downloading the whole source tree by using the <link
xlink:href="&url.books.handbook;/synching.html#ctm">CTM
facility</link>.</para>
@@ -7490,19 +7483,18 @@ interrupt mask =
trap number = 12
panic: page fault</programlisting>
- <para>When you see a message like this, it is not enough to
- just reproduce it and send it in. The instruction pointer
- value is important; unfortunately, it is also
- configuration dependent. In other words, the value varies
- depending on the exact kernel image that you are using.
- If you are using a <filename>GENERIC</filename> kernel
- image from one of the snapshots, then it is possible for
- somebody else to track down the offending function, but if
- you are running a custom kernel then only
- <emphasis>you</emphasis> can tell us where the fault
+ <para>This message is not enough. While the instruction pointer
+ value is important, it is also
+ configuration dependent as it varies
+ depending on the kernel image.
+ If it is a <filename>GENERIC</filename> kernel
+ image from one of the snapshots, it is possible for
+ somebody else to track down the offending function, but for
+ a custom kernel, only
+ you can tell us where the fault
occurred.</para>
- <para>What you should do is this:</para>
+ <para>To proceed:</para>
<procedure>
<step>
@@ -7530,7 +7522,7 @@ panic: page fault</programlisting>
<screen>&prompt.user; <userinput>nm -n kernel.that.caused.the.panic | grep f0xxxxx</userinput></screen>
<para>If that does not yield any results, chop off
- another digit. Repeat until you get some sort of
+ another digit. Repeat until there is some sort of
output. The result will be a possible list of
functions which caused the panic. This is a less than
exact mechanism for tracking down the point of
@@ -7548,8 +7540,7 @@ panic: page fault</programlisting>
<procedure>
<step>
<para>Make sure that the following line is included in
- your kernel configuration file
- (<filename>/usr/src/sys/arch/conf/MYKERNEL</filename>):</para>
+ the kernel configuration file:</para>
<programlisting>makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols</programlisting>
</step>
@@ -7564,7 +7555,7 @@ panic: page fault</programlisting>
<step>
<para>Compile the kernel:</para>
- <screen>&prompt.root; <userinput>make buildkernel KERNCONF=MYKERNEL</userinput></screen>
+ <screen>&prompt.root; <userinput>make buildkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput></screen>
</step>
<step>
@@ -7581,8 +7572,8 @@ panic: page fault</programlisting>
</procedure>
<note>
- <para>If you do not use the <varname>KERNCONF</varname>
- make variable a <filename>GENERIC</filename> kernel will
+ <para>If <varname>KERNCONF</varname> is not included,
+ the <filename>GENERIC</filename> kernel will instead
be built and installed.</para>
</note>
@@ -7595,12 +7586,12 @@ panic: page fault</programlisting>
<filename>kernel.debug</filename> can be used as the
source of debugging symbols for &man.kgdb.1;.</para>
- <para>To make sure you capture a crash dump, you need edit
+ <para>To capture a crash dump, edit
<filename>/etc/rc.conf</filename> and set
- <literal>dumpdev</literal> to point to your swap partition
- (or <literal>AUTO</literal>). This will cause the
+ <literal>dumpdev</literal> to point to either the swap partition
+ or <literal>AUTO</literal>. 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;
+ enable crash dumps. This command can also be run
manually. After a panic, the crash dump can be recovered
using &man.savecore.8;; if <literal>dumpdev</literal> is
set in <filename>/etc/rc.conf</filename>, the &man.rc.8;
@@ -7608,54 +7599,50 @@ panic: page fault</programlisting>
the crash dump in <filename>/var/crash</filename>.</para>
<note>
- <para>&os; crash dumps are usually the same size as the
- physical RAM size of your machine. That is, if you have
- 512 MB of RAM, you will get a 512 MB crash
- dump. Therefore you must make sure there is enough
+ <para>&os; crash dumps are usually the same size as
+ physical RAM. Therefore, make sure there is enough
space in <filename>/var/crash</filename> to hold the
- dump. Alternatively, you run &man.savecore.8; manually
+ dump. Alternatively, run &man.savecore.8; manually
and have it recover the crash dump to another directory
- where you have more room. It is possible to limit the
+ with more room. It is possible to limit the
size of the crash dump by using <literal>options
MAXMEM=N</literal> where
<replaceable>N</replaceable> is the size of kernel's
- memory usage in KBs. For example, if you have 1 GB
- of RAM, you can limit the kernel's memory usage to
- 128 MB by this way, so that your crash dump size
+ memory usage in KBs. For example, for 1 GB
+ of RAM, limit the kernel's memory usage to
+ 128 MB, so that the crash dump size
will be 128 MB instead of 1 GB.</para>
</note>
- <para>Once you have recovered the crash dump, you can get a
- stack trace with &man.kgdb.1; as follows:</para>
+ <para>Once the crash dump has been recovered , get a
+ stack trace as follows:</para>
<screen>&prompt.user; <userinput>kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0</userinput>
<prompt>(kgdb)</prompt> <userinput>backtrace</userinput></screen>
<para>Note that there may be several screens worth of
- information; ideally you should use &man.script.1; to
+ information. Ideally, use &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 occurred. Usually you
- have to read the stack trace from the bottom up to trace
- the exact sequence of events that lead to the crash. You
- can also use &man.kgdb.1; to print out the contents of
+ kernel source code where the panic occurred.
+ The stack trace is usually read from the bottom up to trace
+ the exact sequence of events that lead to the crash.
+ &man.kgdb.1; can also be used to print out the contents of
various variables or structures to examine the system
state at the time of the crash.</para>
<tip>
- <para>Now, if you are really insane and have a second
- computer, you can also configure &man.kgdb.1; to do
- remote debugging such that you can use &man.kgdb.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.</para>
+ <para>If a second
+ computer is available, &man.kgdb.1; can be configured to do
+ remote debugging,
+ including setting breakpoints and single-stepping through
+ the kernel code.</para>
</tip>
<note>
- <para>If you have <literal>DDB</literal> enabled and the
- kernel drops into the debugger, you can force a panic
- (and a crash dump) just by typing
+ <para>If <literal>DDB</literal> is enabled and the
+ kernel drops into the debugger, a panic
+ and a crash dump can be forced by typing
<literal>panic</literal> at the <literal>ddb</literal>
prompt. It may stop in the debugger again during the
panic phase. If it does, type
@@ -7679,9 +7666,9 @@ panic: page fault</programlisting>
<function>dlopen(NULL, flags)</function> will fail to find
such symbols.</para>
- <para>If you want to search, using
+ <para>To search, using
<function>dlsym()</function>, for symbols present in the
- main executable of a process, you need to link the
+ main executable of a process, link the
executable using the <option>--export-dynamic</option>
option to the ELF linker (&man.ld.1;).</para>
</answer>
@@ -7695,13 +7682,13 @@ panic: page fault</programlisting>
<answer>
<para>By default, the kernel address space is 1 GB
- (2 GB for PAE) for i386. If you run a
- network-intensive server (e.g., a FTP or HTTP server),
- or you want to use ZFS, you might find that is not
+ (2 GB for PAE) for i386. When running a
+ network-intensive server or using
+ ZFS, this will probably not be
enough.</para>
- <para>Add the following line to your kernel configuration
- file to increase available space and rebuild your
+ <para>Add the following line to the kernel configuration
+ file to increase available space and rebuild the
kernel:</para>
<programlisting>options KVA_PAGES=<replaceable>N</replaceable></programlisting>
More information about the svn-doc-all
mailing list