On Thu, 2008-08-07 at 14:30 -0700, Moore, Robert wrote: > Yes, we lock the interpreter for major parts of control method execution > in order to implement the multithreading model of the ACPI > specification. > > Here are a couple of sections from the ACPICA programmer reference that > explain the ACPICA multithreading, control method execution, reentrancy, > etc. Thanks for the lengthy response. > 3.3.2.1 Control Method Blocking > First of all, how can a control method block? This is a fairly > exhaustive list of the possibilities: > 1. Executes the Sleep() ASL opcode > 2. Executes the Acquire() ASL opcode and the request cannot be > immediately satisfied > 3. Executes the Wait() ASL opcode and the request cannot be > immediately satisfied > 4. Attempts to acquire the Global Lock (via Operation Region > access, etc), but must wait > 5. Attempts to execute a control method that is serialized and > already executing (or is blocked), or has reached its concurrency limit > 6. Invokes the host debugger via a write to the debug object or > executes the BreakPoint() ASL opcode > 7. Accesses an Operation Region which results in a dispatch to a > user-installed handler that blocks on I/O or other long-term operation > 8. A Notify AML opcode results in a dispatch to a user-installed > handler that blocks in a similar way Ok .. Well it looks like the deadlock that lockdep is warning on is fixed with #2 or #3 .. If you release the interpreter before sleeping on an Acquire() ASL opcode then you "fix" the deadlock that could happen by having different locking orders of the interpreter lock with other mutexes. I'm not sure how to train lockdep to understand this tho , Ingo? Peter? you guys have any thoughts? I assume it's not safe to remove the interpreter lock given the text that you quoted? Daniel -- 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
