From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 8 10:39:23 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 043B81065672 for ; Sun, 8 Jul 2012 10:39:23 +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 52BD68FC08 for ; Sun, 8 Jul 2012 10:39:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA22949 for ; Sun, 08 Jul 2012 13:39:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Snotc-000GuB-OV for freebsd-acpi@FreeBSD.org; Sun, 08 Jul 2012 13:39:20 +0300 Message-ID: <4FF96357.1030601@FreeBSD.org> Date: Sun, 08 Jul 2012 13:39:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: "freebsd-acpi@freebsd.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: safe acpi_cpu_idle disabling X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 10:39:23 -0000 I would like to propose the following patch for your review: http://people.freebsd.org/~avg/acpi_cpu_disable_idle.diff The main purpose of this change is to provide safe interaction between acpi_cpu_idle and dynamic C-state changes by disabling acpi_cpu_idle while C-state data is updated. If my understanding is correct, currently there is no mutual protection between acpi_cpu_idle code and acpi_cpu_cx_cst. The code more or less works by never cleaning up old C-state data, so it is still accessible while the two functions have incoherent views. There still could be problems when acpi_cpu_idle expects C-state data at certain index to belong to one type while acpi_cpu_cx_cst changes it to a different type. P.S. I think that cpu_disable_idle should be made per-CPU (go to acpi_cpu softc). -- Andriy Gapon