DSDT/ASL compiler error

DSDT/ASL compiler error

[Ben B]

Wondering if any ASL experts can help me here. I'm trying to recompile
the DSDT on my HP NC6400 laptop, to hopefully get some better acpi
functionality, and I'm seeing the following error:

$ iasl -tc dsdt.dsl            

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20060608 [Jun 29 2006]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
Warning  1104 -        Result is not used, operator has no effect ^ 

dsdt.dsl  4672:                     Method (_DSM, 4, NotSerialized)
Warning  1086 -                                ^ Not all control paths return a value (_DSM)

dsdt.dsl  4672:                     Method (_DSM, 4, NotSerialized)
Warning  1079 -                                ^ Reserved method must return a value (_DSM)

dsdt.dsl 12767:                 CreateByteField (C1D3, \_SB.C002.C003._X0F._LEN, C08F)
Error    4062 -                                         Object does not exist ^  (\_SB.C002.C003._X0F._LEN)

ASL Input:  dsdt.dsl - 13280 lines, 478523 bytes, 6207 keywords
Compilation complete. 1 Errors, 3 Warnings, 0 Remarks, 2052 Optimizations

The relevent section around line 12767 is this:

    Device (\_SB.C002.C003.C334)
    {
        Name (_HID, EisaId ("PNP0C02"))
        Name (_UID, 0x02)
        Name (\_SB.C002.C003.C1D3, ResourceTemplate ()
        {
            IO (Decode16,
                0x0010,             // Range Minimum
                0x0010,             // Range Maximum
                0x01,               // Alignment
                0x10,               // Length
                )
[... skipping some defs ..]
            IO (Decode16,
                0x00A4,             // Range Minimum
                0x00A4,             // Range Maximum
                0x01,               // Alignment
                0x1A,               // Length
                )
            IO (Decode16,
                0x0500,             // Range Minimum
                0x0500,             // Range Maximum
                0x01,               // Alignment
                0x80,               // Length
                _X0F)
            IO (Decode16,
                0x0800,             // Range Minimum
                0x0800,             // Range Maximum
                0x01,               // Alignment
                0x10,               // Length
                )
            Memory32Fixed (ReadOnly,
                0xFFB00000,         // Address Base
                0x00100000,         // Address Length
                )
            Memory32Fixed (ReadOnly,
                0xFFF00000,         // Address Base
                0x00100000,         // Address Length
                )
        })
        Method (_CRS, 0, NotSerialized)
        {
            If (LEqual (\_SB.C002.C003.C1FC._STA (), 0x0F))
            {
                CreateByteField (C1D3, \_SB.C002.C003.C1D3._X0F._LEN,
C08F)
                Store (0x60, C08F)
            }

            Return (^^C1AD.C1D2 ())
        }
    }


What suggestions does anyone have on fixing this?

Thanks,
BB

Re: DSDT/ASL compiler error

[Thomas Renninger]

On Thu, 2006-08-17 at 19:03 +0200, Ben B wrote:
> Wondering if any ASL experts can help me here. I'm trying to recompile
> the DSDT on my HP NC6400 laptop, to hopefully get some better acpi
> functionality, and I'm seeing the following error:
> 
> $ iasl -tc dsdt.dsl            
> 
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20060608 [Jun 29 2006]
> Copyright (C) 2000 - 2006 Intel Corporation
> Supports ACPI Specification Revision 3.0a
> 
> dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
> Warning  1104 -        Result is not used, operator has no effect ^ 
> 
> dsdt.dsl  4672:                     Method (_DSM, 4, NotSerialized)
> Warning  1086 -                                ^ Not all control paths return a value (_DSM)
> 
> dsdt.dsl  4672:                     Method (_DSM, 4, NotSerialized)
> Warning  1079 -                                ^ Reserved method must return a value (_DSM)
> 
> dsdt.dsl 12767:                 CreateByteField (C1D3, \_SB.C002.C003._X0F._LEN, C08F)
> Error    4062 -                                         Object does not exist ^  (\_SB.C002.C003._X0F._LEN)
> 
I expect this is an HP Bios...
Try:
CreateByteField (C1D3, \_SB.C002.C003.C334._X0F._LEN, C08F)
instead of
CreateByteField (C1D3, \_SB.C002.C003._X0F._LEN, C08F)
in line 12767. The rest should be harmless.

   Thomas

Re: DSDT/ASL compiler error

[Bruno Ducrot]

