Bug 6217

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