http://bugzilla.kernel.org/show_bug.cgi?id=5534
------- Additional Comments From [EMAIL PROTECTED] 2006-03-04 01:23 ------- OK, I had another look at this this morning. I think I understand most of it. All of this refers to the nx6125 BIOS version F.0D and linux kernel 2.6.16-rc5. In addition to the GPE and Notify events, the thermal zone polling (_TZP) is also done from the same single threaded workqueue. This explains why enabling TZP does not solve the problem. Once the _L19 control method is entered it blocks processing of all other events. However, the userspace workaround "watch acpi -t" (or "watch cat /proc/acpi/thermal_zone/*/temperature") works, because it forces action immediately without queueing it on the kacpid workqueue. Reading the temperature sensor status bits has the effect of clearing them, so on the next loop _L19 returns, and then the Notify events get processed. I do not fully understand the quote from the ACPI spec in comment 65, nor this from the ACPI CA Programmer's Reference: "Because of the constraints of the ACPI specification, there is a major limitation on the concurrency that can be achieved within the AML interpreter portion of the subsystem. The specification states that at most one control method can be actually executing AML code at any given time. If a control method blocks (an event that can occur only under a few limited conditions), another method may begin execution. However, ???it can be said that the specification precludes the concurrent execution of control methods???. Therefore, the AML interpreter itself is essentially a single-threaded component of the ACPI subsystem. Serialization of both internal and external requests for execution of control methods is performed and managed by the front-end of the interpreter." However, the DSDT for the HP nx6125 seems to expect a cooperative multithreading model in which one control method can relinquish control using Sleep() and wait for another to complete. I am not a computer scientist, but a mathematical physicist and part time system administrator. I hope my analysis will be useful to someone, but I don't have the time or the skills to take this further. It would be helpful to have some comment from the people who wrote the ACPI spec (HP/Intel/MS/Phoenix/Toshiba) as to what level of concurrency is really expected from the OS. P.S. I notice that acpi_os_queue_for_execution() takes a "priority" argument which is unused. What is the intention of this? So, I am relinquishing control here and hoping someone else will run: Sleep(100000000....) ------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
