From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 16:06:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E714C106564A; Sun, 12 Sep 2010 16:06:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 14D818FC12; Sun, 12 Sep 2010 16:06:45 +0000 (UTC) Received: by bwz20 with SMTP id 20so555039bwz.13 for ; Sun, 12 Sep 2010 09:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=X3ZUo83li3tbc3q6MlfpuTAULq8PwGFt+bPVcJdI/UY=; b=xJ2ea56B54hfEO42RGWSQXusMpRqrvsJgaP4jUp1MNevSVtbn+Us/3v1IUaG0HRvhe xKiVaOmpfeSMiDI8DW1+jOtECURjRM598htYZramyg5Ja3ToHcsVINezl4Dmh911A214 Qy8VKoyarjd7MJm6dr69GngFiop0rwbHgWNZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=LqFIkqJJLdpuakqMZGAtAIHZndGkIPeauJTYL0p4jDqYtG9jxOI0WMOwpFfvaxrEaP WrfYzArA0owTLnhiqDJuVGw4P34Tls2xxK1vx5g5hdHzALJmQFhVH3SsZFYqaOy+ScHy 2je+jUA5ZyJI9Rm7+QoTVp1OEoIy9bcgFOsOg= Received: by 10.204.76.205 with SMTP id d13mr2335335bkk.93.1284307249155; Sun, 12 Sep 2010 09:00:49 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f16sm3802503bkd.16.2010.09.12.09.00.45 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Sep 2010 09:00:47 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8CF91A.4040804@FreeBSD.org> Date: Sun, 12 Sep 2010 19:00:26 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> <4C8CF03F.1050902@icyb.net.ua> <4C8CF412.9080601@icyb.net.ua> In-Reply-To: <4C8CF412.9080601@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 16:06:47 -0000 Andriy Gapon wrote: > on 12/09/2010 18:22 Andriy Gapon said the following: >> Observations are correct, but incomplete; the conclusions are wrong. >> At the end of the boot there are message like this one: >> PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency >> This is a result of re-evaluation of _CST because of a notification from ACPI. > > But still, as you suggest, a patch like the following should be tested and > committed: > > --- a/sys/dev/acpica/acpi_cpu.c > +++ b/sys/dev/acpica/acpi_cpu.c > @@ -828,7 +828,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc) > sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported), > SBUF_FIXEDLEN); > for (i = 0; i < sc->cpu_cx_count; i++) { > - sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat); > + sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type, > + sc->cpu_cx_states[i].trans_lat); > if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) > sc->cpu_non_c3 = i; > } I am not sure this patch is complete: 1) AFAIR I have seen somewhere example where system had several C-states with different latency, but the same type - C3. Type only means enter/exit semantics, and there could be several states with the same semantics. Not sire how to properly them in this case. May be existing approach was not so bad. It is ACPI C-states, not CPU C-states, they are not same. May be we should just mention type somewhere in addition. 2) This change makes heavily understandable values of cx_lowest. 3) If touch cx_lowest, I would prefer to see there possibility to set it to some abstract C6 or whatever, allowing system automatically choose state it has available at the moment. -- Alexander Motin