All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.