The ACPI specification allows concurrent execution of control methods although methods cannot be preempted. The ACPICA interpreter mutex is used to implement this model. >From section 5.5.2, "Control Method Execution": Interpretation of a Control Method is not preemptive, but it can block. 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. Therefore, the interpreter lock is acquired and a control method is allowed to execute to completion unless it blocks on one of the events described below. If the method blocks, the interpreter is unlocked and other control methods may execute. I'm not sure what you mean by "in the middle of an SMBus transaction", I don't know how long such a transaction is valid. I might guess that a single transaction can only span a single operation region access, but I'm not sure of this. A user-installed operation region handler is an operation region handler that is installed by a device driver. This feature would probably only be used for custom (OEM-defined) operation region address spaces. (I have not seen one yet.) For the standard address spaces (memory, I/O, etc.), usually only the default handlers are used. Bob > -----Original Message----- > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- > owner@xxxxxxxxxxxxxxx] On Behalf Of Jean Delvare > Sent: Monday, April 02, 2007 8:49 AM > To: Pavel Machek; Brown, Len > Cc: Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux- > acpi@xxxxxxxxxxxxxxx; linux-kernel; lm-sensors@xxxxxxxxxxxxxx > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Looking at the comment before acpi_ex_exit_interpreter raises two > questions though: > > > * Cases where the interpreter is unlocked: > > * 1) Completion of the execution of a control method > > * 2) Method blocked on a Sleep() AML opcode > > * 3) Method blocked on an Acquire() AML opcode > > * 4) Method blocked on a Wait() AML opcode > > * 5) Method blocked to acquire the global lock > > * 6) Method blocked to execute a serialized control method that is > > * already executing > > * 7) About to invoke a user-installed opregion handler > > 1* This suggests that the mutex could be released by the AML > interpreter in the middle of an SMBus transaction. If so, and if it > happens in practice, this means that we unfortunately cannot use this > mutex to reliably protect the SMBus drivers from concurrent accesses. > This even suggests that it's simply not possible to have a mutex we > take at the beginning when entering the AML interpreter and we release > when leaving the AML interpreter, as it looks like ACPI itself allows > interlaced execution of AML functions. Len, is this true? > > What is the purpose of the ACPI_MTX_INTERPRETER mutex in the first > place, given that it seems it will be released on numerous occasions? > Is it to prevent concurrent AML execution while still allowing > interlaced execution? > > 2* What are "user-installed opregion handlers"? Are they something that > could help solve the ACPI vs. other drivers problem? > > Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html