(Added back the CC list.) I don't think the problem is in the machine specific ACPI info .. As far as I can tell the problem is related to how the interpreter lock is interleaved with the AML mutexes . For example, a series of AML locks can be A->B->C and at any point the interpreter lock can be released, and reacquired. So you have a possible lock sequence of I->A->B->C , then in another path you have A->I->B->C. That creates a circular lock scenario and with multiple threads in those different paths you could end up with a deadlock (or a lockdep warning). I was also reading the ACPI spec on how the ASL compiler does checking on mutex usage similar to what lockdep is doing. I would hope there are no lockdep warning coming from that code. 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
