In ACPI-debug section:

- s/I/we and s/my/a
- remove some contractions
- Various tags fixes for consistency with the rest of the Handbook
This commit is contained in:
Marc Fonvieille 2004-10-18 17:59:19 +00:00
parent c003826aa6
commit 4861882e8d
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=22623

View file

@ -2626,27 +2626,27 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
<literal>S4</literal><acronym>OS</acronym> is implemented
entirely by the operating system.</para>
<para>Start by checking <command>sysctl</command>
<option>hw.acpi</option> for the suspend-related items. Here
are the results for my Thinkpad:</para>
<para>Start by checking <command>sysctl hw.acpi</command>
for the suspend-related items. Here
are the results for a Thinkpad:</para>
<screen>hw.acpi.supported_sleep_state: S3 S4 S5</screen>
<screen>hw.acpi.s4bios: 0</screen>
<screen>hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.s4bios: 0</screen>
<para>This means that I can use <command>acpiconf -s</command>
<para>This means that we can use <command>acpiconf -s</command>
to test <literal>S3</literal>,
<literal>S4</literal><acronym>OS</acronym>, and
<literal>S5</literal>. If <option>s4bios</option> was one
(<literal>1</literal>), I would have
(<literal>1</literal>), we would have
<literal>S4</literal><acronym>BIOS</acronym>
support instead of <literal>S4</literal>
<acronym>OS</acronym>.</para>
<para>When testing suspend/resume, start with
<literal>S1</literal>, if supported. This state is most
likely to work since it doesn't require much driver support.
likely to work since it does not require much driver support.
No one has implemented <literal>S2</literal> but if you have
it, it's similar to <literal>S1</literal>. The next thing
it, it is similar to <literal>S1</literal>. The next thing
to try is <literal>S3</literal>. This is the deepest
<acronym>STR</acronym> state and requires a lot of driver
support to properly reinitialize your hardware. If you have
@ -2658,15 +2658,15 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
your kernel as possible. If it works, you can narrow down
which driver is the problem by loading drivers until it fails
again. Typically binary drivers like
<filename>nvidia.ko</filename>, <application>X11</application>
<filename>nvidia.ko</filename>, X11
display drivers, and <acronym>USB</acronym> will have the most
problems while Ethernet interfaces usually work fine. If you
can load/unload the drivers ok, you can automate this by
can properly load/unload the drivers, you can automate this by
putting the appropriate commands in
<filename>/etc/rc.suspend</filename> and
<filename>/etc/rc.resume</filename>. There is a
commented-out example for unloading and loading a driver. Try
setting <option>hw.acpi.reset_video</option> to zero (0) if
setting <option>hw.acpi.reset_video</option> to zero (<literal>0</literal>) if
your 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>
@ -2674,7 +2674,7 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
<para>Another thing to try is load a recent Linux distribution
with <acronym>ACPI</acronym> support and test their
suspend/resume support on the same hardware. If it works
on Linux, it's likely a &os; driver problem and narrowing down
on Linux, it is likely a &os; driver problem and narrowing down
which driver causes the problems will help us fix the problem.
Note that the <acronym>ACPI</acronym> maintainers do not
usually maintain other drivers (e.g sound,
@ -2715,7 +2715,7 @@ device_probe_and_attach: cbb0 attach returned 12</screen>
system appears hung, try breaking to <acronym>DDB</acronym>
(<keycombo action="simul"><keycap>CTRL</keycap>
<keycap>ALT</keycap><keycap>ESC</keycap></keycombo> on
console) and type <option>show interrupts</option>.</para>
console) and type <literal>show interrupts</literal>.</para>
<para>Your best hope when dealing with interrupt problems is to
try disabling <acronym>APIC</acronym> support with