From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:04:27 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 252BC10657DF; Thu, 26 Mar 2009 15:04:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE968FC22; Thu, 26 Mar 2009 15:04:24 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 RAA28791; Thu, 26 Mar 2009 17:04:20 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CB9973.3010306@icyb.net.ua> Date: Thu, 26 Mar 2009 17:04:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Bruce Cran 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> In-Reply-To: <20090326144140.2203c0d8@gluon.draftnet> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 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:04:28 -0000 on 26/03/2009 16:41 Bruce Cran said the following: > On Thu, 26 Mar 2009 16:33:08 +0200 > Andriy Gapon wrote: > >> on 26/03/2009 16:28 Bruce Cran said the following: >>> On Thu, 26 Mar 2009 16:09:10 +0200 >>> Andriy Gapon wrote: >>>> If you specifically mean the generic case (non-cst) as you mention >>>> in the PR, then I think that you didn't notice that cpu_cx_count >>>> (the global variable) gets updated in acpi_cpu_generic_cx_probe, >>>> So after looping over all CPUs it has the value of the maximum Cx >>>> level supported by at least one CPU. Only then we loop again and >>>> determine the smallest of the supported maximums. >>> Yes, I had missed that. I think the problem however is still that >>> in the generic cx case the global is re-initialized to 0 and never >>> gets updated. >> It would be interesting to catch where/when this happens if this is >> indeed the case. >> > > 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. -- Andriy Gapon