Comment 108 for bug 89860

I have seen this problem with an Intel Classmate running Ubuntu 10.04 LTS (2.6.32-36 kernel) and also when using a stock kernel (2.6.32.59) which enabled me to do ACPI debugging.

It turns out that the ACPI DSDT table contains a control method _Q2A, which is repeatedly triggered by the embedded controller when automatic brightness control of the backlight is enabled (Fn+F10). This method sends repeated notifications to the kernel to adjust the brightness level, with a delay. These notifications queue up inside the kernel and cause long delays in dispatch of other notifications, such as LID events.

You can see this happening if you build a kernel with the following options:

CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y

and then run the following commands:

/etc/init.d/rsyslog stop
echo '0x00000004' | sudo tee /sys/module/acpi/parameters/debug_layer
echo '0x00000004' | sudo tee /sys/module/acpi/parameters/debug_level
echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo egrep '(push query execution|ev_queue_notify_reques)' /proc/kmsg

This will show you 0x2a (_Q2A) events being constantly triggered by the embedded controller:

<7>[ 380.985859] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[ 380.996304] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**)
<4>[ 380.996331] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 83) node f70152b8
<4>[ 381.008269] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**)
<4>[ 381.008295] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 93) node f70152b8
<7>[ 381.084229] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[ 381.120283] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**)
<4>[ 381.120310] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 83) node f70152b8
<4>[ 381.132316] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**)
<4>[ 381.132342] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 93) node f70152b8

Once you press Fn+F7 to stop the automatic brightness control, the Notify queue slowly empties. LID events go to the back of the queue and so they can be executed much later when the queue is full.

It's made worse because the kernel doesn't have a driver for the Notify events (FNBT, 83 and 93) sent by the _Q2A control method, so it doesn't adjust the brightness at all, so next time the EC triggers the _Q2A control method it runs for just as long. If the kernel did adjust the brightness, the next _Q2A would do nothing.

Something similar may be happening in your case and delaying the reception of the LID events that you actually want. You might want to trace all of ACPI instead of just ec.c, since any _E or _L control method could be causing the delay, not just the embedded controller. If you see a long delay between:

<7>[ 380.985859] acpi:ACPI: EC: push query execution (0x??) on queue

when you close the lid, and:

<4>[ 1064.570281] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [LID_] Node f7018060 Value 0x80 (**Device Specific**)

that means that the ACPI interpreter is busy doing something else (which maybe you can't see yet) instead of executing the Notify for the LID event.

These web pages are useful references:

* https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
* http://www.mjmwired.net/kernel/Documentation/acpi/method-customizing.txt
* http://www.kernel.org/doc/Documentation/acpi/debug.txt (beware the verbose spew of useless messages)
* http://kernel.ubuntu.com/~cking/presentations/gpes-and-embedded-controller/EmbeddedControllerAndACPI.odp