Date: Tue, 06 Nov 2012 20:53:03 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Tom Lislegaard <Tom.Lislegaard@proact.no> Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource Message-ID: <50995C8F.3040309@FreeBSD.org> In-Reply-To: <E8A24BEFDC390C4491718DEE8A9C4F209220E2@Semail03.proact.local> References: <E8A24BEFDC390C4491718DEE8A9C4F2091F824@Semail03.proact.local> <509172F6.2040400@FreeBSD.org> <E8A24BEFDC390C4491718DEE8A9C4F2091FC33@Semail03.proact.local> <5092F209.7090803@FreeBSD.org> <E8A24BEFDC390C4491718DEE8A9C4F20920DD1@Semail03.proact <5093BECC.1030709@FreeBSD.org> <E8A24BEFDC390C4491718DEE8A9C4F20921BAC@Semail03.proact.local> <50979BCD.3060000@FreeBSD.org> <E8A24BEFDC390C4491718DEE8A9C4F20921C47@Semail03.proact.local> <5097CB27.8040802@FreeBSD.org> <E8A24BEFDC390C4491718DEE8A9C4F20921C6A@Semail03.proact.local> <5097F24D.7040206@FreeBSD.org> <E8A24BEFDC390C4491718DEE8A9C4F209220E2@Semail03.proact.local>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50995C8F.3040309>