Bug 86491 - Lenovo Z50: syntax error, unexpected PARSEOP_STORE
Summary: Lenovo Z50: syntax error, unexpected PARSEOP_STORE
Status: CLOSED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Lv Zheng
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-18 06:28 UTC by Tigran Gabrielyan
Modified: 2015-08-24 06:16 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.17.1
Tree: Mainline
Regression: No


Attachments
dsdt.dsl (648.76 KB, text/x-dsl)
2014-10-18 06:28 UTC, Tigran Gabrielyan
Details
all acpidump files (30.53 KB, application/gzip)
2014-10-20 18:11 UTC, Tigran Gabrielyan
Details
mce message (460 bytes, text/plain)
2014-10-20 18:19 UTC, Tigran Gabrielyan
Details
dmidecode (12.13 KB, application/octet-stream)
2014-10-20 18:19 UTC, Tigran Gabrielyan
Details
acpidumps (2.95 KB, application/gzip)
2014-10-23 06:41 UTC, Tigran Gabrielyan
Details
dynamic acpi tables (810 bytes, application/gzip)
2015-03-02 02:58 UTC, Tigran Gabrielyan
Details

Description Tigran Gabrielyan 2014-10-18 06:28:41 UTC
Created attachment 154111 [details]
dsdt.dsl

I've copied the following to a new folder:

/sys/firmware/acpi/tables/DSDT
/sys/firmware/acpi/tables/SSDT*

then exucted:

iasl -e SSDT* -d DSDT
iasl -tc DSDT.dsl

And I get:

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20140926-64 [Oct 16 2014]
Copyright (c) 2000 - 2014 Intel Corporation

Compiler aborting due to parser-detected syntax error(s)
DSDT.dsl   7123:                 Store (\_GPE.MMTB (Local2, \_GPE.OSUP (Local2)), Store (Local1, REG6) )
Error    6126 -                               syntax error, unexpected PARSEOP_STORE ^ 

DSDT.dsl   7615:                 Store (\_GPE.MMTB (Local3, \_GPE.OSUP (Local3)), Store (Local2, REG6) )
Error    6126 -                               syntax error, unexpected PARSEOP_STORE ^ 

ASL Input:     DSDT.dsl - 17642 lines, 593183 bytes, 7280 keywords
Hex Dump:      DSDT.hex - 216 bytes

Compilation complete. 2 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

Is this an issue with Lenovo BIOS?

My main concern is I get MCE events only after I resume from standby and the first error happens to be in the Method (_WAK, 1, Serialized)  // _WAK: Wake section (although I have no idea if that relates to wake from suspend).
Comment 1 David Box 2014-10-20 18:08:07 UTC
While the syntax error is real, this isn't necessarily a BIOS bug. The process for disassembling and recompiling aml isn't perfect. We will need to see the acpidump from the machine to diagnosis it further. You can do this by running 'acpidump -b' and uploading all of the dat files. Thanks.
Comment 2 Tigran Gabrielyan 2014-10-20 18:11:47 UTC
Created attachment 154281 [details]
all acpidump files
Comment 3 Tigran Gabrielyan 2014-10-20 18:19:25 UTC
Created attachment 154291 [details]
mce message
Comment 4 Tigran Gabrielyan 2014-10-20 18:19:43 UTC
Created attachment 154301 [details]
dmidecode
Comment 5 Tigran Gabrielyan 2014-10-20 18:19:57 UTC
I've attached the acpidump files, the mce message, and dmidecode output.

Thank you for taking a look.
Comment 6 David Box 2014-10-20 21:18:42 UTC
This looks like an iasl issue, not a BIOS one (as far as the cause of the syntax error). I can see from the your dsdt.dsl file that the method being exectuted (_GPE.MMTB) is external. This means it's defined in another file, usually an ssdt. But I don't see the method in any of the ssdt's in your acpidump and neither did iasl, which is why it has a warning for the method near the top of the file.

AML method calls don't indicate how many arguments the method takes. Without a definition of the method, iasl has to guess the number of arguments. You'll notice on line 37 of your dsdt that iasl guessed 2 arguments for MMTB. This is most likely incorrect. My best guess (and I could be wrong too) is that it takes no arguments and that this:

    Store (\_GPE.MMTB (Local2, \_GPE.OSUP (Local2)), Store (Local1, REG6)))

should be this on three separate lines:

    Store (\_GPE.MMTB, Local2)
    \_GPE.OSUP (Local2)
    Store (Local1, REG6)

The same would follow for the other error. The way to know for sure though is to find the method. It's possible it's in a dydnamic ssdt, but I am unaware how to decompile those. Lv, maybe you can help out here.

Dave
Comment 7 Tigran Gabrielyan 2014-10-20 23:45:36 UTC
Is it possible that an mce be caused by this issue? I ran memtest and cachebench to stress the cpu and no mce is generated, just happens on resume from standby. I just want to be sure it a software/firmware issue somewhere and not a hardware issue while this laptop is still under warranty.

Thanks a lot. Appreciate it.
Comment 8 Lv Zheng 2014-10-22 05:37:02 UTC
Hi,

David:

It might be loaded by these opcodes decoded from SSDT2:
    OperationRegion (CST0, SystemMemory,
                     DerefOf (Index (SSDT, 0x07)),
                     DerefOf (Index (SSDT, 0x08)))
    Load (CST0, HC0)
    OperationRegion (CST1, SystemMemory,
                     DerefOf (Index (SSDT, 0x0A)),
                     DerefOf (Index (SSDT, 0x0B)))
    Load (CST1, HC1)
    OperationRegion (IST1, SystemMemory,
                     DerefOf (Index (SSDT, 0x04)),
                     DerefOf (Index (SSDT, 0x05)))
    Load (IST1, HI1)
