Date: Mon, 14 Apr 2014 20:52:06 +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: r44557 - head/en_US.ISO8859-1/books/handbook/config Message-ID: <201404142052.s3EKq6jY033684@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Mon Apr 14 20:52:06 2014 New Revision: 44557 URL: http://svnweb.freebsd.org/changeset/doc/44557 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/config/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/config/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/config/chapter.xml Mon Apr 14 19:48:31 2014 (r44556) +++ head/en_US.ISO8859-1/books/handbook/config/chapter.xml Mon Apr 14 20:52:06 2014 (r44557) @@ -698,13 +698,13 @@ dc1: [ITHREAD]</screen> <para>Alternatively, statically compile support for the <acronym>NIC</acronym> into a custom kernel. Refer to <filename>/usr/src/sys/conf/NOTES</filename>, - <filename>/usr/src/sys/<replaceable>arch</replaceable>/conf/NOTES</filename> and the - manual page of the driver to determine which line to add - to the custom kernel configuration file. For more - information about recompiling the kernel, refer to - <xref linkend="kernelconfig"/>. If the - <acronym>NIC</acronym> was detected at boot, the kernel - does not need to be recompiled.</para> + <filename>/usr/src/sys/<replaceable>arch</replaceable>/conf/NOTES</filename> + and the manual page of the driver to determine which line + to add to the custom kernel configuration file. For more + information about recompiling the kernel, refer to <xref + linkend="kernelconfig"/>. If the <acronym>NIC</acronym> + was detected at boot, the kernel does not need to be + recompiled.</para> </listitem> </itemizedlist> @@ -1512,10 +1512,10 @@ cron.* <systemitem>A</systemitem>, named <systemitem class="fqdomainname">logserv.example.com</systemitem>, will collect logging information for the local network. Host - <systemitem>B</systemitem>, named <systemitem - class="fqdomainname">logclient.example.com</systemitem>, will - be configured to pass logging information to the logging - server.</para> + <systemitem>B</systemitem>, named <systemitem + class="fqdomainname">logclient.example.com</systemitem>, + will be configured to pass logging information to the logging + server.</para> <sect3> <title>Log Server Configuration</title> @@ -2856,75 +2856,72 @@ kern.maxvnodes: 100000</screen> <acronym>APM</acronym> Software Interface, which allows management of power levels.</para> - <para>There are four major problems in <acronym>APM</acronym>. - First, power management is done by the vendor-specific - <acronym>BIOS</acronym>, separate from the operating system. - For example, the user can set idle-time values for a hard - drive in the <acronym>APM</acronym> <acronym>BIOS</acronym> - so that, when exceeded, the <acronym>BIOS</acronym> spins - down the hard drive without the consent of the operating - system. Second, the <acronym>APM</acronym> logic is embedded - in the <acronym>BIOS</acronym>, and it operates outside the - scope of the operating system. This means that users can - only fix problems in the <acronym>APM</acronym> - <acronym>BIOS</acronym> by flashing a new one into the - <acronym>ROM</acronym>, which is a dangerous procedure with - the potential to leave the system in an unrecoverable state - if it fails. Third, <acronym>APM</acronym> is a - vendor-specific technology, meaning that there is a lot of - duplication of efforts and bugs found in one vendor's - <acronym>BIOS</acronym> may not be solved in others. Lastly, - the <acronym>APM</acronym> <acronym>BIOS</acronym> did not - have enough room to implement a sophisticated power policy - or one that can adapt well to the purpose of the - machine.</para> - - <para>The Plug and Play <acronym>BIOS</acronym> - (<acronym>PNPBIOS</acronym>) was unreliable in - many situations. <acronym>PNPBIOS</acronym> is 16-bit - technology, so the operating system has to use 16-bit - emulation in order to interface with - <acronym>PNPBIOS</acronym> methods. &os; provides an - <acronym>APM</acronym> driver as <acronym>APM</acronym> should - still be used for systems manufactured at or before the year - 2000. The driver is documented in &man.apm.4;.</para> + <para>There are four major problems in <acronym>APM</acronym>. + First, power management is done by the vendor-specific + <acronym>BIOS</acronym>, separate from the operating system. + For example, the user can set idle-time values for a hard drive + in the <acronym>APM</acronym> <acronym>BIOS</acronym> so that, + when exceeded, the <acronym>BIOS</acronym> spins down the hard + drive without the consent of the operating system. Second, the + <acronym>APM</acronym> logic is embedded in the + <acronym>BIOS</acronym>, and it operates outside the scope of + the operating system. This means that users can only fix + problems in the <acronym>APM</acronym> + <acronym>BIOS</acronym> by flashing a new one into the + <acronym>ROM</acronym>, which is a dangerous procedure with the + potential to leave the system in an unrecoverable state if it + fails. Third, <acronym>APM</acronym> is a vendor-specific + technology, meaning that there is a lot of duplication of + efforts and bugs found in one vendor's <acronym>BIOS</acronym> + may not be solved in others. Lastly, the <acronym>APM</acronym> + <acronym>BIOS</acronym> did not have enough room to implement a + sophisticated power policy or one that can adapt well to the + purpose of the machine.</para> + + <para>The Plug and Play <acronym>BIOS</acronym> + (<acronym>PNPBIOS</acronym>) was unreliable in many situations. + <acronym>PNPBIOS</acronym> is 16-bit technology, so the + operating system has to use 16-bit emulation in order to + interface with <acronym>PNPBIOS</acronym> methods. &os; + provides an <acronym>APM</acronym> driver as + <acronym>APM</acronym> should still be used for systems + manufactured at or before the year 2000. The driver is + documented in &man.apm.4;.</para> - <indexterm> - <primary>ACPI</primary> - </indexterm> + <indexterm> + <primary>ACPI</primary> + </indexterm> - <indexterm> - <primary>APM</primary> - </indexterm> + <indexterm> + <primary>APM</primary> + </indexterm> <para>The successor to <acronym>APM</acronym> is the Advanced Configuration and Power Interface (<acronym>ACPI</acronym>). - <acronym>ACPI</acronym> is a standard written by an - alliance of vendors to provide an interface for - hardware resources and power management. It is a key - element in <emphasis>Operating System-directed configuration - and Power Management</emphasis> as it provides more control - and flexibility to the operating system.</para> - - <para>This chapter demonstrates how to configure - <acronym>ACPI</acronym> on &os;. It then offers some tips on - how to debug <acronym>ACPI</acronym> and how to submit a - problem report containing debugging information so that - developers can diagnosis and fix <acronym>ACPI</acronym> - issues.</para> + <acronym>ACPI</acronym> is a standard written by an alliance of + vendors to provide an interface for hardware resources and power + management. It is a key element in <emphasis>Operating + System-directed configuration and Power Management</emphasis> + as it provides more control and flexibility to the operating + system.</para> + + <para>This chapter demonstrates how to configure + <acronym>ACPI</acronym> on &os;. It then offers some tips on + how to debug <acronym>ACPI</acronym> and how to submit a problem + report containing debugging information so that developers can + diagnosis and fix <acronym>ACPI</acronym> issues.</para> <sect2 xml:id="acpi-config"> <title>Configuring <acronym>ACPI</acronym></title> - <para>In &os; the &man.acpi.4; driver is loaded by default at system - boot and should - <emphasis>not</emphasis> be compiled into the kernel. This - driver can not be unloaded after boot because the system - bus uses it for various hardware interactions. - However, if the system is experiencing problems, - <acronym>ACPI</acronym> can be disabled altogether - by rebooting after - setting <literal>hint.acpi.0.disabled="1"</literal> in + <para>In &os; the &man.acpi.4; driver is loaded by default at + system boot and should <emphasis>not</emphasis> be compiled + into the kernel. This driver can not be unloaded after boot + because the system bus uses it for various hardware + interactions. However, if the system is experiencing + problems, <acronym>ACPI</acronym> can be disabled altogether + by rebooting after setting + <literal>hint.acpi.0.disabled="1"</literal> in <filename>/boot/loader.conf</filename> or by setting this variable at the loader prompt, as described in <xref linkend="boot-loader"/>.</para> @@ -2937,34 +2934,38 @@ kern.maxvnodes: 100000</screen> </note> <para><acronym>ACPI</acronym> can be used to put the system into - a sleep mode with <command>acpiconf</command>, the <option>-s</option> - flag, and a number from <literal>1</literal> to <literal>5</literal>. Most users - only need <literal>1</literal> (quick suspend to + a sleep mode with <command>acpiconf</command>, the + <option>-s</option> flag, and a number from + <literal>1</literal> to <literal>5</literal>. Most users only + need <literal>1</literal> (quick suspend to <acronym>RAM</acronym>) or <literal>3</literal> (suspend to <acronym>RAM</acronym>). Option <literal>5</literal> performs - a soft-off which is the same as running <command>halt -p</command>.</para> + a soft-off which is the same as running + <command>halt -p</command>.</para> - <para>Other options are available using <command>sysctl</command>. Refer to - &man.acpi.4; and &man.acpiconf.8; for more information.</para> + <para>Other options are available using + <command>sysctl</command>. Refer to &man.acpi.4; and + &man.acpiconf.8; for more information.</para> </sect2> <sect2 xml:id="ACPI-comprob"> <title>Common Problems</title> + <indexterm> <primary><acronym>ACPI</acronym></primary> </indexterm> <para><acronym>ACPI</acronym> is present in all modern computers that conform to the ia32 (x86), ia64 (Itanium), and amd64 - (<acronym>AMD</acronym>) architectures. The full standard has many features - including <acronym>CPU</acronym> performance management, power - planes control, thermal zones, various battery systems, - embedded controllers, and bus enumeration. Most systems - implement less than the full standard. For instance, a - desktop system usually only implements bus enumeration - while a laptop might have cooling and battery management - support as well. Laptops also have suspend and resume, with - their own associated complexity.</para> + (<acronym>AMD</acronym>) architectures. The full standard has + many features including <acronym>CPU</acronym> performance + management, power planes control, thermal zones, various + battery systems, embedded controllers, and bus enumeration. + Most systems implement less than the full standard. For + instance, a desktop system usually only implements bus + enumeration while a laptop might have cooling and battery + management support as well. Laptops also have suspend and + resume, with their own associated complexity.</para> <para>An <acronym>ACPI</acronym>-compliant system has various components. The <acronym>BIOS</acronym> and chipset vendors @@ -2972,9 +2973,9 @@ kern.maxvnodes: 100000</screen> in memory that specify things like the <acronym>APIC</acronym> map (used for <acronym>SMP</acronym>), config registers, and simple configuration values. Additionally, a bytecode table, - the Differentiated System Description - Table <acronym>DSDT</acronym>, specifies a - tree-like name space of devices and methods.</para> + the Differentiated System Description Table + <acronym>DSDT</acronym>, specifies a tree-like name space of + devices and methods.</para> <para>The <acronym>ACPI</acronym> driver must parse the fixed tables, implement an interpreter for the bytecode, and modify @@ -3017,25 +3018,24 @@ kern.maxvnodes: 100000</screen> <acronym>RAM</acronym> (<acronym>STR</acronym>) states, <literal>S1</literal>-<literal>S3</literal>, and one suspend to disk state (<acronym>STD</acronym>), called - <literal>S4</literal>. <acronym>STD</acronym> can be implemented in two separate - ways. The <literal>S4</literal><acronym>BIOS</acronym> is a + <literal>S4</literal>. <acronym>STD</acronym> can be + implemented in two separate ways. The + <literal>S4</literal><acronym>BIOS</acronym> is a <acronym>BIOS</acronym>-assisted suspend to disk and <literal>S4</literal><acronym>OS</acronym> is implemented - entirely by the operating system. The normal state the system - is in when plugged in but not powered up is - <quote>soft off</quote> (<literal>S5</literal>). - </para> + entirely by the operating system. The normal state the + system is in when plugged in but not powered up is + <quote>soft off</quote> (<literal>S5</literal>).</para> - <para>Use <command>sysctl hw.acpi</command> to check - for the suspend-related items. These example results are from a + <para>Use <command>sysctl hw.acpi</command> to check for the + suspend-related items. These example results are from a Thinkpad:</para> <screen>hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0</screen> <para>Use <command>acpiconf -s</command> to test - <literal>S3</literal>, - <literal>S4</literal>, and + <literal>S3</literal>, <literal>S4</literal>, and <literal>S5</literal>. An <option>s4bios</option> of one (<literal>1</literal>) indicates <literal>S4</literal><acronym>BIOS</acronym> support instead @@ -3074,20 +3074,19 @@ hw.acpi.s4bios: 0</screen> console, a Firewire port and cable for using &man.dcons.4;, and kernel debugging skills.</para> - <para>To help isolate the problem, unload as many drivers - as possible. If it works, narrow down which - driver is the problem by loading drivers until it fails - again. Typically, binary drivers like - <filename>nvidia.ko</filename>, display drivers, and - <acronym>USB</acronym> will have the most problems while - Ethernet interfaces usually work fine. If drivers can be - properly loaded and unloaded, automate this by putting the - appropriate commands in + <para>To help isolate the problem, unload as many drivers as + possible. If it works, narrow down which driver is the + problem by loading drivers until it fails again. Typically, + binary drivers like <filename>nvidia.ko</filename>, display + drivers, and <acronym>USB</acronym> will have the most + problems while Ethernet interfaces usually work fine. If + drivers can be properly loaded and unloaded, automate this + by putting the appropriate commands in <filename>/etc/rc.suspend</filename> and - <filename>/etc/rc.resume</filename>. - Try setting <option>hw.acpi.reset_video</option> to - <literal>0</literal> if the display is messed up after - resume. Try setting longer or shorter values for + <filename>/etc/rc.resume</filename>. Try setting + <option>hw.acpi.reset_video</option> to <literal>0</literal> + if the display is messed up after resume. Try setting + longer or shorter values for <option>hw.acpi.sleep_delay</option> to see if that helps.</para> @@ -3120,9 +3119,8 @@ hw.acpi.s4bios: 0</screen> interrupt storm. Chipsets may have problems based on boot, how the <acronym>BIOS</acronym> configures interrupts before correctness of the <acronym>APIC</acronym> - (<acronym>MADT</acronym>) table, and routing of the - System Control Interrupt - (<acronym>SCI</acronym>).</para> + (<acronym>MADT</acronym>) table, and routing of the System + Control Interrupt (<acronym>SCI</acronym>).</para> <indexterm> <primary>interrupt storms</primary> @@ -3163,8 +3161,8 @@ hw.acpi.s4bios: 0</screen> console in <xref linkend="serialconsole-ddb"/> or setting up a dump partition. To get a backtrace in <acronym>DDB</acronym>, use <literal>tr</literal>. When - handwriting the backtrace, get at least the last five - and the top five lines in the trace.</para> + handwriting the backtrace, get at least the last five and + the top five lines in the trace.</para> <para>Then, try to isolate the problem by booting with <acronym>ACPI</acronym> disabled. If that works, isolate @@ -3178,12 +3176,12 @@ hw.acpi.s4bios: 0</screen> <para>First, try setting <literal>hw.acpi.disable_on_poweroff="0"</literal> in - <filename>/boot/loader</filename>. This keeps <acronym>ACPI</acronym> - from disabling various events during the shutdown process. - Some systems need this value set to <literal>1</literal> - (the default) for the same reason. This usually fixes the - problem of a system powering up spontaneously after a - suspend or poweroff.</para> + <filename>/boot/loader</filename>. This keeps + <acronym>ACPI</acronym> from disabling various events during + the shutdown process. Some systems need this value set to + <literal>1</literal> (the default) for the same reason. + This usually fixes the problem of a system powering up + spontaneously after a suspend or poweroff.</para> </sect3> </sect2> @@ -3196,9 +3194,9 @@ hw.acpi.s4bios: 0</screen> <secondary><acronym>ASL</acronym></secondary> </indexterm> - <para>Some <acronym>BIOS</acronym> vendors provide incorrect - or buggy bytecode. This is usually manifested by kernel - console messages like this:</para> + <para>Some <acronym>BIOS</acronym> vendors provide incorrect or + buggy bytecode. This is usually manifested by kernel console + messages like this:</para> <screen>ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND</screen> @@ -3206,18 +3204,16 @@ hw.acpi.s4bios: 0</screen> <para>Often, these problems may be resolved by updating the <acronym>BIOS</acronym> to the latest revision. Most console messages are harmless, but if there are other problems like - the battery status is not working, these messages are a - good place to start looking for problems. The bytecode, - known as <acronym>AML</acronym>, is compiled from a source - language called <acronym>ASL</acronym>. The - <acronym>AML</acronym> is found in the table known as the - <acronym>DSDT</acronym>. To get a copy of the system's - <acronym>ASL</acronym>, use &man.acpidump.8;. Include both - <option>-t</option>, to show the contents of the fixed tables, - and <option>-d</option>, to disassemble the - <acronym>AML</acronym>. Refer to - <xref linkend="ACPI-submitdebug"/> for an example - syntax.</para> + the battery status is not working, these messages are a good + place to start looking for problems. The bytecode, known as + <acronym>AML</acronym>, is compiled from a source language + called <acronym>ASL</acronym>. The <acronym>AML</acronym> is + found in the table known as the <acronym>DSDT</acronym>. To + get a copy of the system's <acronym>ASL</acronym>, use + &man.acpidump.8;. Include both <option>-t</option>, to show + the contents of the fixed tables, and <option>-d</option>, to + disassemble the <acronym>AML</acronym>. Refer to <xref + linkend="ACPI-submitdebug"/> for an example syntax.</para> <para>The simplest first check is to recompile the <acronym>ASL</acronym> to check for errors. Warnings can @@ -3296,9 +3292,9 @@ hw.acpi.s4bios: 0</screen> <screen>&prompt.root; <userinput>iasl your.asl</userinput></screen> - <para>Adding the <option>-f</option> flag forces creation - of the <acronym>AML</acronym>, even if there are errors - during compilation. Some errors, such as missing return + <para>Adding the <option>-f</option> flag forces creation of + the <acronym>AML</acronym>, even if there are errors during + compilation. Some errors, such as missing return statements, are automatically worked around by the interpreter.</para> @@ -3342,8 +3338,8 @@ acpi_dsdt_name="/boot/DSDT.aml"</program (everything). The <quote>level</quote> is a bitmask so multiple options can be set at once, separated by spaces. In practice, a serial console should be used to log the output - so it is not lost as the console message buffer flushes. - A full list of the individual layers and levels is found in + so it is not lost as the console message buffer flushes. A + full list of the individual layers and levels is found in &man.acpi.4;.</para> <para>Debugging output is not enabled by default. To enable it, @@ -3420,8 +3416,8 @@ debug.acpi.level="ACPI_LV_ERROR"</progra </itemizedlist> </sect2> - <sect2 xml:id="ACPI-submitdebug"> - <info> + <sect2 xml:id="ACPI-submitdebug"> + <info> <title>Debugging &os; <acronym>ACPI</acronym></title> <authorgroup> @@ -3452,26 +3448,26 @@ debug.acpi.level="ACPI_LV_ERROR"</progra </authorgroup> </info> - <indexterm> - <primary>ACPI</primary> - <secondary>problems</secondary> - </indexterm> + <indexterm> + <primary>ACPI</primary> + <secondary>problems</secondary> + </indexterm> - <para><acronym>ACPI</acronym> provides a method for - discovering devices, managing power usage, and providing - standardized access to various hardware previously managed by - the <acronym>BIOS</acronym>. Progress is being made toward - <acronym>ACPI</acronym> working on all systems, but bugs in some - motherboards' <acronym>ACPI</acronym> Machine - Language (<acronym>AML</acronym>) bytecode, - incompleteness in &os;'s kernel subsystems, and bugs in the - &intel; <acronym>ACPI-CA</acronym> interpreter continue to - appear.</para> - - <para>This section is intended to help users assist the &os; - <acronym>ACPI</acronym> maintainers in identifying the root - cause of problems and in debugging and developing a - solution.</para> + <para><acronym>ACPI</acronym> provides a method for + discovering devices, managing power usage, and providing + standardized access to various hardware previously managed by + the <acronym>BIOS</acronym>. Progress is being made toward + <acronym>ACPI</acronym> working on all systems, but bugs in + some motherboards' <acronym>ACPI</acronym> Machine Language + (<acronym>AML</acronym>) bytecode, incompleteness in &os;'s + kernel subsystems, and bugs in the &intel; + <acronym>ACPI-CA</acronym> interpreter continue to + appear.</para> + + <para>This section is intended to help users assist the &os; + <acronym>ACPI</acronym> maintainers in identifying the root + cause of problems and in debugging and developing a + solution.</para> <note> <para>Before submitting a problem, ensure the latest @@ -3512,10 +3508,10 @@ debug.acpi.level="ACPI_LV_ERROR"</progra <para>The <acronym>URL</acronym> to a pasted version of the <firstterm><acronym>ACPI</acronym> Source Language</firstterm> (<acronym>ASL</acronym>). Do - <emphasis>not</emphasis> send the - <acronym>ASL</acronym> directly to the list as it can be - very large. Generate a copy of the - <acronym>ASL</acronym> by running this command:</para> + <emphasis>not</emphasis> send the <acronym>ASL</acronym> + directly to the list as it can be very large. Generate a + copy of the <acronym>ASL</acronym> by running this + command:</para> <screen>&prompt.root; <userinput>acpidump -dt > <replaceable>name</replaceable>-<replaceable>system</replaceable>.asl</userinput></screen> @@ -3536,6 +3532,5 @@ debug.acpi.level="ACPI_LV_ERROR"</progra <acronym>PR</acronym> without emailing &a.acpi.name; first as it is likely that the problem has been reported before.</para> </sect2> - </sect1> </chapter>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404142052.s3EKq6jY033684>