Bug 114811 - ACPI Error: No handler or method for GPE N, disabling event (20160108/evgpe-790) - AMD A8-4500M APU - Lenovo E145
Summary: ACPI Error: No handler or method for GPE N, disabling event (20160108/evgpe-7...
Status: CLOSED DUPLICATE of bug 114201
Alias: None
Product: Drivers
Classification: Unclassified
Component: Watchdog (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_watchdog@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-16 21:18 UTC by Alexander Konotop
Modified: 2016-04-13 06:16 UTC (History)
5 users (show)

See Also:
Kernel Version: 4.5
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
acpidump (696.89 KB, text/plain)
2016-03-16 21:18 UTC, Alexander Konotop
Details
systemd journal (59.75 KB, text/plain)
2016-03-23 14:51 UTC, Sergej Starikov
Details
acpidump Lenovo E145 (394.27 KB, text/plain)
2016-03-23 14:52 UTC, Sergej Starikov
Details
lspci -vvnn on Lenovo Edge E145 (30.41 KB, text/plain)
2016-03-30 23:36 UTC, Sergej Starikov
Details

Description Alexander Konotop 2016-03-16 21:18:02 UTC
Created attachment 209491 [details]
acpidump

My system doesn't boot normally with 4.5 kernel.
It prints the message:

ACPI Error: No handler or method for GPE N, disabling event (20160108/evgpe-790)

continiously so that systemd journald eats 100% of one cpu core and dmesg is not readable.

The "N" number after "GPE" loops continiously through these values:
00 01 05 10 13 14 15 16 17

The hardware is HP 4535s notebook with AMD A4 APU. Tried updating BIOS to the latest version - it didn't give any results.

The distro is siduction (almost debian sid, I've tried both siduction(release) and debian(RC7) kernels - they behave equally).

If I don't propagate the "quiet" param to the kernel - the log message stream will be so solid that the system won't boot at all.

I'm able to boot without any problems if I propagate acpi=off, but then ACPI features, such as CPU frequency scaling, don't work of course.

The 4.2.3 kernel is working nicely in my case.

acpidump output is completely equal in 4.5 and 4.2.3 - I've attached it.
Comment 1 Stefan Schmid 2016-03-23 11:07:51 UTC
I am also affected by this error.
Upgrading from 4.4.x to 4.5.

Screenshot of the Kernel Log in rescue mode under systemd:
https://drive.google.com/file/d/0B3pmY9R_R3jqamJ6d2owMmpZQ2M/view

Distribution: Gentoo Linux
Kernel: =sys-kernel/vanilla-sources-4.5.0
GCC: 4.9.3
glibc: 2.21
Comment 2 Stefan Schmid 2016-03-23 11:12:51 UTC
additional information:
System: ThinkPad Edge E545
http://support.lenovo.com/ch/de/products/laptops-and-netbooks/thinkpad-edge-laptops/thinkpad-edge-e545/20b2/000kmz
Firmware: BIOS/UEFI 1.13 (HRET25WW)  ECP 1.13 (HRHT25WW)  2015/08/12
Comment 3 Sergej Starikov 2016-03-23 13:57:11 UTC
I also run into this with 4.5 kernel.

Distribution: Arch Linux with linux-4.5.
CPU: AMD A4-5000 APU with Radeon(TM) HD 8330 Graphics
Laptop Model: ThinkPad Edge E145
BIOS Version: HSET56WW (2.01 ), 11/20/2013

Journal with said ACPI Errors at the bottom: http://pastebin.com/raw/pRuVpEhL
acpidump: http://pastebin.com/raw/xTcm7yuj
Comment 4 Sergej Starikov 2016-03-23 14:51:04 UTC
Created attachment 210451 [details]
systemd journal
Comment 5 Sergej Starikov 2016-03-23 14:52:00 UTC
Created attachment 210461 [details]
acpidump Lenovo E145
Comment 6 Len Brown 2016-03-28 23:21:32 UTC
Did this work in a kernel before 4.5?
If yes, what is the latest kernel that works?
Can you bit bisect to see what caused this failure?
Comment 7 Sergej Starikov 2016-03-30 23:36:27 UTC
Created attachment 211181 [details]
lspci -vvnn on Lenovo Edge E145

On Arch Linux stable kernel version 4.4.5 the bug does not occur, on all versions above 4.5-rc1 i get the buggy behaviour.

I did a git bisect from tag v4.4 to tag v4.5-rc1. The resulting first bad commit is bdecfcd :
> commit bdecfcdb5461834aab24002bb18d3cbdd907b7fb
> Author: Huang Rui <ray.huang@amd.com>
> Date:   Mon Nov 23 18:07:35 2015 +0800
> 
>     sp5100_tco: fix the device check for SB800 and later chipsets
>    
>     For SB800 and later chipsets, the register definitions are the same
>     with SB800. And for SB700 and older chipsets, the definitions should
>     be same with SP5100/SB7x0.
By its very nature, the parent of this commit does not cause the bug.

The attached lspci output of my machine shows that i have a chipset that is covered by the module sp5100_tco.
In fact, on 4.5 kernels this module gets loaded, while on 4.4.5 it does not.
On 4.4.5 kernel:
> $> uname -a
> Linux godot 4.4.5-1-custom #1 SMP PREEMPT Tue Mar 22 00:15:20 CET 2016 x86_64
> GNU/Linux
> $> sudo lspci -vvnn |grep '4385\|780b\|790b\|sp5100'
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:780b] (rev 3a)
> $> lsmod | grep sp5100
> (empty)
> $> grep sp5100 /lib/modules/4.4.5-1-custom/modules.dep
> kernel/drivers/watchdog/sp5100_tco.ko.gz:

On 4.5 kernel:
> $> uname -a
> Linux godot 4.5.0-1-custom45 #1 SMP PREEMPT Wed Mar 23 10:31:35 CET 2016
> x86_64 GNU/Linux
> $> sudo lspci -vvnn |grep '4385\|780b\|790b\|sp5100'
> 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
> [1022:780b] (rev 3a)
>       Kernel modules: i2c_piix4, sp5100_tco
> $> lsmod |grep sp5100
> sp5100_tco             16384  0

On "shutdown +0" the module even prints an error shortly before the system halts, something like
> sp5100_tcp: Unexpected close, not stopping watchdog!
Comment 8 Lv Zheng 2016-03-31 05:26:59 UTC
Same results are debugged out from another bug (bug 114201).
Please refer to it.
Comment 9 Alexander Konotop 2016-03-31 08:05:53 UTC
My APU is AMD A4 3300M, if it matters.
Comment 10 Lv Zheng 2016-04-05 05:14:49 UTC
Please report this bug to bug 114201.
Let me mark it as duplicate and close.

*** This bug has been marked as a duplicate of bug 114201 ***
Comment 11 Lv Zheng 2016-04-13 06:16:30 UTC
Closing, please track it in 114201.

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