On Fri, Aug 18, 2006 at 12:33:30PM +0200, Thomas Renninger wrote:
> On Thu, 2006-08-17 at 19:03 +0200, Ben B wrote:
> > Wondering if any ASL experts can help me here. I'm trying to recompile
> > the DSDT on my HP NC6400 laptop, to hopefully get some better acpi
> > functionality, and I'm seeing the following error:
> > 
> > $ iasl -tc dsdt.dsl            
> > 
> > Intel ACPI Component Architecture
> > ASL Optimizing Compiler version 20060608 [Jun 29 2006]
> > Copyright (C) 2000 - 2006 Intel Corporation
> > Supports ACPI Specification Revision 3.0a
> > 
> > dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
> > Warning  1104 -        Result is not used, operator has no effect ^ 
> > 
> > dsdt.dsl  4672:                     Method (_DSM, 4, NotSerialized)
> > Warning  1086 -                                ^ Not all control paths return a value (_DSM)
> > 
> > dsdt.dsl  4672:                     Method (_DSM, 4, NotSerialized)
> > Warning  1079 -                                ^ Reserved method must return a value (_DSM)
> > 
> > dsdt.dsl 12767:                 CreateByteField (C1D3, \_SB.C002.C003._X0F._LEN, C08F)
> > Error    4062 -                                         Object does not exist ^  (\_SB.C002.C003._X0F._LEN)
> > 
> I expect this is an HP Bios...
> Try:
> CreateByteField (C1D3, \_SB.C002.C003.C334._X0F._LEN, C08F)
> instead of
> CreateByteField (C1D3, \_SB.C002.C003._X0F._LEN, C08F)
> in line 12767. The rest should be harmless.
> 

I'm not sure if that's one is harmless:
> > dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
It's as if the asl writter wanted to clear the upper bits of Local1, but forgot to
assign it back to Local1.  It might be something like this:
	And(Local1, 0xFFFF, Local1)

It's only a rough guess though, and wihtout knowing what was the
original intention, and without the source of the ASL, it's hard
to tell for sure.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: DSDT/ASL compiler error

[Ben B]

Bruno Ducrot <ducrot@poupinou.org> uttered the following thing:
> On Fri, Aug 18, 2006 at 12:33:30PM +0200, Thomas Renninger wrote:
> > > 
> > > dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
> > > Warning  1104 -        Result is not used, operator has no effect ^ 
> > > 
> I'm not sure if that's one is harmless:
> > > dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
> It's as if the asl writter wanted to clear the upper bits of Local1, but forgot to
> assign it back to Local1.  It might be something like this:
> 	And(Local1, 0xFFFF, Local1)
> 
> It's only a rough guess though, and wihtout knowing what was the
> original intention, and without the source of the ASL, it's hard
> to tell for sure.

This is the context around there. I can send the whole asl if you'd like
also:

                                Store (C15B, Local1)
                                If (Local1)
                                {
                                    If (And (C165, 0x40))
                                    {
                                        Add (Not (Local1), 0x01, Local1)
                                        And (Local1, 0xFFFF)
                                    }
                                }

                                Store (Local1, Index (DerefOf (Index (Local0, 0x02)), 0x0E))

