From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:14:28 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 6ACB110656D5 for ; Thu, 26 Mar 2009 15:14:28 +0000 (UTC) (envelope-from sepotvin@FreeBSD.org) Received: from zerofail.com (gatekeeper1.zerofail.com [208.71.11.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6568FC29 for ; Thu, 26 Mar 2009 15:14:27 +0000 (UTC) (envelope-from sepotvin@FreeBSD.org) Received: from telcobridges.com by freebsd.org (zerofail.com) (SecurityGateway 1.1.4) with SMTP id SG002296242.MSG for ; Thu, 26 Mar 2009 11:04:18 -0400 Received: from leia.telcobridges.lan ([208.94.105.59]) by telcobridges.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 11:04:18 -0400 Message-ID: <49CB9972.4030502@FreeBSD.org> Date: Thu, 26 Mar 2009 11:04:18 -0400 From: "Stephane E. Potvin" Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: John Baldwin References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> <200903261050.51602.jhb@freebsd.org> In-Reply-To: <200903261050.51602.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2009 15:04:18.0836 (UTC) FILETIME=[23239540:01C9AE24] X-SGHeloLookup-Result: hardfail smtp.helo=telcobridges.com (does not match 208.71.8.41) X-SGOP-RefID: str=0001.0A090205.49CB9973.007F,ss=1,fgs=0 (_st=1 _vt=0 _iwf=0) Cc: =?ISO-8859-1?Q?Daniel_Dvor=28=E1k?= , freebsd-acpi@freebsd.org 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:14:29 -0000 John Baldwin wrote: > On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: >> On Thu, 26 Mar 2009 09:37:50 -0400 >> John Baldwin wrote: >> >>> No, the code is doing things differently on purpose (though I'm not >>> completely sure why). For _CST it sets cpu_cx_count to the maximum >>> Cx level supported by any CPU in the system. For non-_CST it sets it >>> to the maximum Cx level supported by all CPUs in the system. I think >>> it is correct for cpu_cx_count to always start at 0 and only be >>> bumped up to a higher setting. Setting it to 3 would be very wrong >>> for the _CST case as I've seen CPUs that support C4. >> From briefly reading through the specifications I'd assumed the maximum >> power state was C3. > > For the non _CST case that is all that is defined, yes. However, _CST is a > variable length array of Cx states, so it can support arbitrary numbers of > states. > >> I had thought the _CST block was wrong because in >> acpi_cpu_global_cx_lowest_sysctl it validates the new value against >> cpu_cx_count; if one CPU has a lower cx state than the others, then >> won't this tell the other CPUs to use an unsupported state? > > It depends on if the CPU driver is smart enough to cap requests to > sc->cpu_cx_count, though if it does presumably it would do that in the > cx_generic case as well. I'm not sure why it behaves differently for the > _CST case, but I do think it is on purpose at least rather than an accidental > bug. Perhaps Nate can chime in with why? > The intent when I added support for cx states on SMP systems was to use the same maximum cx_state for all CPUs when _CST is not used (cx_generic case) and to respect per-processor maximum cx_state when _CST is present and can be used. This whole piece of code is really convoluted and there's been a few errors found in it over time so I wouldn't be surprised if there were some still lurking. Could you send me privately a copy of your ASL and a verbose boot log? Steph