on 06/11/2012 10:50 Tom Lislegaard said the following: > No problem, I'm happy to assist in debugging this. > > Enabling the acpi debugging quickly fills the kernel message buffer, but it > seems to be the same set of messages > repeating again and again so I think this is representative > > https://dl.dropbox.com/u/13263820/debug_dmesg.txt
This didn't clarify things as much as I hoped, but I am inclined to think that it is polling from userland that triggers all the processor notifications. In any case, here is a patch to try: http://people.freebsd.org/~avg/acpi_cpu-stable.diff Please disable all the tunings added to loader.conf during debugging when testing this patch. The patch is a combination of two changes: 1. Do not needlessly use ever-increasing resource IDs. Rather use the IDs that are tied to Cx level IDs. Also, release previous resources upon _CST change. 2. Bind a thread that processes a processor _CST change notification to the target processor and perform _CST processing in a critical section. These should ensure the following: - the CPU doesn't enter an idle state and doesn't try to use Cx level parameters while they are being changed - Cx level parameters are never concurrently modified when multiple notifications fire in a rapid succession and multiple ACPI task threads are configured sched_bind is a heavy-weight operation, but it is OK in this context because processor notifications should not occur too often > And, btw, thanks for your efforts. Thank you for all the excellent debugging and testing! P.S. I still believe that BIOS/ACPI on the machine behaves sub-optimally. -- Andriy Gapon _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
