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.

Created attachment 154281 [details]
all acpidump files

Created attachment 154291 [details]
mce message

Created attachment 154301 [details]
dmidecode

I've attached the acpidump files, the mce message, and dmidecode output.

Thank you for taking a look.

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

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.

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

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.

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.

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

(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.

(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.

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?

ping...

Created attachment 168541 [details]
dynamic acpi tables

Apologies, I hadn't seen your message. I've attached them now.

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?

Add Lv.

Lv, please take a look at this acpi table to decide if we need fix this iasl compiling issue.

I'll move it to ACPICA category.

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

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