This looks like the EC read/write problem that is fixed by these two changes:

From: Bob Moore <robert.moore@intel.com>
Date: Fri, 6 Sep 2013 14:27:15 +0800
Subject: ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a  field.

commit 4be4be8fee2ee99a52f94f90d03d2f287ee1db86 upstream.

This change fixes a problem where a Store operation to an ArgX object that contained a reference to a field object did not complete the automatic dereference and then write to the actual field object.
Instead, the object type of the field object was inadvertently changed to match the type of the source operand. The new behavior will actually write to the field object (buffer field or field unit), thus matching the correct ACPI-defined behavior.

From: Bob Moore <robert.moore@intel.com>
Date: Thu, 8 Aug 2013 15:29:32 +0800
Subject: ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and  BufferField refs.

commit 63660e05ec719613b518547b40a1c501c10f0bc4 upstream.

Previously, references to these objects were resolved only to the actual FieldUnit or BufferField object. The correct behavior is to resolve these references to an actual value.
The problem is that DerefOf did not resolve these objects to actual values.  An "Integer" object is simple, return the value.  But a field in an operation region will require a read operation.  For a BufferField, the appropriate data must be extracted from the parent buffer.

NOTE: It appears that this issues is present in Windows7 but not Windows8.

It is so strange that this method also be complained:

               Method (_BTP, 1, NotSerialized)  // _BTP: Battery Trip Point 
                {     

                    If (LAnd (LNotEqual (Zero, ECRD (RefOf (B1FC))), LNotEqual (
                        Zero, ECRD (RefOf (B1FV)))))
                    {     
                        Store (Divide (Multiply (Arg0, 0x64), Divide (Multiply (ECRD (RefOf (
                            B1FC)), ECRD (RefOf (B1FV))), 0x03E8, ), ), Local0)
                        Add (Local0, One, Local0)
                        Store (Local0, ECRD( RefOf (BTP1)))
                    }     

                    Return (Zero)
                }     


The error msg is :
[  100.550084] ACPI Error: Needed [Integer/String/Buffer], found [Reference] ffff880193a65ee8 (20131115/exresop-422)
[  100.550090] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [LAnd] (20131115/dswexec-461)
[  100.550093] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.H_EC.BAT1._BTP] (Node ffff880196885d20), AE_AML_OPERAND_TYPE (20131115/psparse-536)

Hi, I failed to compile the decompilation result (the dsdt file) you posted into AML code.  It might be broken if decompiler is not used correctly.
Could you please post an acpidump output instead?

Thanks in advance.

Created attachment 118121 [details]
original DSDT from my machine.

