From: Zhang Rui <rui.zhang@intel.com>
To: trenn@suse.de
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
"linux-acpi@vger" <linux-acpi@vger.kernel.org>
Subject: Re: Documentation - How to debug ACPI Problems
Date: Sat, 03 Jan 2004 06:32:46 +0800 [thread overview]
Message-ID: <1073082766.5397.14.camel@localhost.localdomain> (raw)
In-Reply-To: <1181140008.28514.259.camel@queen.suse.de>
On Wed, 2007-06-06 at 16:26 +0200, Thomas Renninger wrote:
>
> 3. Problem Analysis and Solving
> -------------------------------
>
> 3.1. I see Warnings or Errors when disassembling or compiling my DSDT
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Some might be sever ACPICA or BIOS bugs, some might just be incompatibilities
> with the Microsoft compiler. We want to fix both, therefore a bug should be
> filed at bugzilla.kernel.org
> In general you should watch your system, if you don't miss any functionality
> there is no reason to panic (e.g. modify the DSDT and override your original
> one, you really should not do that if you do not see any big advantage and even
> then, better try to get a real fix or at least a kernel workaround like a
> boot or module parameter).
>
> You should be able to debug this with userspace tools (See:
> "1.2. Useful Userspace Tools for Table Playing")
>
>
> 3.2) Hardware accessed by ACPI is not working correctly - Using ACPI_DEBUG
3.2. typo
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> 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.
>
> On more complicated bugs you should make use of the ACPI_DEBUG=y facility.
> This allows you to fine grain enable specific output in the ACPI interpreter.
>
>
> 3.2.1 Using ACPI_DEBUG Boot Parameters acpi.debug_level and acpi.debug_layer
>
> Note: In kernel versions before 2.6.22 the boot parameters are:
> acpi_dbg_level and acpi_dbg_layer
>
> ACPI can produce tons of debug output if these debug masks are
> switched to full on.
> include/acpi/acoutput.h shows which flags can be enabled for level and
> layer (cat /proc/acpi/debug_{level,layer} also shows you the flags,
> but that interface will move to sysfs, not sure whether there still
> will be such a help).
They work in the same way as they do in procfs.
i.e. cat /sys/module/acpi/parameters/debug_{level,layer}
shows you the flags as well.
In fact, I think they can replace the proc I/F right now.
>
> Therefore, switch on debug flags carefully. You also might want to
> increase the kernel ring buffer by passing:
> log_buf_len=XY in bytes and later use dmesg -s XY to get more than
> 16k kernel log output.
> Instead of serial console logging you might want to use the netconsole
> interface (Documentation/networking/netconsole.txt) to write away
> syslog messages over network or firescope (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.
>
> 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?
echo 0x1F >/sys/module/acpi/parameters/debug_level
And we still support the ACPI debug proc I/F at the current stage.
Thanks,
Rui
next prev parent reply other threads:[~2007-06-07 7:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-06 14:26 Documentation - How to debug ACPI Problems Thomas Renninger
2004-01-02 22:32 ` Zhang Rui [this message]
2007-06-06 14:59 ` Jesper Juhl
2007-06-11 16:28 ` Thomas Renninger
2007-06-18 4:12 ` Len Brown
2007-06-18 11:18 ` Thomas Renninger
2007-08-14 15:25 ` Len Brown
2007-08-14 15:25 ` Len Brown
2007-08-14 15:40 ` Len Brown
2007-08-14 16:49 ` Thomas Renninger
2007-08-14 16:50 ` Henrique de Moraes Holschuh
2007-08-14 17:33 ` Alan Cox
2007-08-14 18:03 ` Valdis.Kletnieks
2007-06-06 15:52 ` Alexey Starikovskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1073082766.5397.14.camel@localhost.localdomain \
--to=rui.zhang@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trenn@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox