Most recent kernel where this bug did not occur: NA Distribution: Gentoo Hardware Environment: Quanta KN1 based notebook (915GM/PM, nvidia gf 6600) Software Environment: Gentoo / 2.6.15 Problem Description: Most ACPI functionality seem to run fine except when an external monitor is connected. All procs freeze, and syslog is spammed with: "ACPI Error (evgpe-0688): No handler or method for GPE[17], disabling event [20060127]" Whenever the monitor is disconnected, the kernel resumes normal operation. I tried rewriting the DSDT to the best of my (very limited) knowledge. Got rid of the 4 errors, but this did not affect the issue. DSDT original (in hex format) can be found at this url: http://www.stoneinnovation.no/zicada/dsdt.hex
Tried commenting out any gfx handling code i could find in the dsdt,- did not affect issue. Tried commenting out the acpi error handler in evgpe.c,- this stopped syslog from getting spammed,- but as soon as the monitor was connected, the system was beeing slowed down, and the temp was rising (temperature up debugmsg in dmesg). Linux reported 0 load as this was occuring. It seems to me that the evgpe.c code is unsuccessful in disabling the gpe[17] event,- yet there is no output to dmesg on this beeing attempted. Race condition issue ? I can supply logfile outputs and output from other tools when i get home later on today if needed.
Created attachment 7580 [details] Original DSDT Added the original DSDT.
There is no _L17 or _E17 method in the DSDT, so this GPE will probably not be handled. It should be disabled after this, though. Please post the acpidump for the machine, the FADT contains the GPE info.
Created attachment 7581 [details] ACPIdump Added acpidump output
entire dmesg would help also
Created attachment 7582 [details] Dmesg output Added complete dmesg output.
Created attachment 7583 [details] lspci -vv output Added lspci -vv output.
Tried adding a dummy _L17 GPE doing nothing. This gets rid of the errors, but loads the cpu quite heavily if the external monitor is connected.
I can't discover how the GPE 0x17 is being enabled. You may have to enable debug tracing during ACPI initialization so we can see what GPEs are being enabled, and why.
Need trace or we will close this.
Please reopen this bug if: - it is still present in kernel 2.6.17 and - you can provide the requested information.
Distribution: Kubuntu Hardware Environment: same: Quanta KN1 based notebook, Geforce Go 6600 Software Environment: Kubuntu / 2.6.17-11, also tested with newest stable version (2.6.20.1) error is still present when connecting an external monitor: [ 239.460000] ACPI Error (evgpe-0711): No handler or method for GPE[17], disabling event [20060707] loops until monitor is disconnected. Since I'm pretty new to linux (but learning fast and willing to help ;-)) if you tell me how to enable debug tracing during acpi initialization, I'll deliver the trace. thanks for your help.
Created attachment 10639 [details] cat /proc/acpi/debug_level okay, hope I did it right: I compiled kernel 2.6.20.1 with config_acpi_debug=y. This attachment shows the activated debug_level. Please tell me if I have to enable other debug options as well.
Created attachment 10640 [details] dmesg | grep ACPI (after restarting computer without external monitor attached). ACPI_DEBUG information should be in there. Please remember I'm new to this and just trying to provide the right information.
Created attachment 10641 [details] /var/log/messages /var/log/messages after rebooting the machine (without external monitor plugged) I plugged the ext. monitor and the looping error message popped up (no event handler).
Hi, Manuel, Do you still have this problem in the latest kernel release, say 2.6.23.1? Can you please do the following test in the latest kernel: echo 0x04 >/sys/module/acpi/parameters/debug_layer echo 0x8800001f > /sys/module/acpi/paramters/debug_level connect the external monitor and attach the dmesg output.
Created attachment 13358 [details] patch: disable gpe if no handler exists From the acpidump you attached, CRTC and CRTS in the PMIO OpRegion stands for the status and enable bit of the gpe 0x17. GPE 0x17 is enabled in the PCI0._INI method. And it is never disabled again even if no gpe handler exists for this gpe. This patch disables the gpe if no handler for this gpe is detected.
Created attachment 13654 [details] patch vs 2.6.24-rc2 This version of Rui's patch is applied to the ACPI tree.
Thomas, Manuel, It would be great if one of you could confirm that this patch fixes the problem. thanks, -Len
shipped in Linux-2.6.24-git22 closed
I'm seeing this issue in a CTL KN1 computer. I've reproduced this with the latest linux acpi git tree (1192aeb), even tried 2.6.24-git22 so I guess the problem never got fixed and the bug should be reopen. I'm willing to help with anything to debug this.
Created attachment 15599 [details] acpidump output on this machine(katie) made with acpidump 20071116
Created attachment 15600 [details] full dmesg with acpi debug features on This is the full dmesg output from the mentioned kernel (built from acpi git tree) configured with oldconfig from a 2.6.24 from debian sid .config and with the acpi debug enabled. After the boot I plugged the monitor for a second.
Created attachment 15601 [details] proposed patch I think I found it. The problem seems to be in checking if the GPE that was fired is enabled before disabling it in acpi_ev_disable_gpe() and even returning AE_OK in that case. So I removed the check making it always disable the requested GPE, which should be OK IIUC. This indeed fix the problem leaving only one "ACPI Error (evgpe-0710): No handler or method for GPE[17], disabling event [20070126]" message in the logs and preventing the IRQ storm. I've also tried moving the acpi_ev_update_gpe_enable_masks call before the check but didn't make any difference, so I think this is the way to go. Unless there is a better reason to leave the check there.
hah, patch is already available for upstream kernel, please refer to http://marc.info/?l=linux-acpi&m=120511546326164&w=2 and https://bugzilla.redhat.com/show_bug.cgi?id=251744 thanks for your effort, Damian, :)
patch in comment #24 shipped in Linux-2.6.25-git16 commit 51ae796f7fa1d8034252628572053f477bc29913 Author: Damián Viano <des@debian.org> Date: Tue Apr 29 03:32:25 2008 -0400 ACPICA: always disable GPE when requested acpi_ev_disable_gpe() has an optimization where it doesn't disable a GPE that it "doesn't have to". Unfortunately, it can get tricked by AML that scribbles on register state behind its back. So when asked to disable a GPE, simply do it -- a redundant register write in the common case is a fair price to pay to be bomb-proof for the rare cases. http://bugzilla.kernel.org/show_bug.cgi?id=6217 Signed-off-by: Damián Viano <des@debian.org> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
17 June 2008. Implemented another change for the GPE disable. We now perform a read-change-write of the enable register instead of simply writing out the cached enable mask. This will prevent inadvertent enabling of GPEs if a rogue GPE is received during initialization (before GPE handlers are installed.)
Created attachment 16595 [details] patch mentioned at comment #27
re: patch in comment #28 scripts/checkpatch.pl ERROR: trailing whitespace #41: FILE: drivers/acpi/events/evgpe.c:281: + $ ERROR: code indent should use tabs where possible #42: FILE: drivers/acpi/events/evgpe.c:282: + ^I/*$ ERROR: code indent should use tabs where possible #43: FILE: drivers/acpi/events/evgpe.c:283: + ^I * Even if we don't know the GPE type, make sure that we always$ ERROR: code indent should use tabs where possible #44: FILE: drivers/acpi/events/evgpe.c:284: + ^I * disable it. low_disable_gpe will just clear the enable bit for this$ ERROR: code indent should use tabs where possible #45: FILE: drivers/acpi/events/evgpe.c:285: + ^I * GPE and write it. It will not write out the current GPE enable mask,$ WARNING: line over 80 characters #46: FILE: drivers/acpi/events/evgpe.c:286: + * since this may inadvertently enable GPEs too early, if a rogue GPE has ERROR: code indent should use tabs where possible #46: FILE: drivers/acpi/events/evgpe.c:286: + ^I * since this may inadvertently enable GPEs too early, if a rogue GPE has$ ERROR: code indent should use tabs where possible #47: FILE: drivers/acpi/events/evgpe.c:287: + ^I * come in during ACPICA initialization - possibly as a result of AML or$ ERROR: code indent should use tabs where possible #48: FILE: drivers/acpi/events/evgpe.c:288: + ^I * other code that has enabled the GPE.$ ERROR: code indent should use tabs where possible #49: FILE: drivers/acpi/events/evgpe.c:289: + ^I */$ ERROR: code indent should use tabs where possible #50: FILE: drivers/acpi/events/evgpe.c:290: + ^Istatus = acpi_hw_low_disable_gpe(gpe_event_info);$ ERROR: code indent should use tabs where possible #51: FILE: drivers/acpi/events/evgpe.c:291: + ^Ireturn_ACPI_STATUS(status);$ WARNING: braces {} are not necessary for single statement blocks #82: FILE: drivers/acpi/hardware/hwgpe.c:77: + if (!gpe_register_info) { + return (AE_NOT_EXIST); + } ERROR: return is not a function, parentheses are not required #83: FILE: drivers/acpi/hardware/hwgpe.c:78: + return (AE_NOT_EXIST); WARNING: braces {} are not necessary for single statement blocks #90: FILE: drivers/acpi/hardware/hwgpe.c:85: + if (ACPI_FAILURE(status)) { + return (status); + } ERROR: return is not a function, parentheses are not required #91: FILE: drivers/acpi/hardware/hwgpe.c:86: + return (status); ERROR: return is not a function, parentheses are not required #106: FILE: drivers/acpi/hardware/hwgpe.c:101: + return (status); ERROR: "foo * bar" should be "foo *bar" #119: FILE: drivers/acpi/hardware/hwgpe.c:119: +acpi_hw_write_gpe_enable_reg(struct acpi_gpe_event_info * gpe_event_info) total: 15 errors, 3 warnings, 103 lines checked
whelp, git am --whitespace=strip fixed 11 of the whitespace errors, we'll get the rest when we lindent ACPICA. applied to acpi-test
in Linus' tree as commit e38e8a0743b0e996a8a3fbea8908fe75a84f02c7