[Devel] Clarification request about AcpiDbgLevel and AcpiGbl_EnableAmlDebugObject

[Devel] Clarification request about AcpiDbgLevel and AcpiGbl_EnableAmlDebugObject

[Sascha Wildner]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

Hello,

here is an issue I don't understand.

* In acpixf.h, if ACPI_DEBUG_OUTPUT is not set, AcpiDbgLevel is defined to
ACPI_NORMAL_DEFAULT, and ACPI_LV_DEBUG_OBJECT is part of that.

* In exdebug.c, function AcpiExDoDebugObject(), it returns early without
printing when neither AcpiGbl_EnableAmlDebugObject is set nor
ACPI_LV_DEBUG_OBJECT is in AcpiDbgLevel, else it proceeds with printing.
But by default, ACPI_LV_DEBUG_OBJECT is in AcpiDbgLevel (see above).
AcpiExDoDebugObject() is the only place where AcpiGbl_EnableAmlDebugObject
is referenced.

The reference manual says (at least that's how I read it) that when
AcpiGbl_EnableAmlDebugObject is FALSE, output from the AML "Debug Object"
is disabled, but given the definition of ACPI_NORMAL_DEFAULT together with
the check in AcpiExDoDebugObject(), that doesn't seem to be the case.

So my question is: How should the host OS properly handle this? I saw that
FreeBSD for example initializes AcpiDbgLevel to 0 (when their ACPI_DEBUG
switch isn't set) but the reference manual doesn't mention that anything
other than AcpiGbl_EnableAmlDebugObject being FALSE is necessary.

Or am I missing something?

Sascha

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1402 bytes --]

Re: [Devel] Clarification request about AcpiDbgLevel and AcpiGbl_EnableAmlDebugObject

[Zheng, Lv]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

Hi,

IMO, AcpiGbl_EnableAmlDebugObject is deprecated, removing it can reduce memory consumption of ACPICA.
It’s an old mechanism referenced by Linux as a module parameter – acpi.aml_debug_output.
When removing it, we should carefully prevent old OSPMs behavior from being changed.
In Linux kernel, there are some cleanups need to be done for ACPI_DEBUG_OUTPUT first.
Which might be the cause why the cleanup of AcpiGbl_EnableAmlDebugObject hasn’t happened.

Thanks and best regards
-Lv

From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Sascha Wildner
Sent: Thursday, May 15, 2014 4:54 AM
To: devel(a)acpica.org
Subject: [Devel] Clarification request about AcpiDbgLevel and AcpiGbl_EnableAmlDebugObject

Hello,

here is an issue I don't understand.

* In acpixf.h, if ACPI_DEBUG_OUTPUT is not set, AcpiDbgLevel is defined to ACPI_NORMAL_DEFAULT, and ACPI_LV_DEBUG_OBJECT is part of that.

* In exdebug.c, function AcpiExDoDebugObject(), it returns early without printing when neither AcpiGbl_EnableAmlDebugObject is set nor ACPI_LV_DEBUG_OBJECT is in AcpiDbgLevel, else it proceeds with printing. But by default, ACPI_LV_DEBUG_OBJECT is in AcpiDbgLevel (see above). AcpiExDoDebugObject() is the only place where AcpiGbl_EnableAmlDebugObject is referenced.

The reference manual says (at least that's how I read it) that when AcpiGbl_EnableAmlDebugObject is FALSE, output from the AML "Debug Object" is disabled, but given the definition of ACPI_NORMAL_DEFAULT together with the check in AcpiExDoDebugObject(), that doesn't seem to be the case.

So my question is: How should the host OS properly handle this? I saw that FreeBSD for example initializes AcpiDbgLevel to 0 (when their ACPI_DEBUG switch isn't set) but the reference manual doesn't mention that anything other than AcpiGbl_EnableAmlDebugObject being FALSE is necessary.

Or am I missing something?

Sascha


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 30854 bytes --]

Re: [Devel] Clarification request about AcpiDbgLevel and AcpiGbl_EnableAmlDebugObject

[David E. Box]

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

On Wed, May 14, 2014 at 10:53:30PM +0200, Sascha Wildner wrote:
> Hello,
> 
> here is an issue I don't understand.
> 
> * In acpixf.h, if ACPI_DEBUG_OUTPUT is not set, AcpiDbgLevel is defined to
> ACPI_NORMAL_DEFAULT, and ACPI_LV_DEBUG_OBJECT is part of that.
> 
> * In exdebug.c, function AcpiExDoDebugObject(), it returns early without
> printing when neither AcpiGbl_EnableAmlDebugObject is set nor
> ACPI_LV_DEBUG_OBJECT is in AcpiDbgLevel, else it proceeds with printing.
> But by default, ACPI_LV_DEBUG_OBJECT is in AcpiDbgLevel (see above).
> AcpiExDoDebugObject() is the only place where AcpiGbl_EnableAmlDebugObject
> is referenced.
> 
> The reference manual says (at least that's how I read it) that when
> AcpiGbl_EnableAmlDebugObject is FALSE, output from the AML "Debug Object"
> is disabled, but given the definition of ACPI_NORMAL_DEFAULT together with
> the check in AcpiExDoDebugObject(), that doesn't seem to be the case.
>

I agree the spec isn't clear here. The comment description in the code for
AcpiExDoDebugObject() is correct however. Debug Object output can be enabled by
_either_ having the global switch set, AcpiGbl_EnableAmlDebugObject, or by
setting the bit for ACPI_DEBUG_OUTPUT in AcpiDbgLevel. By default we turn of the
global switch, but Debug Object gets enabled anyway by bit field selection
through ACPI_NORMAL_DEFAULT as you mentioned.

We'll see about making this clearer in the spec.

> So my question is: How should the host OS properly handle this? I saw that
> FreeBSD for example initializes AcpiDbgLevel to 0 (when their ACPI_DEBUG
> switch isn't set) but the reference manual doesn't mention that anything
> other than AcpiGbl_EnableAmlDebugObject being FALSE is necessary.

How should the host OS handle what exactly? I think you misunderstand what Debug
Object is. In ASL you can use the Store operator to print debug messages like
this:

	// The contents of name will be output using AcpiOsPrintf
	Store(NAME, Debug) 

It's like printk's for BIOS developers. It's a simply way of printing custom
"debug" messages directly from the ASL code and has no effect on whether
messages will be printed for warnings, errors, etc. Each of these are controlled
by a single bit in the 32 bit AcpiDbgLevel bit field. You can see these in
acoutput.h

Setting AcpiDbgLevel to 0 is the way to turn of all debug output. However you
can still use the the global switch, AcpiGbl_EnableAmlDebugObject, to see just
the Debug Object (the BIOS developers printk's) that may exist in the AML.

-- Dave Box

Re: [Devel] Clarification request about AcpiDbgLevel and AcpiGbl_EnableAmlDebugObject

[Sascha Wildner]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Thu, May 15, 2014 at 3:08 AM, David E. Box
<david.e.box(a)linux.intel.com> wrote:
> On Wed, May 14, 2014 at 10:53:30PM +0200, Sascha Wildner wrote:
>> So my question is: How should the host OS properly handle this? I saw that
>> FreeBSD for example initializes AcpiDbgLevel to 0 (when their ACPI_DEBUG
>> switch isn't set) but the reference manual doesn't mention that anything
>> other than AcpiGbl_EnableAmlDebugObject being FALSE is necessary.
>
> How should the host OS handle what exactly? I think you misunderstand what Debug
> Object is. In ASL you can use the Store operator to print debug messages like
> this:

David,

sorry for not being clear enough the first time.

After a recent ACPICA upgrade in DragonFly BSD we've had some reports
of (mostly temperature related) Debug Object output like for example
http://lists.dragonflybsd.org/pipermail/users/2014-February/109309.html,
which I was investigating. I checked the reference and I
(mis)understood it as saying that with AcpiGbl_EnableAmlDebugObject
being FALSE alone, Debug Object output would not be printed, which
confused me, so I asked etc.

But I understand now that if I wanted to disable them, I would need to
modify AcpiDbgLevel, too. I'll study the ASL first, though.

Sascha

Re: [Devel] Clarification request about AcpiDbgLevel and AcpiGbl_EnableAmlDebugObject

[David E. Box]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

On Thu, May 15, 2014 at 09:21:33PM +0200, Sascha Wildner wrote:
> On Thu, May 15, 2014 at 3:08 AM, David E. Box
> <david.e.box(a)linux.intel.com> wrote:
> > On Wed, May 14, 2014 at 10:53:30PM +0200, Sascha Wildner wrote:
> >> So my question is: How should the host OS properly handle this? I saw that
> >> FreeBSD for example initializes AcpiDbgLevel to 0 (when their ACPI_DEBUG
> >> switch isn't set) but the reference manual doesn't mention that anything
> >> other than AcpiGbl_EnableAmlDebugObject being FALSE is necessary.
> >
> > How should the host OS handle what exactly? I think you misunderstand what Debug
> > Object is. In ASL you can use the Store operator to print debug messages like
> > this:
> 
> David,
> 
> sorry for not being clear enough the first time.
> 
> After a recent ACPICA upgrade in DragonFly BSD we've had some reports
> of (mostly temperature related) Debug Object output like for example
> http://lists.dragonflybsd.org/pipermail/users/2014-February/109309.html,
> which I was investigating.

I'm not aware of a change we made recently that would have turned on Debug
Output, but maybe Lv knows. A BIOS change would be the culprit here. However if
you can clearly bisect the issue down to a difference in the version of ACPICA
and nothing else, we'd like to know about.

> I checked the reference and I
> (mis)understood it as saying that with AcpiGbl_EnableAmlDebugObject
> being FALSE alone, Debug Object output would not be printed, which
> confused me, so I asked etc.

I think we should explicitly state that it can still be enabled by
AcpiDbgLevel in the spec to clear up any confusion.

> But I understand now that if I wanted to disable them, I would need to
> modify AcpiDbgLevel, too. I'll study the ASL first, though.

Good luck with that.

-- Dave Box