And the SSDT named object contains the table address and size:
    Name (SSDT, Package (0x0C)
    {
        "CPU0IST ", 
        0xA8630A98, 
        0x00000539, 
        "APIST   ", 
        0xAAE78618, 
        0x000005AA, 
        "CPU0CST ", 
        0xAAE78C18, 
        0x000003D3, 
        "APCST   ", 
        0xAAE77D98, 
        0x00000119
    })

tigrangab:

Did you see real issues by running Linux on such platform?
If so, you may need to do 2 things to help to confirm the root cause.

1. Please dump the above tables by the following commands:
# sudo acpidump -a 0xA8630A98
# sudo acpidump -a 0xAAE78618
# sudo acpidump -a 0xAAE78C18
# sudo acpidump -a 0xAAE77D98
And upload the dumped tables here so that we can learn if the missing methods are in those dynamic loaded tables.
You need to use the acpidump compiled from the upstream Linux kernel in tools/power/acpi or the acpidump compiled from the upstream ACPICA repo.

2. I wonder if we convert the above lines into:
    OperationRegion (CST0, SystemMemory,
                     0xAAE78C18, 0x000003D3)
    Load (CST0, HC0)
    OperationRegion (CST1, SystemMemory,
                     0xAAE77D98, 0x00000119)
    Load (CST1, HC1)
    OperationRegion (IST1, SystemMemory,
                     0xAAE78618, 0x000005AA)
    Load (IST1, HI1)
And using the customized SSDT2 through initrd override, will this still be seen?
Please refer to Documentation/acpi/initrd_table_override.txt and give this a try.

Thanks and best regards
Comment 9 Tigran Gabrielyan 2014-10-22 05:43:18 UTC
I see the machine check exceptions in my log when I resume from standby (see "mce message" attachment). It doesn't happen under Windows. If I enable the discrete nvidia card, then resuming from standby fails after the 4th or 5th time doing a suspend/resume cycle.

I'm just more concerned about the MCE even though the hardware seems to be fine (except the resuming hanging issue).

I will get you the acpidumps tomorrow.

Thank you.
Comment 10 Tigran Gabrielyan 2014-10-22 21:04:08 UTC
Interesting, I just found this http://www.linlap.com/lenovo_ideapad_z710#notes which describes the exact issue I'm having. It's a different model, but same manufacturer. At least I know I'm not alone now.

I will provide the acpidumps when I get home.
Comment 11 Tigran Gabrielyan 2014-10-23 06:41:32 UTC
Created attachment 154591 [details]
acpidumps

sudo acpidump -a 0xA8630A98 > 0xA8630A98
Cannot map /dev/mem
Could not map table header at 0x00000000A8630A98
Could not get table at 0x00000000A8630A98, AE_ACCESS
Comment 12 Lv Zheng 2014-10-23 06:52:01 UTC
(In reply to tigrangab from comment #11)
> Created attachment 154591 [details]
> acpidumps

Thanks!

> sudo acpidump -a 0xA8630A98 > 0xA8630A98
> Cannot map /dev/mem
> Could not map table header at 0x00000000A8630A98
> Could not get table at 0x00000000A8630A98, AE_ACCESS

The following entries are not used in the tables:
        "CPU0IST ", 
        0xA8630A98, 
        0x00000539,
So it makes senses that it doesn't even exist on your current configuration.

Since all tables are obtained, we may ask power experts to help.
Comment 13 Zhang Rui 2015-02-15 08:59:05 UTC
(In reply to tigrangab from comment #11)
> Created attachment 154591 [details]
> acpidumps
> 
> sudo acpidump -a 0xA8630A98 > 0xA8630A98
> Cannot map /dev/mem
> Could not map table header at 0x00000000A8630A98
> Could not get table at 0x00000000A8630A98, AE_ACCESS

why are you using acpidump -a?
I think you just need to run "acpidump > acpidump.out" with root privilege.
Comment 14 Zhang Rui 2015-02-15 09:05:52 UTC
hah, I see.
To dump the dynamic DSDT tables, why not just "cd /sys/firmware/acpi/tables/dynamic", and cat each file into a .dat file and attach them here?
Comment 15 Zhang Rui 2015-03-02 02:53:22 UTC
ping...
Comment 16 Tigran Gabrielyan 2015-03-02 02:58:20 UTC
Created attachment 168541 [details]
dynamic acpi tables
Comment 17 Tigran Gabrielyan 2015-03-02 02:58:49 UTC
Apologies, I hadn't seen your message. I've attached them now.
Comment 18 Aaron Lu 2015-08-20 09:25:37 UTC
I think there are two issues here:
1 iasl syntax error
2 MCE after wake up

I don't think MCE is caused by ASL, I would suggest you open a new bug against some CPU category, those people may have a better idea.
We can keep track the iasl syntax error issue here, if it is somehow fixable(not all syntax error is fixable). Lv, is this one fixable?
Comment 19 Aaron Lu 2015-08-20 09:26:34 UTC
Add Lv.

Lv, please take a look at this acpi table to decide if we need fix this iasl compiling issue.
Comment 20 Aaron Lu 2015-08-20 09:27:12 UTC
I'll move it to ACPICA category.
Comment 21 Lv Zheng 2015-08-24 06:15:24 UTC
Hi,

The iasl issue is not an issue.
This is a known problem in ACPI specification.
You need to use -fe to specify a external definition file.
Please also refer to the ACPICA user manual for the details.

Thanks and best regards
-Lv
Comment 22 Lv Zheng 2015-08-24 06:16:39 UTC
You'd better to use the following command line to see if this can be resolved without -fe:

iasl -e DSDT -e SSDT* -d DSDT

Thanks
-Lv

Note You need to log in before you can comment on or make changes to this bug.