http://bugzilla.kernel.org/show_bug.cgi?id=5534
------- Additional Comments From [EMAIL PROTECTED] 2006-04-08 03:02 ------- There has been no significant movement on this bug for months. I can only conclude that the problem is only triggered by a few very sophisticated DSDTs (the HP nx6125 among them) or has remained unrecognized on other platforms. Nonetheless it seems to me that Linux does not correctly implement the ACPI spec. Therefore, I propose a solution with the patch attached. Interpretation of control methods called in response to GPE events or Notify events is confined to one single-threaded workqueue. It is true that the AML interpreter is essentially single-threaded, because it is protected by a mutex and therefore only one kernel thread can be executing AML code at one time. However, this does NOT mean that the execution of different control methods should not overlap. The ACPI spec allows for the transfer of control between one method and another when the AML calls Sleep, Acquire, Wait etc. (see the ACPI-CA reference). The way Sleep() is implemented in Linux, it calls schedule() and transfers control to other kernel threads: but any other control method which is queued in the kacpid thread itself will not be able to run until the currently executing control method is finished. On the HP nx6125 laptop this is essential, otherwise the ACPI subsystem will block, thermal events will not be processed, and the system will overheat. http://bugzilla.kernel.org/show_bug.cgi?id=5534 So, if any of you have an nx6125, or an ACPI bug which you think may be caused by the mechanism I have described, please try this patch. This is my first attempt at a serious kernel hack, so please forgive the state of it: this is work in progress. At least it should show one approach to the problem. I'm sure it has loads of problems with respect to locking, SMP, etc. which you will point out. In order to enable the new behaviour you need to write a positive integer (e.g. 10) to /proc/acpi/poolsize. Instead of executing all the GPE and Notify handlers in the single kacpid thread, we create a pool of worker threads and hand over the work to them. These can now execute concurrently, though access to the interpreter is still serialized by the use of a mutex. The thread pool is allowed to grow dynamically up to the maximum size which is set by the user by writing an integer to /proc/acpi/poolsize. If this integer is 0 the thread pool is not used at all and the old behaviour is used. You can also read /proc/acpi/poolsize to see the maximum pool size and the currently allocated threads. There is a field "jiffies" in the thread pool entry structure which is written when a thread finishes execution of a control method. My intention is that in future this will be used to reap unused threads. Of course, the user-configurable pool size may not be necessary. We might hard-code it. Or even allow the AML to create as many threads as necessary (assuming we trust the BIOS). Peter Wainwright (P.S. not the Apache/Perl expert). (copied to linux-acpi list). ------- 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
