Date: Thu, 15 May 2014 00:14:10 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44838 - head/en_US.ISO8859-1/books/faq Message-ID: <201405150014.s4F0EAml041000@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405150014.s4F0EAml041000>