From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:37:53 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 2B21B106564A; Thu, 26 Mar 2009 14:37:53 +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 D9F8D8FC19; Thu, 26 Mar 2009 14:37:52 +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 A5F0119017; Thu, 26 Mar 2009 14:37:51 +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 14:37:51 +0000 (GMT) Date: Thu, 26 Mar 2009 14:37:31 +0000 From: Bruce Cran To: John Baldwin Message-ID: <20090326143731.0d2b7711@gluon.draftnet> In-Reply-To: <200903260937.51028.jhb@freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <200903260937.51028.jhb@freebsd.org> 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: quoted-printable Cc: Daniel =?utf-8?Q?Dvo=C5=99=C3=A1k?= , 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 14:37:53 -0000 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. =46rom briefly reading through the specifications I'd assumed the maximum power state was C3. =20 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? --=20 Bruce Cran