From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 11 06:32:34 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 463EF106566B; Tue, 11 Sep 2012 06:32:34 +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 2EF7D8FC12; Tue, 11 Sep 2012 06:32:32 +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 JAA18870; Tue, 11 Sep 2012 09:32:31 +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 1TBK1P-00020O-FI; Tue, 11 Sep 2012 09:32:31 +0300 Message-ID: <504EDAFE.3000601@FreeBSD.org> Date: Tue, 11 Sep 2012 09:32:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120901 Thunderbird/15.0 MIME-Version: 1.0 To: "freebsd-acpi@freebsd.org" X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: do we always have acpi_cpu for a cpu? 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: Tue, 11 Sep 2012 06:32:34 -0000 I think that we always expect to have a one-to-one correspondence between acpi_cpu devices and actual (APIC) CPUs. acpi_pcpu_get_id() seems to even assert that, if I am reading the code correctly. The following patch adds the assert to acpi_cpu_idle as well and also removes what I believe to be an obsolete comment about HTT CPUs. acpi_cpu: expect every cpu to have a corresponding acpi_cpu object ... via Processor object in ASL namespace. diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c index 15201f9..203ed02 100644 --- a/sys/dev/acpica/acpi_cpu.c +++ b/sys/dev/acpica/acpi_cpu.c @@ -925,23 +925,15 @@ acpi_cpu_idle() uint32_t start_time, end_time; int bm_active, cx_next_idx, i; + sc = cpu_softc[PCPU_GET(cpuid)]; + KASSERT(sc != NULL, ("acpi_cpu_idle: CPU without ACPI CPU")); + /* If disabled, return immediately. */ if (cpu_disable_idle) { ACPI_ENABLE_IRQS(); return; } - /* - * Look up our CPU id to get our softc. If it's NULL, we'll use C1 - * since there is no ACPI processor object for this CPU. This occurs - * for logical CPUs in the HTT case. - */ - sc = cpu_softc[PCPU_GET(cpuid)]; - if (sc == NULL) { - acpi_cpu_c1(); - return; - } - /* Find the lowest state that has small enough latency. */ cx_next_idx = 0; if (cpu_disable_deep_sleep) -- Andriy Gapon