Messages in this thread | | | Date | Wed, 6 Jun 2007 16:59:35 +0200 | From | "Jesper Juhl" <> | Subject | Re: Documentation - How to debug ACPI Problems |
| |
On 06/06/07, Thomas Renninger <trenn@suse.de> 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@suse.de>, 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@gmail.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |