From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:10:58 2009 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 919521065674; Thu, 26 Mar 2009 15:10:58 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0D58FC21; Thu, 26 Mar 2009 15:10:58 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id E61DC19017; Thu, 26 Mar 2009 15:10:56 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 26 Mar 2009 15:10:56 +0000 (GMT) Date: Thu, 26 Mar 2009 15:10:35 +0000 From: Bruce Cran To: Andriy Gapon Message-ID: <20090326151035.51e4196e@gluon.draftnet> In-Reply-To: <49CB9973.3010306@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, John Baldwin 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 List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 15:10:59 -0000 On Thu, 26 Mar 2009 17:04:19 +0200 Andriy Gapon wrote: > on 26/03/2009 16:41 Bruce Cran said the following: > > I added lots of printfs to acpi_cpu.c and found that it's occuring > > in acpi_cpu_startup; initializing it to 3 in that function (which I > > wrongly assumed was the lowest Cx state supported in ACPI) fixed > > the problem on my Athlon XP PC because the generic cx handling code > > then lowered cpu_cx_count to 1 based on the fact that > > sc->cpu_cx_count was also 1. > > > > Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in > early exits from it. So, sc->cpu_cx_count is always set to at least > 1, but if we exit via one of the returns before the end of function, > then global cpu_cx_count is never updated. > Exactly: acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 acpi_cpu_generic_cx_probe if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 So we're hitting an early exit in acpi_cpu_generic_cx_probe. -- Bruce Cran