Created attachment 214831 [details]
acpidump output

Created attachment 214841 [details]
acpidump -z output

Created attachment 214851 [details]
acpidump -b output

https://bugzilla.kernel.org/show_bug.cgi?id=85881 seems also be related

Created attachment 214861 [details]
copy of /sys/firmware/dmi/tables/DMI

I attached a copy of /sys/firmware/dmi/tables/DMI since running "sudo dmidecode" gives the following error:

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.4 present.
45 structures occupying 2597 bytes.
Table at 0x7AD14000.

mmap: Can't map beyond end of file /sys/firmware/dmi/tables/DMI
Table is unreachable, sorry.

(dmidecode version 3.0)

        Method (_L06, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
        {
            If ((\_SB.PCI0.IGPU.GSSE && !GSMI))
            {
                \_SB.PCI0.IGPU.GSCI ()
            }
            Else
            {
                \_SB.PCI0.IGPU.GEFC = 0x00
                SCIS = 0x01
                \_SB.PCI0.IGPU.GSSE = 0x00
                \_SB.PCI0.IGPU.SCIE = 0x00
            }
        }

GPE 06 seems to be display related:

           Device (IGPU)
            {
                Name (_ADR, 0x00020000)  // _ADR: Address
                OperationRegion (GFXH, PCI_Config, 0x00, 0x40)
                Field (GFXH, ByteAcc, NoLock, Preserve)
                {
                    VID0,   16,
                    DID0,   16
                }

                Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If ((Arg0 == ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
                    {
                        If (((VID0 & 0xFFFF) != 0xFFFF))
                        {
                            Local0 = Package (0x02)
                                {
                                    "hda-gfx",
                                    Buffer (0x0A)
                                    {
                                        "onboard-1"
                                    }
                                }
                            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                            Return (Local0)
                        }
                    }

                    Return (0x00)
                }
....

just for grins... what happens if you boot with "acpi_osi="
(and later, when the patch is upstream to allow it, "acpi_osi=!Darwin" )

Created attachment 214991 [details]
Output of the "grep . -r /sys/firmware/acpi/interrupts" command

Created attachment 215011 [details]
Output of "sudo perf record -g -a sleep 10"

@Len: thank you for your quick reply.

- If I boot with "acpi_osi=" nothing seems to change

- I also attached the output of "grep . -r /sys/firmware/acpi/interrupts/" to make sure I didn't accidentally omit relevant details (for example both "interrupts/sci" and "interrupts/gpe_all" are also high in addition to "interrupts/gpe06" but I assumed they were some kind of "totals" perhaps)

- I also attached the output of "sudo perf record -g -a sleep 10".

- I worked around the issue by putting this in my root crontab:
@reboot echo disable > /sys/firmware/acpi/interrupts/gpe06

Is that possible for you to download this git repo:

https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next

# git clone git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
# git checkout linux-next

And try to boot the kernel with acpi_osi=!Darwin?

Thanks and best regards
-Lv

We posted the GPE flooding preventsion code on the ACPI mailinglist.
https://patchwork.kernel.org/patch/9099221/
https://patchwork.kernel.org/patch/9099251/
https://patchwork.kernel.org/patch/9099271/
Please apply them and try acpi_block_gpe=0x06

Our strategy is not to introduce DMI based quirks into kernel, but facilitate users with the command line.
Because such kind of flooding normally indicates a gap in the kernel.
Such quirks will grow endlessly if we start to make quirks for unknown gaps.

Thanks
-Lv

*** Bug 105781 has been marked as a duplicate of this bug. ***

*** Bug 105491 has been marked as a duplicate of this bug. ***

Is it acpi.block_gpe=0x00 or acpi_block_gpe=0x00? The former is written in the patch and latter is written here in the bug report.

Another question, can you tell in which kernel version this will be included?

Both of the patches (the boot parameter part) were not upstreamed.
For now, you can only do this during runtime IMO.
After booting, "echo mask > /sys/firmware/acpi/interrupts/gpeX".
Which may not be convenient for the distribution vendors to provide boot quirks.

Thanks
Lv

(In reply to Gökçen Eraslan from comment #14)
> Is it acpi.block_gpe=0x00 or acpi_block_gpe=0x00? The former is written in
> the patch and latter is written here in the bug report.

Should be acpi_block_gpe=0x00.
The patch really contains problems in the comments...

Thanks
Lv

I don't think this is RESOLVED/CODE_FIX. I'm experiencing the problem with 4.9.0-rc6, and Lv Zheng's patches did not go upstream. Please reopen.

It's not closed.
It's still on my radar as long as the status of the bug is not "closed".

I'll try to re-submit the last patch after doing necessary cleanup on it.
I failed to obtain the feedback about why Rafael disliked this patch, so I may still fail to achieve the final version he expects.
However I'll try again.

Thanks
Lv

Submitted here:
https://patchwork.kernel.org/patch/9465793/
Let's wait for Rafael's review.

Thanks and best regards
Lv

Refreshed patch according changed Documentation structure, enhanced it with enhanced declarators and patch description:
https://patchwork.kernel.org/patch/9477259/

Any news? Is this now merged to the kernel?

Doesn't it make more sense to mark it as IN_PROGRESS? It's RESOLVED when the fix is in upstream.

Closing as:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9c4aa1eecb48cfac18ed5e3aca9d9ae58fbafc11

No platform quirks will be upstreamed, you can use kernel boot parameters for your platforms. Example of using this mechanism:
 acpi_mask_gpe=0x06

Thanks
Lv