From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 6 18:53:09 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 271EC412; Tue, 6 Nov 2012 18:53:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4FB8FC16; Tue, 6 Nov 2012 18:53:07 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA24459; Tue, 06 Nov 2012 20:53:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50995C8F.3040309@FreeBSD.org> Date: Tue, 06 Nov 2012 20:53:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:53:09 -0000 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