This seems similar to #53071 and #25412, however it is on a different GPE and still occurring.
- A CPU core is 80-90% pegged with kworker:
12772 root 20 0 0 0 0 R 84,1 0,0 15:37.79 kworker/0:6
- When doing grep . -r /sys/firmware/acpi/interrupts/ I see a lot of interrupts on gpe06:
- Disabling gpe06 frees up the core without any noticeable side-effects:
# echo disable > /sys/firmware/acpi/interrupts/gpe06
Created attachment 214831 [details]
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.GEFC = 0x00
SCIS = 0x01
\_SB.PCI0.IGPU.GSSE = 0x00
\_SB.PCI0.IGPU.SCIE = 0x00
GPE 06 seems to be display related:
Name (_ADR, 0x00020000) // _ADR: Address
OperationRegion (GFXH, PCI_Config, 0x00, 0x40)
Field (GFXH, ByteAcc, NoLock, Preserve)
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
If ((Arg0 == ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
If (((VID0 & 0xFFFF) != 0xFFFF))
Local0 = Package (0x02)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
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:
# 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
We posted the GPE flooding preventsion code on the ACPI mailinglist.
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.
*** 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.
(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...
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.
Let's wait for Rafael's review.
Thanks and best regards
Refreshed patch according changed Documentation structure, enhanced it with enhanced declarators and patch description:
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.
No platform quirks will be upstreamed, you can use kernel boot parameters for your platforms. Example of using this mechanism: