https://bugzilla.kernel.org/show_bug.cgi?id=221451
--- Comment #5 from Daniel Gibson ([email protected]) --- Created attachment 310041 --> https://bugzilla.kernel.org/attachment.cgi?id=310041&action=edit make acpi_ex_release_mutex() print backtraces if thread releases mutex it doesn't own In addition to all the suggestions that were made: Can you attach your ACPI tables? And also more logs, maybe all kernel and gsd-power-related stuff from journalctl starting shortly before the suspend until the reset. Also check the log at next boot, could be it logged some information about the reset. > During this time, the _Q92 event fires, fails to acquire the lock that's > being held by gsd-power, and panics. The log lines you posted don't support this theory: > Apr 29 14:56:18 nox kernel: ACPI Error: Thread 504246464 cannot release Mutex > [ECMT] acquired by thread 226623488 (20250807/exmutex-378) This means that the mutex was aquired in one thread (226623488), but a different thread (504246464) is trying to *release* it now. This should not happen. It might mean that the ACPI code of the current thread (504246464) is buggy and only releases the mutex but never acquired it? OTOH, then it should fail every time, just with a different error (AE_AML_MUTEX_NOT_ACQUIRED) if the mutex is not currently held by another thread. This error is from acpi_ex_release_mutex() in drivers/acpi/acpica/exmutex.c, around line 380. Would be interesting to see the backtraces of both involved threads; I attached a patch that should print them. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