Yes,of cource.
I also notice it.I sucessfully recompile it after revising the errors.
(In reply to Lv Zheng from comment #3)
> Hi, I failed to compile the decompilation result (the dsdt file) you posted
> into AML code.  It might be broken if decompiler is not used correctly.
> Could you please post an acpidump output instead?
> 
> Thanks in advance.

I couldn't reproduce this issue in the recent ACPICA repo.  I'll attach AcpiExec debugging stuff into this thread.  This might be an already fixed bug.
Could you offer ACPI_CA_VERSION?  It could be found in include/acpi/acpixf.h.

Created attachment 118761 [details]
Debugging DSDT for this issue

The minimal DSDT for debugging.

Created attachment 118771 [details]
Debugging patch to reproduce this issue in AcpiExec.

This debugging patch can be used in AcpiExec to reproduce this bug.
Nothing went wrong. So could you please try a recent kernel?

(In reply to Lv Zheng from comment #8)
> Created attachment 118771 [details]
> Debugging patch to reproduce this issue in AcpiExec.
> 
> This debugging patch can be used in AcpiExec to reproduce this bug.
> Nothing went wrong. So could you please try a recent kernel?

The ACPI_CA_VERSION is 0x20131115, kernel version is 3.13-rc3,which I think is recent.
I think the linux ACPICA has some bugs.For example:
Store (And (ECRD (RefOf (B1ST)), 0x07), Index (PKG1, Zero))
will got "ACPI Error: Needed type [Reference], found [Integer] ".
But if I change it to:
Store (And (0x07,ECRD (RefOf (B1ST))), Index (PKG1, Zero))
Nothing goes wrong and I can see the battery information.
Isn't it strange?

The fix for the ECRD issue is addressed in comment #1

Should I patch the linux kernel source or use a modified DSDT file?
Now I am using a modified DSDT file.And I can see the  remaining battery
capacity,but not detect whether the battery is charging.
I have ever patched the kernel according to comment 1,but still not work.
I am not sure how many methords which are still not work in DSDT.But at least the lid close event cannot be detected.

It seems that the recent linux kernel 3.13-rc4 has commit the two patchs mentioned in Comment 1.Unfortunately,it still cannot parse/execute the method _BST.So I have to use my modified DSDT file.

I'm a little confused by what you've posted here.

Could you please:
1. Download latest ACPICA from acpica.org.
   https://acpica.org/downloads
2. Boot the platform with DSDT customized.
3. Executing the following commands:
   # cd <dir to acpica>
   # make acpidump
   # sudo <dir to acpica>/generate/unix/bin/acpidump -c > dsdt-ospm.txt
   # sudo <dir to acpica>/generate/unix/bin/acpidump > dsdt-bios.txt
   # dmesg > dmesg-ospm.txt
4. Post the dsdt-ospm.txt, dsdt-bios.txt and dsdt-ospm.txt here.

Thanks in advance.

(In reply to Lv Zheng from comment #13)

Sorry a typo fix here:

The line of:
> 4. Post the dsdt-ospm.txt, dsdt-bios.txt and dsdt-ospm.txt here.
should be:
4. Post the dsdt-ospm.txt, dsdt-bios.txt and dmesg-ospm.txt here.

Created attachment 124731 [details]
dsdt-ospm

Created attachment 124741 [details]
dsdt-bios

Created attachment 124751 [details]
dmesg-ospm

My laptop is hasee A500C too,the same problem.here is my files....
(In reply to Lv Zheng from comment #14)
> (In reply to Lv Zheng from comment #13)
> 
> Sorry a typo fix here:
> 
> The line of:
> > 4. Post the dsdt-ospm.txt, dsdt-bios.txt and dsdt-ospm.txt here.
> should be:
> 4. Post the dsdt-ospm.txt, dsdt-bios.txt and dmesg-ospm.txt here.

Hi, 

The output results of dsdt-ospm and dsdt-bios are same (no DSDT customizations?).  And they all seem to be generated by the acpidump not downloaded from acpica.org.

Using latest acpica.org acpidump, you'll find:

DSDT/FACS are the first 2 tables in the dumped file generated by "sudo acpidump";
RSDP/RSDT/XSDT/DSDT/FACS are the very first tables in the dumped file generated by "sudo acpidump -c".

Please check and upload the correct acpidump outputs.

Created attachment 126571 [details]
1

Created attachment 126581 [details]
dsdt-ospm

Created attachment 126591 [details]
dsdt-bios

Created attachment 126601 [details]
dmesg-ospm

Sorry,I am late.
(In reply to Lv Zheng from comment #13)
> I'm a little confused by what you've posted here.
> 
> Could you please:
> 1. Download latest ACPICA from acpica.org.
>    https://acpica.org/downloads
> 2. Boot the platform with DSDT customized.
> 3. Executing the following commands:
>    # cd <dir to acpica>
>    # make acpidump
>    # sudo <dir to acpica>/generate/unix/bin/acpidump -c > dsdt-ospm.txt
>    # sudo <dir to acpica>/generate/unix/bin/acpidump > dsdt-bios.txt
>    # dmesg > dmesg-ospm.txt
> 4. Post the dsdt-ospm.txt, dsdt-bios.txt and dsdt-ospm.txt here.
> 
> Thanks in advance.

Created attachment 127601 [details]
The differences between the 2 DSDTs

This is the differences between the 2 DSDTs.
Bob, is the modification still required by current ACPICA interpreter?

Created attachment 127621 [details]
dmesg | grep ACPI

This is the newest kernel version,which still does not detect the battery.

linux-3.14-rc4

Hi,

For clarification purpose.

In order to identify the differences between the 2 bootup sequences, can you upload 2 dmesg outpus against the same kernel.  One is booted without DSDT customized (dmsg-bios.txt), one is booted with DSDT customized (dmsg-ospm.txt).

If one of them can use already uploaded dmesg, please point me the link.  For example: "attachment 127621 [details]".

The diff result of the 2 dmesg outputs might be helpful for debugging.

Created attachment 127641 [details]
This is the normal dmesg output

Created attachment 127651 [details]
This is the dmesg output with customized dsdt file

Have upload the two files

Hi,

This diff block is very suspecious:

@@ -16617,7 +16738,6 @@
                 Name (_UID, One)  // _UID: Unique ID
                 Method (_STA, 0, NotSerialized)  // _STA: Status
                 {
-                    Store (One, BNUM)
                     If (And (BNUM, One))
                     {
                         Return (0x1F)

In your customized DSDT, the BAT1 _STA method can be decoded as:
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    Store (One, BNUM)
                    If (And (BNUM, One))
                    {
                        Return (0x1F)
                    }

                    If (LLessEqual (OSYS, 0x07D2))
                    {
                        Return (0x0A)
                    }

                    Return (0x0B)
                }

So it will always return 0x1F and make the battery detected for Linux.

Could you try a DSDT customized kernel without this line but with others kept to see if the battery can still be detected?

If not,when I hibernate to disk and resume from it,the battery is not detected again.I don't know why hibernate will change BNUM.
(In reply to Lv Zheng from comment #31)
> Hi,
> 
> This diff block is very suspecious:
> 
> @@ -16617,7 +16738,6 @@
>                  Name (_UID, One)  // _UID: Unique ID
>                  Method (_STA, 0, NotSerialized)  // _STA: Status
>                  {
> -                    Store (One, BNUM)
>                      If (And (BNUM, One))
>                      {
>                          Return (0x1F)
> 
> In your customized DSDT, the BAT1 _STA method can be decoded as:
>                 Method (_STA, 0, NotSerialized)  // _STA: Status
>                 {
>                     Store (One, BNUM)
>                     If (And (BNUM, One))
>                     {
>                         Return (0x1F)
>                     }
> 
>                     If (LLessEqual (OSYS, 0x07D2))
>                     {
>                         Return (0x0A)
>                     }
> 
>                     Return (0x0B)
>                 }
> 
> So it will always return 0x1F and make the battery detected for Linux.
> 
> Could you try a DSDT customized kernel without this line but with others
> kept to see if the battery can still be detected?

(In reply to pangqy from comment #32)
> If not,when I hibernate to disk and resume from it,the battery is not
> detected again.I don't know why hibernate will change BNUM.

Sorry I didn't quite understand what you are talking about.
Do you mean:
If this line is not added, the battery can be detected after bootup, but it will still get lost after resuming from a hibernation?

If so, this issue is not an ACPICA interpreter issue.

Let's look at the BNUM.  BNUM is located in the GVNS.
    OperationRegion (GNVS, SystemMemory, 0xDBA3EC18, 0x02B1)
    Field (GNVS, AnyAcc, Lock, Preserve)
    {
        Offset (0x1E), 
        BNUM,   8, 
        B1SC,   16, 
        B1SF,   16, 
        B1SS,   8
    }
According to your boot log, GVNS is an ACPI NVS storage:
[    0.000000] BIOS-e820: [mem 0x00000000db508000-0x00000000dba40fff] ACPI NVS
I suppose this is an issue related to the NVS save/restore.  The GVNS is simply not restored correctly after resuming from a hibernation.

I can help to trace if BNUM is modified during this period.
I can post a debugging patch later for you to confirm.

Could you do a test on Windows? Unplug the battery after hibernation and check the battery status after resume.

Yes,win7 can detect correctly.

(In reply to Lan Tianyu from comment #34)
> Could you do a test on Windows? Unplug the battery after hibernation and
> check the battery status after resume.

(In reply to pangqy from comment #35)
> Yes,win7 can detect correctly.
> 
> (In reply to Lan Tianyu from comment #34)
> > Could you do a test on Windows? Unplug the battery after hibernation and
> > check the battery status after resume.

This is a different issue than the AE_AML_OPERAND_TYPE.
The BNUM can only be updated in EC _REG.
Linux will restore BNUM value from NVS, and never executes _REG again after hibernation.
So you'll get wrong battery status on Linux.
Now I can understand why you added the BNUM line.
Hope this is not related to the ACPICA bug you are reporting.
Let me focus on the AE_AML_OPERAND_TYPE one.
I'll try to reproduce it.

Created attachment 128371 [details]
ACPI: Add debugging support to dump BNUM after resuming.

If you want to know where BNUM has been modified.
You can try this patch and perform a hibernate/resume once.

I'll go back to the interpreter issue you've reported.

I still cannot reproduce it under simulation environment.
Could you please do the following tests for us so that I can examine more method/EC information?

1. Apply the following patches:
   attachment 127631 [details]
   attachment 128341 [details]
   attachment 128351 [details]
2. Build the kernel without DSDT customized;
3. Boot the kernel with "acpi_trace_once=\_SB_.PCI0.LPCB.H_EC.BAT1._BST";
4. Post dmesg here;

Thanks in advance.

Created attachment 128381 [details]
normal boot dmesg file

Created attachment 128391 [details]
the dmesg file after resume

I have uploaded the two dmesg output files after applying your  attachment 128371 [details] patch.
(In reply to Lv Zheng from comment #37)
> Created attachment 128371 [details]
> ACPI: Add debugging support to dump BNUM after resuming.
> 
> If you want to know where BNUM has been modified.
> You can try this patch and perform a hibernate/resume once.
> 
> I'll go back to the interpreter issue you've reported.

Can these patchs be directly applied to the linux kernel source tree?
I am using linux-3.14-rc5 now.
(In reply to Lv Zheng from comment #38)
> I still cannot reproduce it under simulation environment.
> Could you please do the following tests for us so that I can examine more
> method/EC information?
> 
> 1. Apply the following patches:
>    attachment 127631 [details]
>    attachment 128341 [details]
>    attachment 128351 [details]
> 2. Build the kernel without DSDT customized;
> 3. Boot the kernel with "acpi_trace_once=\_SB_.PCI0.LPCB.H_EC.BAT1._BST";
> 4. Post dmesg here;
> 
> Thanks in advance.

(In reply to pangqy from comment #41)
> I have uploaded the two dmesg output files after applying your  attachment
> 128371 [details] patch.
> (In reply to Lv Zheng from comment #37)
> > Created attachment 128371 [details]
> > ACPI: Add debugging support to dump BNUM after resuming.

BNUM can only be modified by:
H_EC._REG
H_EC._Q33
And the NVS save/restore.

The patch is used to help me to understand if you need the following line in battery's _STA (as what you've said in comment 32):
                    Store (One, BNUM)
The attachment 128391 [details] where hibernation is executed, the following lines are useful for me to understand what has happened to BNUM.
[    0.133252] ACPI: BNUM: [before _REG(EC)] value=0x00000000, status=0x00
[    0.193216] ACPI: BNUM: [after _REG(EC)] value=0x00000001, status=0x00
[   87.809235] ACPI: BNUM: [nvs_save] value=0x00000001, status=0x00
[   87.823433] ACPI: BNUM: [nvs_restore] value=0x00000001, status=0x00
[   89.837545] [ACPI Debug]  String [0x05] "16831"
[   89.842183] [ACPI Debug]  Integer 0x0000000000000000
The first 2 lines are related to H_EC._REG execution.
The next 2 lines are related to NVS save/restore.
The last 2 lines are related to H_EC._Q33 execution.
The BNUM is remained 0x01 after restoring NVS, and is reset to 0x00 after _Q33 EC GPE processing (which looks like an implementation for updating the battery's status).

This is not directly related to the AE_AML_OPERAND_TYPE report and seems better to be handled as a seperate bug (possibly EC opregion bug).

I'd ignore the following line when dealing with the interpreter bug you've reported in this thread:
                    Store (One, BNUM)

(In reply to pangqy from comment #42)
> Can these patchs be directly applied to the linux kernel source tree?
> I am using linux-3.14-rc5 now.
> (In reply to Lv Zheng from comment #38)
> > I still cannot reproduce it under simulation environment.
> > Could you please do the following tests for us so that I can examine more
> > method/EC information?
> > 
> > 1. Apply the following patches:
> >    attachment 127631 [details]
> >    attachment 128341 [details]
> >    attachment 128351 [details]
> > 2. Build the kernel without DSDT customized;
> > 3. Boot the kernel with "acpi_trace_once=\_SB_.PCI0.LPCB.H_EC.BAT1._BST";
> > 4. Post dmesg here;

Yes, they only contain trivial debugging lines.
I tried them for 3.14-rc5 and succeeded in applying the patches with "quilt refresh".

Created attachment 128561 [details]
ACPICA: Dispatcher: Add control method tracing once support.

The attachment 128341 [details] is not suitable for your kernel version, please use this instead.

How to patch?Isn't it the command "patch -p1 < patchfile"?
(In reply to Lv Zheng from comment #44)
> (In reply to pangqy from comment #42)
> > Can these patchs be directly applied to the linux kernel source tree?
> > I am using linux-3.14-rc5 now.
> > (In reply to Lv Zheng from comment #38)
> > > I still cannot reproduce it under simulation environment.
> > > Could you please do the following tests for us so that I can examine more
> > > method/EC information?
> > > 
> > > 1. Apply the following patches:
> > >    attachment 127631 [details]
> > >    attachment 128341 [details]
> > >    attachment 128351 [details]
> > > 2. Build the kernel without DSDT customized;
> > > 3. Boot the kernel with "acpi_trace_once=\_SB_.PCI0.LPCB.H_EC.BAT1._BST";
> > > 4. Post dmesg here;
> 
> Yes, they only contain trivial debugging lines.
> I tried them for 3.14-rc5 and succeeded in applying the patches with "quilt
> refresh".

If you failed to use the patch directly by "git am <patchfile>" or "patch", try the following steps.

1. Download the following attachments:
    attachment 127631 [details]
    attachment 128561 [details]
    attachment 128351 [details]
   And rename the patch files as:
    127631.patch
    128561.patch
    128341.patch

2. Prepare the quilt patch folder, by executing the following commands:
   # apt-get install quilt
   # cd <kernel v3.14-rc5 directory>
   # mkdir patches
   # cp <patch files> patches/
   # touch patches/series

3. Prepare the quilt patch series file:
   "# vi patches/series"
   Edit it to contain the following lines:

# begin patches/series file
127631.patch
128561.patch
128341.patch
# end patches/series file

4. Apply the patches using quilt:
   # quilt push; quilt refresh
   # quilt push; quilt refresh
   # quilt push; quilt refresh

5. Complete the rest test steps:
   Build the kernel without DSDT customized;
   Boot the kernel with "acpi_trace_once=\_SB_.PCI0.LPCB.H_EC.BAT1._BST";
   Post dmesg here.

Created attachment 128701 [details]
dmesg after applying 3 patchs

Is this the dmesg you want? First time to use quilt.Not sure whether the patches have be applied.
(In reply to Lv Zheng from comment #47)
> If you failed to use the patch directly by "git am <patchfile>" or "patch",
> try the following steps.
> 
> 1. Download the following attachments:
>     attachment 127631 [details]
>     attachment 128561 [details]
>     attachment 128351 [details]
>    And rename the patch files as:
>     127631.patch
>     128561.patch
>     128341.patch
> 
> 2. Prepare the quilt patch folder, by executing the following commands:
>    # apt-get install quilt
>    # cd <kernel v3.14-rc5 directory>
>    # mkdir patches
>    # cp <patch files> patches/
>    # touch patches/series
> 
> 3. Prepare the quilt patch series file:
>    "# vi patches/series"
>    Edit it to contain the following lines:
> 
> # begin patches/series file
> 127631.patch
> 128561.patch
> 128341.patch
> # end patches/series file
> 
> 4. Apply the patches using quilt:
>    # quilt push; quilt refresh
>    # quilt push; quilt refresh
>    # quilt push; quilt refresh
> 
> 5. Complete the rest test steps:
>    Build the kernel without DSDT customized;
>    Boot the kernel with "acpi_trace_once=\_SB_.PCI0.LPCB.H_EC.BAT1._BST";
>    Post dmesg here.

Created attachment 128711 [details]
dmesg after applying 3 patchs

(In reply to pangqy from comment #35)
> Yes,win7 can detect correctly.
> 
> (In reply to Lan Tianyu from comment #34)
> > Could you do a test on Windows? Unplug the battery after hibernation and
> > check the battery status after resume.

Ok. Thanks fro test. That means Win7 shows battery is absent, right?

I will attach debug patch and please have a try without customized DSDT. 

BTW, does the issue take place during S2RAM?

Created attachment 128721 [details]
ec.patch

(In reply to pangqy from comment #50)
> Created attachment 128711 [details]
> dmesg after applying 3 patchs

Hi, it seems the patch is not applied.
Since you should have this in your dmesg output if it was applied:
[    0.000000] ACPI: Trace once is enabled for _SB_.PCI0.LPCB.H_EC.BAT1._BST

And it seems you are facing the same issue as the following reporter:
https://bugzilla.kernel.org/show_bug.cgi?id=70891

So you might need same workaround patch.
Let me post the modified test steps later in this thread.

Here is the test step for kernel v3.14-rc5:

1. Please apply the following patches:
    attachment 127631 [details]
    attachment 128561 [details]
    attachment 128351 [details]
    attachment 128751 [details]
2. Build the kernel without DSDT customized;
3. Boot the kernel with "acpi_trace_once=_SB_.PCI0.LPCB.H_EC.BAT1._BST";
4. Post dmesg here;

Thanks in advance.

(In reply to Lan Tianyu from comment #52)
> Created attachment 128721 [details]
> ec.patch

Hi, Tianyu

I think the "EC _REG not executed after resuming" or "BNUM cannot be set properly after a _Q33 execution" are different issues than the reportered interpreter one.

In order not to confuse people who are reading this thread, should we start another threads to track these issues?

Created attachment 128771 [details]
dmesg after applying 4 patchs

Have done it.
(In reply to Lv Zheng from comment #54)
> Here is the test step for kernel v3.14-rc5:
> 
> 1. Please apply the following patches:
>     attachment 127631 [details]
>     attachment 128561 [details]
>     attachment 128351 [details]
>     attachment 128751 [details]
> 2. Build the kernel without DSDT customized;
> 3. Boot the kernel with "acpi_trace_once=_SB_.PCI0.LPCB.H_EC.BAT1._BST";
> 4. Post dmesg here;
> 
> Thanks in advance.

Created attachment 128781 [details]
dmesg with ec.patch

Yes,Win7 has no problem.
I don't like S2RAM and even not enable the kernel support.So I don't know.
By the way, I have applied your ec.patch and upload the dmesg as attachment 128781 [details]. 
(In reply to Lan Tianyu from comment #51)
> (In reply to pangqy from comment #35)
> > Yes,win7 can detect correctly.
> > 
> > (In reply to Lan Tianyu from comment #34)
> > > Could you do a test on Windows? Unplug the battery after hibernation and
> > > check the battery status after resume.
> 
> Ok. Thanks fro test. That means Win7 shows battery is absent, right?
> 
> I will attach debug patch and please have a try without customized DSDT. 
> 
> BTW, does the issue take place during S2RAM?

(In reply to pangqy from comment #59)
> Yes,Win7 has no problem.
> I don't like S2RAM and even not enable the kernel support.So I don't know.
> By the way, I have applied your ec.patch and upload the dmesg as attachment
> 128781 [details]. 

The battery status with my debug patch is still not correct after hibernation?

(In reply to pangqy from comment #57)
> Have done it.

Hi, I checked the dmesg, we now had:

[    6.600600] ACPI: Begin method [0xffff880199041c18:\_SB_.PCI0.LPCB.H_EC.BAT1._BST] execution.
[    6.600602] ACPI: Tracing once enabled: ffff880199041c18:_SB_.PCI0.LPCB.H_EC.BAT1._BST
[    6.600617] ACPI Error: Needed type [Reference], found [Integer] ffff880196b34630 (20131218/exresop-103)
[    6.600620] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [And] (20131218/dswexec-461)
[    6.600623] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.H_EC.BAT1._BST] (Node ffff880199042cf8), AE_AML_OPERAND_TYPE (20131218/psparse-536)
[    6.600628] ACPI: Tracing once disabled: ffff880199041c18
[    6.600629] ACPI: End method [0xffff880199041c18] execution.
[    6.600631] ACPI Exception: AE_AML_OPERAND_TYPE, Evaluating _BST (20131218/battery-472)

We didn't get any ECRD(RefOf(B1ST)) stuff, so we didn't obtain more information than the previous dmesg.

The _BST can be simplified as:
DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I", 0x00000028)
{
    Scope (_SB)
    {
        Device (PCI0)
        {
            Device (LPCB)
            {
                Device (H_EC)
                {
                    Name (_HID, EisaId ("PNP0C09"))  // _HID: Hardware ID

                    OperationRegion (ECF2, EmbeddedControl, Zero, 0xFF)
                    Field (ECF2, ByteAcc, Lock, Preserve)
                    {
                        Offset (0x32), 
                        B1ST,   8, 
                        B1CC,   16, 
                    }

                    Method (ECRD, 1, Serialized)
                    {
                        Store (DerefOf (Arg0), Local0)
                        Return (Local0)
                    }

                    Device (BAT1)
                    {
                        Name (_HID, EisaId ("PNP0C0A"))  // _HID: Hardware ID
                        Name (_UID, One)  // _UID: Unique ID
                        Method (_STA, 0, NotSerialized)  // _STA: Status
                        {
                            Return (0x1F)
                        }

                        Method (_BST, 0, NotSerialized)  // _BST: Battery Status
                        {
                            Name (PKG1, Package (0x04)
                            {
                                0xFFFFFFFF, 
                                0xFFFFFFFF, 
                                0xFFFFFFFF, 
                                0xFFFFFFFF
                            })
                            Store (And (0x07, ECRD (RefOf (B1ST))), Index (PKG1, Zero
                                ))
                            Store (B1CC, Index (PKG1, 0x02))
                            Return (PKG1)
                        }
                    }
                }
            }
        }
    }
}
This function is pretty much simple.

I was previously thinking the first And() opcode execution has triggered the exception, but this log confused me.
The next step we may try to add AML dump and opcode debugging information to catch the issue.
I'll post the debugging patch later.

No,without customized dsdt,the battery is never detected.
(In reply to Lan Tianyu from comment #60)
> (In reply to pangqy from comment #59)
> > Yes,Win7 has no problem.
> > I don't like S2RAM and even not enable the kernel support.So I don't know.
> > By the way, I have applied your ec.patch and upload the dmesg as attachment
> > 128781 [details]. 
> 
> The battery status with my debug patch is still not correct after
> hibernation?

Yes,it is simple.I just swap the the parameters of And.The original _BST function is:
                Method (_BST, 0, NotSerialized)  // _BST: Battery Status
                {
                    Name (PKG1, Package (0x04)
                    {
                        0xFFFFFFFF, 
                        0xFFFFFFFF, 
                        0xFFFFFFFF, 
                        0xFFFFFFFF
                    })
                    Store (And (ECRD (RefOf (B1ST)), 0x07), Index (PKG1, Zero
                        ))
                    Store (B1CC, Index (PKG1, 0x02))
                    Return (PKG1)
                }

But the swap is necessary.
(In reply to Lv Zheng from comment #61)
> (In reply to pangqy from comment #57)
> > Have done it.
> 
> Hi, I checked the dmesg, we now had:
> 
> [    6.600600] ACPI: Begin method
> [0xffff880199041c18:\_SB_.PCI0.LPCB.H_EC.BAT1._BST] execution.
> [    6.600602] ACPI: Tracing once enabled:
> ffff880199041c18:_SB_.PCI0.LPCB.H_EC.BAT1._BST
> [    6.600617] ACPI Error: Needed type [Reference], found [Integer]
> ffff880196b34630 (20131218/exresop-103)
> [    6.600620] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands
> for [And] (20131218/dswexec-461)
> [    6.600623] ACPI Error: Method parse/execution failed
> [\_SB_.PCI0.LPCB.H_EC.BAT1._BST] (Node ffff880199042cf8),
> AE_AML_OPERAND_TYPE (20131218/psparse-536)
> [    6.600628] ACPI: Tracing once disabled: ffff880199041c18
> [    6.600629] ACPI: End method [0xffff880199041c18] execution.
> [    6.600631] ACPI Exception: AE_AML_OPERAND_TYPE, Evaluating _BST
> (20131218/battery-472)
> 
> We didn't get any ECRD(RefOf(B1ST)) stuff, so we didn't obtain more
> information than the previous dmesg.
> 
> The _BST can be simplified as:
> DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I", 0x00000028)
> {
>     Scope (_SB)
>     {
>         Device (PCI0)
>         {
>             Device (LPCB)
>             {
>                 Device (H_EC)
>                 {
>                     Name (_HID, EisaId ("PNP0C09"))  // _HID: Hardware ID
> 
>                     OperationRegion (ECF2, EmbeddedControl, Zero, 0xFF)
>                     Field (ECF2, ByteAcc, Lock, Preserve)
>                     {
>                         Offset (0x32), 
>                         B1ST,   8, 
>                         B1CC,   16, 
>                     }
> 
>                     Method (ECRD, 1, Serialized)
>                     {
>                         Store (DerefOf (Arg0), Local0)
>                         Return (Local0)
>                     }
> 
>                     Device (BAT1)
>                     {
>                         Name (_HID, EisaId ("PNP0C0A"))  // _HID: Hardware ID
>                         Name (_UID, One)  // _UID: Unique ID
>                         Method (_STA, 0, NotSerialized)  // _STA: Status
>                         {
>                             Return (0x1F)
>                         }
> 
>                         Method (_BST, 0, NotSerialized)  // _BST: Battery
> Status
>                         {
>                             Name (PKG1, Package (0x04)
>                             {
>                                 0xFFFFFFFF, 
>                                 0xFFFFFFFF, 
>                                 0xFFFFFFFF, 
>                                 0xFFFFFFFF
>                             })
>                             Store (And (0x07, ECRD (RefOf (B1ST))), Index
> (PKG1, Zero
>                                 ))
>                             Store (B1CC, Index (PKG1, 0x02))
>                             Return (PKG1)
>                         }
>                     }
>                 }
>             }
>         }
>     }
> }
> This function is pretty much simple.
> 
> I was previously thinking the first And() opcode execution has triggered the
> exception, but this log confused me.
> The next step we may try to add AML dump and opcode debugging information to
> catch the issue.
> I'll post the debugging patch later.

(In reply to pangqy from comment #63)
> Yes,it is simple.I just swap the the parameters of And.The original _BST
> function is:
> Method (_BST, 0, NotSerialized)  // _BST: Battery Status
> {
>     Name (PKG1, Package (0x04)
>     {
>         0xFFFFFFFF,
>         0xFFFFFFFF, 
>         0xFFFFFFFF,
>         0xFFFFFFFF
>     })
>     Store (And (ECRD (RefOf (B1ST)), 0x07), Index (PKG1, Zero))
>     Store (B1CC, Index (PKG1, 0x02))
>     Return (PKG1)
> }

Yes, I see what you've done in the customized DSDT according to the diff result in comment attachment 12761 [details].

> But the swap is necessary.

But the known opregion field reference issue should have already been fixed by the commit mentioned in comment 1.  And I actually cannot reproduce your issue using my environment.
So we need to track exactly the AML code parsed and executed in your environment.

Hi,

I think I may know what you are suffering from.
Before starting to solve it, I may still need you to upload a log to prove this.
Let me post some debugging patches later for you to address the issue.

Created attachment 129031 [details]
ACPICA: Dispatcher: Add trace support for method execution.

Debugging facility to turn on trace method for arbitrary method execution.
This is different from the acpi.trace_method_name and I rely on this facility to catch the exact execution steps of the AML code.

Created attachment 129041 [details]
ACPICA: Parser: Add trace support for opcode execution.

This is used to catch opcode execution.

Created attachment 129051 [details]
ACPICA: Dispatcher: Add trace support for object type checking.

ACPICA has a hack behaviour possibly for slack mode compliance.
Your issue seems to relate to this behaviour.

Created attachment 129061 [details]
ACPICA: Events: Add tracing support for region accesses.

This can be used to track EC opregion accesses.

Created attachment 129071 [details]
ACPICA: Workaround to match method where backslash cannot be specified by the bootloader.

This patch is not required, but seems to be useful for your grub.

Here is the test request:

1. Please apply the following patches:
    attachment 129031 [details]
    attachment 129041 [details]
    attachment 129051 [details]
    attachment 129061 [details]
    attachment 129071 [details]
2. Build the kernel without DSDT customized;
3. Boot the kernel with "acpi.debug_layer=0x000000E4 acpi.debug_level=0x00000010 acpi_trace_once=_SB_.PCI0.LPCB.H_EC.BAT1._BST";
4. Post dmesg here.

Thanks in advance.

Created attachment 129091 [details]
dmesg after applying 5 patchs

Have done it.
(In reply to Lv Zheng from comment #71)
> Here is the test request:
> 
> 1. Please apply the following patches:
>     attachment 129031 [details]
>     attachment 129041 [details]
>     attachment 129051 [details]
>     attachment 129061 [details]
>     attachment 129071 [details]
> 2. Build the kernel without DSDT customized;
> 3. Boot the kernel with "acpi.debug_layer=0x000000E4
> acpi.debug_level=0x00000010 acpi_trace_once=_SB_.PCI0.LPCB.H_EC.BAT1._BST";
> 4. Post dmesg here.
> 
> Thanks in advance.

OK, Thanks.

I'll check the following log entries:

[    6.448520]  dsmethod-0218 ds_begin_method_execut: Begin method [0xffff880199044ca8:\_SB_.PCI0.LPCB.H_EC.BAT1._BST] execution.
[    6.448522]  dsmethod-0225 ds_begin_method_execut: Tracing once enabled: ffff880199044ca8:_SB_.PCI0.LPCB.H_EC.BAT1._BST.
[    6.448529]  dsmethod-0180 ds_dump_aml           : AML[0x00000043]: 08 50 4B 47 31 12 16 04 0C FF FF FF FF 0C FF FF FF FF 0C FF FF FF FF 0C FF FF FF FF 70 7B 45 43 52 44 71 42 31 53 54 0A 07 00 88 50 4B 47 31 00 00 70 42 31 43 43 88 50 4B 47 31 0A 02 00 A4 50 4B 47 31.
[    6.448534]    psloop-0506 ps_parse_loop         : Begin opcode: Name[0x00000000] Class=0x03, Type=0x17, Flags=0x13c0.
[    6.448538]    psloop-0506 ps_parse_loop         : Begin opcode: Package[0x00000005] Class=0x01, Type=0x12, Flags=0x3020.
[    6.448541]    psloop-0506 ps_parse_loop         : Begin opcode: DwordConst[0x00000008] Class=0x02, Type=0x0b, Flags=0x2000.
[    6.448546]   psparse-0154 ps_complete_this_op   : End opcode: DwordConst[0x00000008].
[    6.448547]    psloop-0506 ps_parse_loop         : Begin opcode: DwordConst[0x0000000d] Class=0x02, Type=0x0b, Flags=0x2000.
[    6.448549]   psparse-0154 ps_complete_this_op   : End opcode: DwordConst[0x0000000d].
[    6.448551]    psloop-0506 ps_parse_loop         : Begin opcode: DwordConst[0x00000012] Class=0x02, Type=0x0b, Flags=0x2000.
[    6.448553]   psparse-0154 ps_complete_this_op   : End opcode: DwordConst[0x00000012].
[    6.448555]    psloop-0506 ps_parse_loop         : Begin opcode: DwordConst[0x00000017] Class=0x02, Type=0x0b, Flags=0x2000.
[    6.448557]   psparse-0154 ps_complete_this_op   : End opcode: DwordConst[0x00000017].
[    6.448563]   psparse-0154 ps_complete_this_op   : End opcode: Package[0x00000005].
[    6.448566]   psparse-0154 ps_complete_this_op   : End opcode: Name[0x00000000].
[    6.448569]    psloop-0506 ps_parse_loop         : Begin opcode: Store[0x0000001c] Class=0x00, Type=0x04, Flags=0x1c00.
[    6.448572]    psloop-0506 ps_parse_loop         : Begin opcode: And[0x0000001d] Class=0x00, Type=0x07, Flags=0x3c04.
[    6.448576]    psloop-0506 ps_parse_loop         : Begin opcode: -NamePath-[0x0000001e] Class=0x02, Type=0x0b, Flags=0x0280.
[    6.448583]   psparse-0154 ps_complete_this_op   : End opcode: -NamePath-[0x0000001e].
[    6.448586]    psloop-0506 ps_parse_loop         : Begin opcode: RefOf[0x00000022] Class=0x00, Type=0x02, Flags=0x1400.
[    6.448591]   psparse-0154 ps_complete_this_op   : End opcode: RefOf[0x00000022].
[    6.448593]    psloop-0506 ps_parse_loop         : Begin opcode: ByteConst[0x00000027] Class=0x02, Type=0x0b, Flags=0x2000.
[    6.448595]   psparse-0154 ps_complete_this_op   : End opcode: ByteConst[0x00000027].
[    6.448597]   exresop-0091 ex_check_object_type  : TypeNeeded=0x14, ThisType=0x01, Flags=0x0000.
[    6.448599] ACPI Error: Needed type [Reference], found [Integer] ffff880194e39090 (20131218/exresop-111)
[    6.448602] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [And] (20131218/dswexec-461)
[    6.448604]   psparse-0154 ps_complete_this_op   : End opcode: And[0x0000001d].
[    6.448606]   psparse-0154 ps_complete_this_op   : End opcode: Store[0x0000001c].
[    6.448608] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.H_EC.BAT1._BST] (Node ffff880199046cf8), AE_AML_OPERAND_TYPE (20131218/psparse-543)
[    6.448612]  dsmethod-0733 ds_terminate_control_m: Tracing once disabled: ffff880199044ca8.
[    6.448614]  dsmethod-0737 ds_terminate_control_m: End method [0xffff880199044ca8] execution.
[    6.448617] ACPI Exception: AE_AML_OPERAND_TYPE, Evaluating _BST (20131218/battery-472)

Hi,

The AML is decoded as:

70 : StoreOp
7B : AndOp
45 43 52 44 : ECRD
71 : RefOfOp
42 31 53 54 : BIST
0A : BytePrefix
07 : 0x07
00 
88 : IndexOp
50 4B 47 31 : PKG1
00 : ZeroOp
00 :

According to your log, you have something wrong with ECRD.
[    6.448576]    psloop-0506 ps_parse_loop         : Begin opcode: -NamePath-[0x0000001e] Class=0x02, Type=0x0b, Flags=0x0280.
[    6.448583]   psparse-0154 ps_complete_this_op   : End opcode: -NamePath-[0x0000001e].

It is not resolved as method call.
The following code pieces are critical to this behaviour:
1. psobject: acpi_ps_get_aml_opcode:
    AML_CLASS_PREFIX:
     walk_state->opcode = AML_INT_NAMEPATH_OP;
     walk_state->arg_types = ARGP_NAMESTRING;
2. psloop: acpi_ps_parse_loop
    walk_state->arg_types:
     acpi_ps_get_arguments
3. psloop: acpi_ps_get_arguments
    AML_INT_NAMEPATH_OP:
     acpi_ps_get_next_namepath
4. psargs: acpi_ps_get_next_namepath
    ACPI_SUCCESS(status)
    possible_method_call
    node->type == ACPI_TYPE_METHOD:
     acpi_ps_init_op(arg, AML_INT_METHODCALL_OP);

Possibly, ECRD in your environment is not decoded as method.
Let me post the debugging patch later to find the causes on your platform.

There are 2 issues triggered on this platform.

One is about the "Return" object -> Zero Integer hack.
But this is not the cause why _BST failed on your platform as the hack should work.

The root cause on your platform is the _BTP execution.
After executing this control method, ECRD could never be executed again...

OperationRegion (ECF2, EmbeddedControl, Zero, 0xFF)
Field (ECF2, ByteAcc, Lock, Preserve)
{
    Offset (0x37), 
    B1FC,   16, 
    Offset (0x5D), 
    B1FV,   16, 
    Offset (0xDB), 
    BTP1,   8
}

Method (_BTP, 1, NotSerialized)  // _BTP: Battery Trip Point
{
    If (LAnd (LNotEqual (ECRD (RefOf (B1FC)), Zero),
              LNotEqual (ECRD (RefOf (B1FV)), Zero)))
    {
        Store (Divide (Multiply (Arg0, 0x64),
                       Divide (Multiply (ECRD (RefOf (B1FC)),
                                         ECRD (RefOf (B1FV))),
                               0x03E8,),),
               Local0)
        Add (Local0, One, Local0)
        Store (Local0, ECRD(RefOf (BTP1)))
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    }
    Return (Zero)
}

This is a known ACPICA issue.
There is a bug tracking this issue:
http://bugs.acpica.org/show_bug.cgi?id=1002
With this line, the interpreter state machine will run into mess.

Since, the Local0 is not used.
What if you only customize the DSDT with this line modified as:
        Store (ECRD(RefOf (BTP1)), Local0)
And leave other logical statements not swapped.
You should still be able to have battery properly probed.

Could you give it a try?

1. Customize DSDT with only this line (in _BTP method):
        Store (Local0, ECRD(RefOf (BTP1)))
        Note that ACPICA disassembling result might be looking like:
        Store (Local0, ECRD)
        RefOf (BTP1)
   modified to
        Store (ECRD(RefOf (BTP1)), Local0)
2. Build the kernel with this customized DSDT and the following patches applied:
    attachment 129031 [details]
    attachment 129041 [details]
    attachment 129051 [details]
    attachment 129061 [details]
    attachment 129071 [details]
3. Build the kernel without DSDT customized;
3. Boot the kernel with "acpi.debug_layer=0x000000E4 acpi.debug_level=0x00000010 acpi_trace_once=_SB_.PCI0.LPCB.H_EC.BAT1._BTP";
4. It is good to post dmesg here to see if this is the root cause of this issue.

Sorry, a mistake.

According to the original purpose of this function.

> What if you only customize the DSDT with this line modified as:
>         Store (ECRD(RefOf (BTP1)), Local0)

You might modify it to:
          Store (Local0, BTP1)

>    modified to
>         Store (ECRD(RefOf (BTP1)), Local0)

You might modify it to:
          Store (Local0, BTP1)

Created attachment 129271 [details]
ACPICA: Parser: Change argument types of Store opcode to improve compliance.

This is the linuxized fix for the known issue.

Here is another test request:

1. Please apply the following patches:
    attachment 129271 [details]
2. Build the kernel without DSDT customized;
3. Boot the kernel to see if the battery can be probed.
4. Post dmesg here.

Thanks in advance.

Yes,it works.The battery is detected.
(In reply to Lv Zheng from comment #77)
> Sorry, a mistake.
> 
> According to the original purpose of this function.
> 
> > What if you only customize the DSDT with this line modified as:
> >         Store (ECRD(RefOf (BTP1)), Local0)
> 
> You might modify it to:
>           Store (Local0, BTP1)
> 
> >    modified to
> >         Store (ECRD(RefOf (BTP1)), Local0)
> 
> You might modify it to:
>           Store (Local0, BTP1)

This works,too.But when I resume from disk,ACPI report such a error:
[    6.393027] ACPI Error: Needed type [Reference], found [Integer] ffff8800d66e7288 (20131218/exresop-103)
[    6.393031] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [Store] (20131218/dswexec-461)
[    6.393035] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.H_EC.BAT1._BTP] (Node ffff880199042d20), AE_AML_OPERAND_TYPE (20131218/psparse-536)

(In reply to Lv Zheng from comment #79)
> Here is another test request:
> 
> 1. Please apply the following patches:
>     attachment 129271 [details]
> 2. Build the kernel without DSDT customized;
> 3. Boot the kernel to see if the battery can be probed.
> 4. Post dmesg here.
> 
> Thanks in advance.

(In reply to pangqy from comment #81)
> This works,too.But when I resume from disk,ACPI report such a error:
[   
> 6.393027] ACPI Error: Needed type [Reference], found [Integer]
> ffff8800d66e7288 (20131218/exresop-103)
[    6.393031] ACPI Exception:
> AE_AML_OPERAND_TYPE, While resolving operands for [Store]
> (20131218/dswexec-461)
[    6.393035] ACPI Error: Method parse/execution
> failed [\_SB_.PCI0.LPCB.H_EC.BAT1._BTP] (Node ffff880199042d20),
> AE_AML_OPERAND_TYPE (20131218/psparse-536)

This might because the fix is just a workaround (see the patch description, it violates ACPI specification) or there is another issue in your BIOS table.

Let me first try to improve the fix.
If the final fix still cannot work for all cases, I'll start to help you by debugging the suspend/resume issue (if so, possibly you need to start another thread in order not to confuse other people who are reading this issue).

I think all problems here are root caused.

First,
Windows will allow Method invocations in a SuperName.
The workaround can fix this, but it is not correct.

Second,
Windows will not automatically dereference an argument if there is an explicit DeRefOf.
I didn't fix this.

So the test specified in comment 79 doesn't work out an successful result.
This is because the EC access to BTP1 should be write, while without fixing the second issue, it turns out to be a read access.

I'll post improved first issue fix and the fix for the second issue later.
Please wait for a while.

Thanks for the reporting and testing.

I checked the code and tried to fix.
This is a Windows compliance issue.

ACPICA interpreter seems to heavily rely on the spec defined operand types.
Though spec insists call-by-reference, ACPICA interpreter will only ensure call-by-reference for spec defined operand types; for other types, ACPICA may try to do a call-by-value.

So this bug seems not such easy to be fixed.
If we made the method invocation possible for SuperName, finally it triggered many compliance issues.
Fixing all of them requires recursive ASL unit tests.

It takes time to achieve this.  Please wait until further reports.

OK,thank you very much.
(In reply to Lv Zheng from comment #84)
> I checked the code and tried to fix.
> This is a Windows compliance issue.
> 
> ACPICA interpreter seems to heavily rely on the spec defined operand types.
> Though spec insists call-by-reference, ACPICA interpreter will only ensure
> call-by-reference for spec defined operand types; for other types, ACPICA
> may try to do a call-by-value.
> 
> So this bug seems not such easy to be fixed.
> If we made the method invocation possible for SuperName, finally it
> triggered many compliance issues.
> Fixing all of them requires recursive ASL unit tests.
> 
> It takes time to achieve this.  Please wait until further reports.

Lv, as we've identified this is an ACPICA issue, and there is already a bug report in bugs.acpica.org.
This bug is closed and we will track the issue there.

What happened in linux-4.5? Seems no ACPI error reported. But wrong battery detected.

gentoo@localhost ~ $ dmesg |grep ACPI
[    0.000000] BIOS-e820: [mem 0x00000000cab4b000-0x00000000cab51fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000db508000-0x00000000dba40fff] ACPI NVS
[    0.000000] efi:  ESRT=0xdbf7b918  ACPI 2.0=0xdba12000  ACPI=0xdba12000  SMBIOS=0xf04c0  MPS=0xfd470 
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000DBA12000 000024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 0x00000000DBA12098 0000AC (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: FACP 0x00000000DBA21DC8 00010C (v05 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 0x00000000DBA121D8 00FBE9 (v02 ALASKA A M I    00000028 INTL 20120711)
[    0.000000] ACPI: FACS 0x00000000DBA3F080 000040
[    0.000000] ACPI: APIC 0x00000000DBA21ED8 000092 (v03 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: FPDT 0x00000000DBA21F70 000044 (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: LPIT 0x00000000DBA21FB8 00005C (v01 ALASKA A M I    00000000 AMI. 00000005)
[    0.000000] ACPI: SSDT 0x00000000DBA22018 000228 (v01 INTEL  sensrhub 00000000 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000DBA22240 00018F (v01 Intel  zpodd    00001000 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000DBA223D0 000539 (v01 PmRef  Cpu0Ist  00003000 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000DBA22910 000AD8 (v01 PmRef  CpuPm    00003000 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000DBA233E8 0002DE (v01 PmRef  Cpu0Tst  00003000 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000DBA236C8 000348 (v01 PmRef  ApTst    00003000 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000DBA23A10 0001C7 (v01 PmRef  LakeTiny 00003000 INTL 20120711)
[    0.000000] ACPI: MCFG 0x00000000DBA23BD8 00003C (v01 ALASKA A M I    01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 0x00000000DBA23C18 000038 (v01 ALASKA A M I    01072009 AMI. 00000005)
[    0.000000] ACPI: SSDT 0x00000000DBA23C50 000315 (v01 SataRe SataTabl 00001000 INTL 20120711)
[    0.000000] ACPI: SSDT 0x00000000DBA23F68 003364 (v01 SaSsdt SaSsdt   00003000 INTL 20091112)
[    0.000000] ACPI: ECDT 0x00000000DBA272D0 0000C1 (v01 ALASKA A M I    01072009 AMI. 00000005)
[    0.000000] ACPI: BGRT 0x00000000DBA27398 000038 (v00 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: PM-Timer IO Port: 0x1808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000029] ACPI: Core revision 20160108
[    0.012538] ACPI: 10 ACPI AML tables successfully acquired and loaded
[    0.058503] PM: Registering ACPI NVS region [mem 0xcab4b000-0xcab51fff] (28672 bytes)
[    0.058507] PM: Registering ACPI NVS region [mem 0xdb508000-0xdba40fff] (5476352 bytes)
[    0.068000] ACPI: bus type PCI registered
[    0.068003] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.075231] ACPI: Added _OSI(Module Device)
[    0.075234] ACPI: Added _OSI(Processor Device)
[    0.075236] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.075239] ACPI: Added _OSI(Processor Aggregator Device)
[    0.075341] ACPI : EC: EC description table is found, configuring boot EC
[    0.075349] ACPI : EC: EC started
[    0.077882] ACPI: Executed 2 blocks of module-level executable AML code
[    0.080891] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[    0.081594] ACPI: Dynamic OEM Table Load:
[    0.081600] ACPI: SSDT 0xFFFF880197E3FC00 0003D3 (v01 PmRef  Cpu0Cst  00003001 INTL 20120711)
[    0.082202] ACPI: Dynamic OEM Table Load:
[    0.082206] ACPI: SSDT 0xFFFF880197E42800 0005AA (v01 PmRef  ApIst    00003000 INTL 20120711)
[    0.082840] ACPI: Dynamic OEM Table Load:
[    0.082844] ACPI: SSDT 0xFFFF880197EA1200 000119 (v01 PmRef  ApCst    00003000 INTL 20120711)
[    0.084461] ACPI: Interpreter enabled
[    0.084472] ACPI: (supports S0 S4 S5)
[    0.084474] ACPI: Using IOAPIC for interrupt routing
[    0.084495] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.091384] acpi ABCD0000:00: ACPI dock station (docks/bays count: 1)
[    0.093305] ACPI: Power Resource [FN00] (off)
[    0.093364] ACPI: Power Resource [FN01] (off)
[    0.093420] ACPI: Power Resource [FN02] (off)
[    0.093476] ACPI: Power Resource [FN03] (off)
[    0.093535] ACPI: Power Resource [FN04] (off)
[    0.094213] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e])
[    0.095617] pci 0000:00:14.0: System wakeup disabled by ACPI
[    0.095922] pci 0000:00:1a.0: System wakeup disabled by ACPI
[    0.096059] pci 0000:00:1b.0: System wakeup disabled by ACPI
[    0.096217] pci 0000:00:1c.0: System wakeup disabled by ACPI
[    0.096371] pci 0000:00:1c.1: System wakeup disabled by ACPI
[    0.096524] pci 0000:00:1c.2: System wakeup disabled by ACPI
[    0.096696] pci 0000:00:1d.0: System wakeup disabled by ACPI
[    0.097357] pci 0000:02:00.0: System wakeup disabled by ACPI
[    0.099280] pci 0000:03:00.0: System wakeup disabled by ACPI
[    0.102115] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.102176] ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 10 11 12 14 15)
[    0.102222] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 *4 5 6 10 11 12 14 15)
[    0.102268] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15)
[    0.102313] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    0.102359] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    0.102406] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 10 11 12 14 15)
[    0.102450] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.102697] ACPI: Enabled 5 GPEs in block 00 to 3F
[    0.102793] ACPI : EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[    0.102977] PCI: Using ACPI for IRQ routing
[    0.108863] pnp: PnP ACPI init
[    0.108919] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active)
[    0.109078] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.109093] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.109129] system 00:03: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active)
[    0.109171] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.109198] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 (active)
[    0.109233] pnp 00:06: Plug and Play ACPI device, IDs PNP0f03 (active)
[    0.109268] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.109348] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.109811] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.110084] pnp: PnP ACPI: found 10 devices
[    0.126733] ACPI: Power Button [PWRB]
[    0.128410] ACPI: Lid Switch [LID0]
[    0.128498] ACPI: Power Button [PWRF]
[    0.184305] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[    0.494132] ata6.00: ACPI cmd ef/10:06:00:00:00:00 (unknown) succeeded
[    0.494134] ata6.00: ACPI cmd f5/00:00:00:00:00:00 (unknown) filtered out
[    0.494135] ata6.00: ACPI cmd b1/c1:00:00:00:00:00 (unknown) filtered out
[    0.495155] ata6.00: ACPI cmd ef/10:06:00:00:00:00 (unknown) succeeded
[    0.495156] ata6.00: ACPI cmd f5/00:00:00:00:00:00 (unknown) filtered out
[    0.495157] ata6.00: ACPI cmd b1/c1:00:00:00:00:00 (unknown) filtered out
[    1.966296] ACPI: AC Adapter [ADP1] (on-line)
[    1.966347] ACPI: Battery Slot [BAT1] (battery absent)
[    1.977483] ACPI Warning: SystemIO range 0x000000000000F040-0x000000000000F05F conflicts with OpRegion 0x000000000000F040-0x000000000000F04F (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255)
[    1.977489] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    1.980069] ACPI: bus type USB registered
[    2.004239] ACPI: Thermal Zone [TZ00] (51 C)
[    2.028284] ACPI: Thermal Zone [TZ01] (5 C)
gentoo@localhost ~ $