public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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