From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 22:40:05 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A3AE1065672 for ; Wed, 25 Mar 2009 22:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EC1CB8FC1D for ; Wed, 25 Mar 2009 22:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2PMe4cu073658 for ; Wed, 25 Mar 2009 22:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2PMe4eZ073657; Wed, 25 Mar 2009 22:40:04 GMT (envelope-from gnats) Date: Wed, 25 Mar 2009 22:40:04 GMT Message-Id: <200903252240.n2PMe4eZ073657@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:40:05 -0000 The following reply was made to PR kern/108581; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Wed, 25 Mar 2009 22:32:16 +0000 In acpi_cpu_startup in /sys/dev/acpi_cpu.c cpu_cx_count is initialized to 0. If the generic Cx mode is being used (which it appears to be on older CPUs) then a loop is run over all the CPUs to find the highest Cx state common to all of them. However that code assumes that cpu_cx_count has been initialized too *high*, since it only sets it if it finds a CPU with a maximum Cx state lower than the current value of cpu_cx_count. This means that while setting the per-CPU cx_lowest sysctl works because it correctly gets initialized to 1 in acpi_cpu_generic_cx_probe, the global systl hw.acpi.cpu.cx_lowest always fails because it thinks there are no Cx states. Initializing cpu_cx_count to 3 instead of 0 should fix the problem. There appears to be a related bug in the _CST mode handling below; if there exists a CPU in the system which supports a higher Cx state than the others, the global cx_cpu_count will be set too high if the purpose of that sysctl is to reflect the maximum Cx state that all CPUs support. -- Bruce