Of particular interest that I'd like to get going also is the built in
accelerometer, which I only discovered browsing the ASL:

            Device (ACEL)
            {
                Name (_HID, EisaId ("HPQ0004"))

"HP Mobile Data Protection Sensor"....but that's for another project. :)

Ben

Re: DSDT/ASL compiler error

[Bruno Ducrot]

On Fri, Aug 18, 2006 at 02:10:48PM +0200, Ben B wrote:
> Bruno Ducrot <ducrot@poupinou.org> uttered the following thing:
> > On Fri, Aug 18, 2006 at 12:33:30PM +0200, Thomas Renninger wrote:
> > > > 
> > > > dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
> > > > Warning  1104 -        Result is not used, operator has no effect ^ 
> > > > 
> > I'm not sure if that's one is harmless:
> > > > dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
> > It's as if the asl writter wanted to clear the upper bits of Local1, but forgot to
> > assign it back to Local1.  It might be something like this:
> > 	And(Local1, 0xFFFF, Local1)
> > 
> > It's only a rough guess though, and wihtout knowing what was the
> > original intention, and without the source of the ASL, it's hard
> > to tell for sure.
> 
> This is the context around there. I can send the whole asl if you'd like
> also:
> 
>                                 Store (C15B, Local1)
>                                 If (Local1)
>                                 {
>                                     If (And (C165, 0x40))
>                                     {
>                                         Add (Not (Local1), 0x01, Local1)
>                                         And (Local1, 0xFFFF)
>                                     }
>                                 }
> 
>                                 Store (Local1, Index (DerefOf (Index (Local0, 0x02)), 0x0E))

Sound like it really should be And(Local1, 0xFFFF, Local1).

> accelerometer, which I only discovered browsing the ASL:
> 
>             Device (ACEL)
>             {
>                 Name (_HID, EisaId ("HPQ0004"))
> 
> "HP Mobile Data Protection Sensor"....but that's for another project. :)

Indeed.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: DSDT/ASL compiler error

[Thomas Renninger]

On Fri, 2006-08-18 at 13:25 +0200, Bruno Ducrot wrote:
> On Fri, Aug 18, 2006 at 12:33:30PM +0200, Thomas Renninger wrote:
> > On Thu, 2006-08-17 at 19:03 +0200, Ben B wrote:
> > > Wondering if any ASL experts can help me here. I'm trying to recompile
> > > the DSDT on my HP NC6400 laptop, to hopefully get some better acpi
> > > functionality, and I'm seeing the following error:
> > > 
> > > $ iasl -tc dsdt.dsl            
> > > 
> > > Intel ACPI Component Architecture
> > > ASL Optimizing Compiler version 20060608 [Jun 29 2006]
> > > Copyright (C) 2000 - 2006 Intel Corporation
> > > Supports ACPI Specification Revision 3.0a
> > > 
> > > dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
> > > Warning  1104 -        Result is not used, operator has no effect ^ 
> > > 
> > > dsdt.dsl  4672:                     Method (_DSM, 4, NotSerialized)
> > > Warning  1086 -                                ^ Not all control paths return a value (_DSM)
> > > 
> > > dsdt.dsl  4672:                     Method (_DSM, 4, NotSerialized)
> > > Warning  1079 -                                ^ Reserved method must return a value (_DSM)
> > > 
> > > dsdt.dsl 12767:                 CreateByteField (C1D3, \_SB.C002.C003._X0F._LEN, C08F)
> > > Error    4062 -                                         Object does not exist ^  (\_SB.C002.C003._X0F._LEN)
> > > 
> > I expect this is an HP Bios...
> > Try:
> > CreateByteField (C1D3, \_SB.C002.C003.C334._X0F._LEN, C08F)
> > instead of
> > CreateByteField (C1D3, \_SB.C002.C003._X0F._LEN, C08F)
> > in line 12767. The rest should be harmless.
> > 
> 
> I'm not sure if that's one is harmless:
> > > dsdt.dsl  3275:                                         And (Local1, 0xFFFF)
> It's as if the asl writter wanted to clear the upper bits of Local1, but forgot to
> assign it back to Local1.  It might be something like this:
> 	And(Local1, 0xFFFF, Local1)
> 
> It's only a rough guess though, and wihtout knowing what was the
> original intention, and without the source of the ASL, it's hard
> to tell for sure.

Thanks.

I checked on a very similar DSDT table:
This line seems only to be used for the WMAA method:
Method (WMAA, 3, NotSerialized)
{
    Return (C23E (Arg1, Arg2))
}
C23E->C24B->C1AB(in this function is the line), the functions are only
used once in DSDT.
I expect this method is part of the Windows Management Instrumentation
(WMI -> [1]).
The functions might have other names in your dsl output file.
As the WMAA function shouldn't get used on a current linux system it
should be harmless in the end.

(unfortunately, I hoped that was the missing hint to fix some things on
this system).

Sorry Ben, I can't help you with the HPQ0004 device, I don't know
anything about this one and don't have such a machine myself.

Thanks again,

     Thomas

[1]: http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx

Re: DSDT/ASL compiler error

[Bruno Ducrot]

On Fri, Aug 18, 2006 at 03:09:56PM +0200, Thomas Renninger wrote:
> (unfortunately, I hoped that was the missing hint to fix some things on
> this system).

What things need to be fixed?  I'm just curious.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: DSDT/ASL compiler error

[Thomas Renninger]

On Fri, 2006-08-18 at 22:18 +0200, Bruno Ducrot wrote:
> On Fri, Aug 18, 2006 at 03:09:56PM +0200, Thomas Renninger wrote:
> > (unfortunately, I hoped that was the missing hint to fix some things on
> > this system).
> 
> What things need to be fixed?  I'm just curious.

- _PPC always returns 1, therefore highest freq cannot be set
  (also reported recently on cpufreq list)
  https://bugzilla.novell.com/show_bug.cgi?id=179702

- The other one could be an EC issue:
  battery and AC status is not updated.
  May be an interference with the mouse driver from the comments,
  no idea yet.
  https://bugzilla.novell.com/show_bug.cgi?id=200169

Any hints are greatly appreciated...
AFAIK both (at least first on several Core Duo models) phenomenons seem
to happen on several (all?) new HP models.

   Thomas

Re: DSDT/ASL compiler error

[Bruno Ducrot]

On Sat, Aug 19, 2006 at 02:50:12PM +0200, Thomas Renninger wrote:
> On Fri, 2006-08-18 at 22:18 +0200, Bruno Ducrot wrote:
> > On Fri, Aug 18, 2006 at 03:09:56PM +0200, Thomas Renninger wrote:
> > > (unfortunately, I hoped that was the missing hint to fix some things on
> > > this system).
> > 
> > What things need to be fixed?  I'm just curious.
> 
> - _PPC always returns 1, therefore highest freq cannot be set
>   (also reported recently on cpufreq list)
>   https://bugzilla.novell.com/show_bug.cgi?id=179702
> 
> - The other one could be an EC issue:
>   battery and AC status is not updated.
>   May be an interference with the mouse driver from the comments,
>   no idea yet.
>   https://bugzilla.novell.com/show_bug.cgi?id=200169
> 
> Any hints are greatly appreciated...
> AFAIK both (at least first on several Core Duo models) phenomenons seem
> to happen on several (all?) new HP models.
> 

My first though is to try atpic instead of apic and maybe tweak
apci_sci= parameter?  I'll look more in details the bug.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: DSDT/ASL compiler error

[Bruno Ducrot]

On Sat, Aug 19, 2006 at 02:50:12PM +0200, Thomas Renninger wrote:
> On Fri, 2006-08-18 at 22:18 +0200, Bruno Ducrot wrote:
> > On Fri, Aug 18, 2006 at 03:09:56PM +0200, Thomas Renninger wrote:
> > > (unfortunately, I hoped that was the missing hint to fix some things on
> > > this system).
> > 
> > What things need to be fixed?  I'm just curious.
> 
> - _PPC always returns 1, therefore highest freq cannot be set
>   (also reported recently on cpufreq list)
>   https://bugzilla.novell.com/show_bug.cgi?id=179702
> 
> - The other one could be an EC issue:
>   battery and AC status is not updated.
>   May be an interference with the mouse driver from the comments,
>   no idea yet.
>   https://bugzilla.novell.com/show_bug.cgi?id=200169
> 
> Any hints are greatly appreciated...
> AFAIK both (at least first on several Core Duo models) phenomenons seem
> to happen on several (all?) new HP models.
> 

Also I'm wondering why there is a \_PR.CPU0.INI() method.  I'm wondering
if it should be a _INI instead.  But it seems it's a workaround for some
others OSs and I'm not sure if we have to call the SMM implied by that
_INI in order to fix that since Linux should have done something similar
already?

Strange.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: DSDT/ASL compiler error

[Thomas Renninger]

Am So 20.08.2006 12:22 schrieb Bruno Ducrot <ducrot@poupinou.org>:
>
>> On Sat, Aug 19, 2006 at 02:50:12PM +0200, Thomas Renninger wrote:
>> > On Fri, 2006-08-18 at 22:18 +0200, Bruno Ducrot wrote:
>> > > On Fri, Aug 18, 2006 at 03:09:56PM +0200, Thomas Renninger wrote:
>> > > > (unfortunately, I hoped that was the missing hint to fix some
>> > > > things on
>> > > > this system).
>> > >
>> > > What things need to be fixed? I'm just curious.
>> >
>> > - _PPC always returns 1, therefore highest freq cannot be set
>> > (also reported recently on cpufreq list)
>> > https://bugzilla.novell.com/show_bug.cgi?id=179702
>> >
>> > - The other one could be an EC issue:
>> > battery and AC status is not updated.
>> > May be an interference with the mouse driver from the comments,
>> > no idea yet.
>> > https://bugzilla.novell.com/show_bug.cgi?id=200169
>> >
>> > Any hints are greatly appreciated...
>> > AFAIK both (at least first on several Core Duo models) phenomenons
>> > seem
>> > to happen on several (all?) new HP models.
>> >
>>
>> Also I'm wondering why there is a _PR.CPU0.INI() method. I'm
>> wondering
>> if it should be a _INI instead. But it seems it's a workaround for
>> some
>> others OSs and I'm not sure if we have to call the SMM implied by
>> that
>> _INI in order to fix that since Linux should have done something
>> similar
>> already?
>>
>> Strange.
>
>The _INI funcs are declared in SSDT(s) just invoking INI().
>The SMM stuff in _INI seems to be called if _OSI function only returns
>true for "Windows 2001" (don't have the table here right now, but it
>was for a specific _OSI string setting C014 to 0x4 which is checked
>there). It didn't help, it even made things worse, slowing the whole
>system down extremly.
>
>    Thomas
>

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html