http://bugzilla.kernel.org/show_bug.cgi?id=5534
------- Additional Comments From [EMAIL PROTECTED] 2006-03-01 03:20 ------- OK, I've been tearing out my remaining hair and have spent the last couple of weekends trying to track down the problem, though I knew absolutely zilch about ACPI when I started. However, here is my speculation, based on reading the DSDT, available at http://acpi.sourceforge.net/dsdt/view.php?id=558, and the kernel source. I am hoping that some kernel expert will jump in and tell me if I'm right or wrong. Asynchronous notification of thermal events is handled by a level-triggered interrupt which causes execution of the ACPI control method _L19 (defined by AML code in the DSDT). This method enters a loop which polls the temperature sensor via the SMBus (I assume this is something similar to http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2408). If the status bits of the temperature sensor indicate a trip point has been exceeded a thermal Notify() event is generated. At the end of the loop, the control method relinquishes control via a Sleep() call for 100 microseconds before polling again. In this interval, one would hope that the OS would take control and process the outstanding Notify() events. HOWEVER, as far as I can tell from the kernel source, both the _L19 interrupt and the Notify handlers are run from a single workqueue in the thread known as "kacpid". This means the Notify() events do not get processed until the _L19 method has completed. They just pile up in the queue. Presumably reading the temperature (using cat /proc/acpi/thermal_zone/*/temperature or acpi -t) causes the queue to be flushed immediately. The question is: does the DSDT or the kernel behaviour better represent the ACPI spec? According to the ACPI spec: "When a control method does block, the operating software can initiate or continue the execution of a different control method. A control method can only assume that access to global objects is exclusive for any period the control method does not block.". I take this to mean that it would be acceptable to process the thermal Notify() events as they occur, and before the interrupt handler _L19 returns. This would presumably require a separate kernel thread. Does this make sense? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
