Re: Documentation - How to debug ACPI Problems

[Jesper Juhl]

On 06/06/07, Thomas Renninger <trenn@xxxxxxx> wrote:
> Hi,
>
> I made up a little How-To for what I find out is nice to debug ACPI
> problems.
Nice :-)

> Any enhancements, corrections, etc. are very much appreciated.
See below.

> I'd like to have a final version in the Documentation section.
When you send in the patch to add that final version, please also
remember to add an entry to Documentation/00-INDEX

[snip]
> How to debug ACPI Problems
> ==========================
>
> Thomas Renninger <trenn@xxxxxxx>, 2007
> Copyright (C) 2007 SUSE Linux GmbH
>
>
> 1. Introduction
> ---------------
>
> 1.1. General Info
> - - - - - - - -
Perhaps start out here by telling people what ACPI is. Something like this:

ACPI stands for Advanced Configuration and Power Interface.

> Please refer to the latest ACPI spec for general ACPI information:
> http://www.acpi.info/spec.htm
>
> ACPI is required by most recent x86, x86_64 and IA64 architecture based
> machines.
>
> In general ACPI tables provide information from the BIOS to the OS.
> There are ACPI tables (DSDT and SSDTs), written in the ACPI Source
> Language (ASL) which include byte code (similar to Java byte code) that gets
> interpreted by the OS. The kernel makes use of provided BIOS functions

The word "provided" seems superfluous here.

[snip]
> The ACPI tables of your system can be extracted with the acpidump tool:

I think the colon ":" at the end of this line should be removed.

> in the latest pmutils package from here:
> ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils
[snip]
> In history people used to override their DSDT to workaround BIOS or even kernel

I would replace "In history people used to ..." with "Historically
people used to ...".

[snip]
> If you expect the bug in a module in drivers/acpi/*.c code you might have luck
> and be able to find or narrow down the culprit by simple printks.
I would rewrite that bit as :

If you suspect the bug to be in a module in drivers/acpi/*.c code, you
may be able to find or narrow down the culprit simply by adding
printk()'s.

> On more complicated bugs you should make use of the ACPI_DEBUG=y facility.

Maybe just me, but I would say "For" here instead of "On".

[snip]
>          Note: In kernel versions before 2.6.22 the boot parameters are:

should be "...the boot parameters were:" - past tense.

[snip]
>          interface (Documentation/networking/netconsole.txt) to write away
>          syslog messages over network or firescope

"... to write away syslog messages over network ..." sounds a little
clumsy to me. Why not simply write "... to send syslog messages over
network ..." ?

> (patches already exist in
>          2.6.22-rcX-mm?) to send syslog messages over firewire.
>          The latter might be the only way to debug early hangs on laptops
>          without serial console anyway.

"without a serial console" ???

>    3.2.2 Using ACPI_DEBUG Boot Parameters via /sysfs and /proc
>
>          The same as 3.2.1., you can also pass the parameters at runtime e.g.
>          via:
>          echo 0x1F >/proc/acpi/debug_level    # before 2.6.22 or
>          echo ?!?  >/sys/?/!/?                # Rui?

Seems like some bits are missing here ^^^

>          Wrapping such statements around loading and unloading a bug affected
>          ACPI module might give you the possibility to increase debug_level,
>          but still only give you a managable amount of debug output.

s/managable/manageable/


[snip]

--
Jesper Juhl <jesper.juhl@xxxxxxxxx>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/