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:
/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.
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 ACPI_DEBUG_ FUNC_TRACE= y FUNCTION_ TRACER= y
CONFIG_
CONFIG_FTRACE=y
CONFIG_
and then run the following commands:
/etc/init.d/rsyslog stop acpi/parameters /debug_ layer acpi/parameters /debug_ level debug/dynamic_ debug/control ev_queue_ notify_ reques) ' /proc/kmsg
echo '0x00000004' | sudo tee /sys/module/
echo '0x00000004' | sudo tee /sys/module/
echo -n 'file ec.c +p' | sudo tee /sys/kernel/
sudo egrep '(push query execution|
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 notify_ reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**) notify_ reques: No notify handler for Notify (FNBT, 83) node f70152b8 notify_ reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**) notify_ reques: No notify handler for Notify (FNBT, 93) node f70152b8 notify_ reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**) notify_ reques: No notify handler for Notify (FNBT, 83) node f70152b8 notify_ reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**) notify_ reques: No notify handler for Notify (FNBT, 93) node f70152b8
<4>[ 380.996304] evmisc-0125 [07] ev_queue_
<4>[ 380.996331] evmisc-0201 [07] ev_queue_
<4>[ 381.008269] evmisc-0125 [07] ev_queue_
<4>[ 381.008295] evmisc-0201 [07] ev_queue_
<7>[ 381.084229] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[ 381.120283] evmisc-0125 [07] ev_queue_
<4>[ 381.120310] evmisc-0201 [07] ev_queue_
<4>[ 381.132316] evmisc-0125 [07] ev_queue_
<4>[ 381.132342] evmisc-0201 [07] ev_queue_
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/ ACPITricksAndTi ps www.mjmwired. net/kernel/ Documentation/ acpi/method- customizing. txt www.kernel. org/doc/ Documentation/ acpi/debug. txt (beware the verbose spew of useless messages) kernel. ubuntu. com/~cking/ presentations/ gpes-and- embedded- controller/ EmbeddedControl lerAndACPI. odp
* http://
* http://
* http://