From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 19 21:43:00 2012 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 3B794106564A; Tue, 19 Jun 2012 21:43:00 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id D74F68FC18; Tue, 19 Jun 2012 21:42:59 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q5JLggjt090221; Tue, 19 Jun 2012 14:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1340142163; bh=2okPJml7Tf+/SK6L5Z+8tXk5kFlrI29w2Gdv4yQVi5I=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=wfs63A0X9UQAl7n4icLre3nKPaF/2YXwarR3h6zyHsmRZ3RrHHM/1NgxBU3yltwhW bY/QJAgDPLOfpggciGMq6wMDCVRSSo/253fuzW7duXDtRR2tAN+Xp3oxBJ7YPS4Drb 9gVB16iMJMRsCzULG2fZcCQnR5lNLmu+fNY8ErPA= From: Sean Bruno To: Andriy Gapon In-Reply-To: <4FE0EA24.6000906@FreeBSD.org> References: <1340121728.5203.8.camel@powernoodle> <4FE0EA24.6000906@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Jun 2012 14:42:42 -0700 Message-ID: <1340142162.3201.12.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 142162002 Cc: "freebsd-acpi@freebsd.org" Subject: Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing. 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: Tue, 19 Jun 2012 21:43:00 -0000 On Tue, 2012-06-19 at 14:07 -0700, Andriy Gapon wrote: > on 19/06/2012 19:02 Sean Bruno said the following: > > The first impact of this behavior is to list C3 as C2 in the list of > > Cstates when you retrieve the cx_supported sysctls for the cpus. > > I do not think that this is a real problem. A cosmetic one - most likely. > Yes, most likely. Except that the code seems to think that the index of the Cstates is good enough for a comparison to value. More over, the sysctl's accept a value like "C3" and manipulate that into an index into the Cstate array without checking for the Cstate value. The impact of this patch corrects this cosmetic display issue. > > The > > second impact is that the power_profile script never drops to a valid > > Cstate when you set the economy_lowest variable in rc.conf. > > Could you please explain if this somehow follows from your first observation and > how? > If not, could you please share your finding on what exactly causes this to happen? > > Also, are we talking about a laptop here? Namely, judging from the reference to > 'economy_lowest', are AC state changes in play? > No, what I was attempting to do was configure a server such that it would attempt to use the C3 state at idle. Since the server gets configured by the power_state scripts via devd, the server is never configured with its global cx_lowest as anything other than C1. e.g: -bash-4.2$ sysctl -a|grep cx_lowest hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.1.cx_lowest: C1 -bash-4.2$ sysctl -a|grep cx_supported dev.cpu.0.cx_supported: C1/1 C2/96 dev.cpu.1.cx_supported: C1/1 C2/96 It seems that the rc.conf value of performance_cx_lowest="LOW" is what I really want, not economy_cx_lowest. Sean