From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 00:12:55 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 9AA721065670; Sun, 12 Sep 2010 00:12:54 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 09:12:48 +0900 From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org, freebsd-acpi@FreeBSD.org Message-Id: <20100912091248.5c95bf2c.nork@FreeBSD.org> In-Reply-To: <20100912081409.9f4d74d0.nork@FreeBSD.org> References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.org> <20100912081409.9f4d74d0.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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: Sun, 12 Sep 2010 00:12:55 -0000 On Sun, 12 Sep 2010 08:14:09 +0900 Norikatsu Shigemura wrote: > According to acpidump -dt, I could find CPU0CST table, but > not found _CST. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Scope (\) > { > Name (SSDT, Package (0x0C) > { > : > "CPU0CST ", > 0xDA9AB618, > 0x000005CD, > : > }) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Hum... ACPI CA 20100806 has a bug? Humm... I wonder if CF-R9 required another initialization? I don't know what is HI0 and HC0. But default values of HI0 and HC0 is 0, and HI0 and HC0 are set CST related values by GCAP, I think.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Scope (\_PR.CPU0) { Name (HI0, Zero) Name (HC0, Zero) : Method (GCAP, 1, NotSerialized) { CreateDWordField (Arg0, Zero, STS0) CreateDWordField (Arg0, 0x04, CAP0) If (LOr (LEqual (STS0, 0x06), LEqual (STS0, 0x0A))) { Return (Zero) } If (And (STS0, One)) { And (CAP0, 0x0BFF, CAP0) Return (Zero) } Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0) If (And (CFGD, One)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (PDC0, 0x09), 0x09)), LNot (And (SDTL, One)))) { Or (SDTL, One, SDTL) OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02 ))) Load (IST0, HI0) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC0, 0x18 )), LNot (And (SDTL, 0x02)))) { Or (SDTL, 0x02, SDTL) OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08 ))) Load (CST0, HC0) } } Return (Zero) } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thank you. -- Norikatsu Shigemura From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 07:39:21 2010 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 D0A7E106566C; Sun, 12 Sep 2010 07:39:21 +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 AB6FF8FC1D; Sun, 12 Sep 2010 07:39:20 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA24172; Sun, 12 Sep 2010 10:39:16 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ouh9g-000FgF-FC; Sun, 12 Sep 2010 10:39:16 +0300 Message-ID: <4C8C83A3.9010009@icyb.net.ua> Date: Sun, 12 Sep 2010 10:39:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nate Lawson References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.org> In-Reply-To: <4C8BCAC5.5050008@root.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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: Sun, 12 Sep 2010 07:39:21 -0000 on 11/09/2010 21:30 Nate Lawson said the following: >> PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 >> PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. >> PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency > > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. > The "not available" message means that transition latency is defined too high. That is, in this case latency is greater than 100 for C2. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 08:01:21 2010 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 39B7A106564A; Sun, 12 Sep 2010 08:01:21 +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 12FF78FC1A; Sun, 12 Sep 2010 08:01:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA24343; Sun, 12 Sep 2010 11:01:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OuhUy-000Fh6-Ms; Sun, 12 Sep 2010 11:01:16 +0300 Message-ID: <4C8C88CC.5060302@icyb.net.ua> Date: Sun, 12 Sep 2010 11:01:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nate Lawson References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.org> In-Reply-To: <4C8BCAC5.5050008@root.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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: Sun, 12 Sep 2010 08:01:21 -0000 on 11/09/2010 21:30 Nate Lawson said the following: > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. >From reading of the code, C3 should be used in this case even if C2 is not available. But I think that it might get removed for a different reason: PM2_CNT_BLK length seems to be zero. With ACPI_DB_INFO enabled there should be "no BM control" message in the log. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 08:03:07 2010 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 7B8CB1065672; Sun, 12 Sep 2010 08:03:07 +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 5F6848FC14; Sun, 12 Sep 2010 08:03:06 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA24351; Sun, 12 Sep 2010 11:03:05 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OuhWi-000FhE-Pj; Sun, 12 Sep 2010 11:03:04 +0300 Message-ID: <4C8C8938.4030500@icyb.net.ua> Date: Sun, 12 Sep 2010 11:03:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Norikatsu Shigemura References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.org> <20100912081409.9f4d74d0.nork@FreeBSD.org> In-Reply-To: <20100912081409.9f4d74d0.nork@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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: Sun, 12 Sep 2010 08:03:07 -0000 on 12/09/2010 02:14 Norikatsu Shigemura said the following: > According to acpidump -dt, I could find CPU0CST table, but > not found _CST. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Scope (\) > { > Name (SSDT, Package (0x0C) > { > : > "CPU0CST ", > 0xDA9AB618, > 0x000005CD, > : > }) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Hum... ACPI CA 20100806 has a bug? How do you conclude? Does a different version work? It seems that our acpidump doesn't dump a dynamically loaded table. That the table was loaded we can see from these messages: ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 10:40:05 2010 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C930D1065670; Sun, 12 Sep 2010 10:40:05 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B99118FC17; Sun, 12 Sep 2010 10:40:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8CAe5Et041232; Sun, 12 Sep 2010 10:40:05 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8CAe5Cg041228; Sun, 12 Sep 2010 10:40:05 GMT (envelope-from brucec) Date: Sun, 12 Sep 2010 10:40:05 GMT Message-Id: <201009121040.o8CAe5Cg041228@freefall.freebsd.org> To: dk@garant.ru, brucec@FreeBSD.org, brucec@FreeBSD.org, freebsd-acpi@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported 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: Sun, 12 Sep 2010 10:40:05 -0000 Synopsis: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported State-Changed-From-To: closed->open State-Changed-By: brucec State-Changed-When: Sun Sep 12 10:35:23 UTC 2010 State-Changed-Why: This does appear to be a bug, but only in the ACPI code: Hyperthreading isn't guaranteed to give a performance increase for every workload, and TurboBoost is only seen once lower Cx states are enabled. Responsible-Changed-From-To: brucec->freebsd-acpi Responsible-Changed-By: brucec Responsible-Changed-When: Sun Sep 12 10:35:23 UTC 2010 Responsible-Changed-Why: Over to the acpi list. This appears to be a problem with ACPI on the machine, because C2 and C3 states should probably be available. http://www.freebsd.org/cgi/query-pr.cgi?pr=135447 From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 15:39:01 2010 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 98BF6106566B; Sun, 12 Sep 2010 15:39:01 +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 477308FC13; Sun, 12 Sep 2010 15:39:00 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA28410; Sun, 12 Sep 2010 18:38:58 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ouodu-000Fyv-Lm; Sun, 12 Sep 2010 18:38:58 +0300 Message-ID: <4C8CF412.9080601@icyb.net.ua> Date: Sun, 12 Sep 2010 18:38:58 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin 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> In-Reply-To: <4C8CF03F.1050902@icyb.net.ua> X-Enigmail-Version: 1.1.2 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-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: Sun, 12 Sep 2010 15:39:01 -0000 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; } P.S. I restored acpi@ cc: which I think is quite relevant, but was somehow lost. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 15:49:53 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id C24E1106566B; Sun, 12 Sep 2010 15:49:52 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Mon, 13 Sep 2010 00:49:46 +0900 From: Norikatsu Shigemura To: Andriy Gapon Message-Id: <20100913004946.6cf945a4.nork@FreeBSD.org> In-Reply-To: <4C8CF412.9080601@icyb.net.ua> 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> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current , freebsd-acpi@FreeBSD.org, nork@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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: Sun, 12 Sep 2010 15:49:53 -0000 Hi avg. On Sun, 12 Sep 2010 18:38:58 +0300 Andriy Gapon wrote: > > 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: Thank you, I'll test your patch. But I'm rebuilding another patches. So please wait next day. -- Norikatsu Shigemura From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 16:00:21 2010 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E90106566C for ; Sun, 12 Sep 2010 16:00:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 543078FC17 for ; Sun, 12 Sep 2010 16:00:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8CG0Lvq070026 for ; Sun, 12 Sep 2010 16:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8CG0KEH070006; Sun, 12 Sep 2010 16:00:20 GMT (envelope-from gnats) Date: Sun, 12 Sep 2010 16:00:20 GMT Message-Id: <201009121600.o8CG0KEH070006@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 16:00:21 -0000 The following reply was made to PR i386/135447; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, dk@garant.ru Cc: Bruce Cran Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported Date: Sun, 12 Sep 2010 18:52:14 +0300 First of all, the PR was created improperly - sysctl -a output is in "Fix" section for some reason. Please don't do that in the future. Second, it's impossible to tell if "C2 and C3 states should probably be available" unless we see acpidump -dt output and dmesg with ACPI debugging enabled (ACPI_PROCESSOR x ACPI_DB_INFO): http://www.freebsd.org/doc/handbook/acpi-debug.html P.S. That is, generally we expect to see C2 and C3 levels, but not universally. BIOS or BIOS configuration, motherboard peculiarities and OS supported features are among the thing that affect C2+ availability. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 16:25:29 2010 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 1CCA21065672 for ; Sun, 12 Sep 2010 16:25:29 +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 90C798FC12 for ; Sun, 12 Sep 2010 16:25:28 +0000 (UTC) Received: by bwz20 with SMTP id 20so565156bwz.13 for ; Sun, 12 Sep 2010 09:25:27 -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-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: Sun, 12 Sep 2010 16:25:29 -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 From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 19:13:01 2010 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 5C962106566B for ; Sun, 12 Sep 2010 19:13:01 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from april.london.02.net (april.london.02.net [87.194.255.143]) by mx1.freebsd.org (Postfix) with ESMTP id 26A078FC12 for ; Sun, 12 Sep 2010 19:13:00 +0000 (UTC) Received: from unknown (94.193.93.212) by april.london.02.net (8.5.124.10) id 4C88869300163F13 for freebsd-acpi@freebsd.org; Sun, 12 Sep 2010 20:12:59 +0100 Date: Sun, 12 Sep 2010 20:12:55 +0100 From: Bruce Cran To: freebsd-acpi@freebsd.org Message-ID: <20100912201255.0000579a@unknown> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Hang when booting with verbose ACPI debugging 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: Sun, 12 Sep 2010 19:13:01 -0000 Hi, I'm running -current from a few days ago and decided to see if I could figure out if I should be getting more Cx levels after enabling C3/C6/C7 in the BIOS. However when setting: debug.acpi.layer="ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ALL" the system hangs at the Entropy harvesting line (I know those debug settings are too much for debugging Cx support). It also hung when I booted into single-user mode and tried to list the debug.acpi sysctls. Although the system doesn't respond to keypresses, the system isn't totally locked up: pressing the power button a couple of times triggers the message that the system's not ready to switch into S5 mode. -- Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 19:28:49 2010 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 5CC931065670 for ; Sun, 12 Sep 2010 19:28:49 +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 A7D208FC14 for ; Sun, 12 Sep 2010 19:28:48 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA01233; Sun, 12 Sep 2010 22:28:42 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OusEE-000GAl-DP; Sun, 12 Sep 2010 22:28:42 +0300 Message-ID: <4C8D29E9.1030600@icyb.net.ua> Date: Sun, 12 Sep 2010 22:28:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100912 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Bruce Cran References: <20100912201255.0000579a@unknown> In-Reply-To: <20100912201255.0000579a@unknown> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Hang when booting with verbose ACPI debugging 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: Sun, 12 Sep 2010 19:28:49 -0000 on 12/09/2010 22:12 Bruce Cran said the following: > Hi, > > I'm running -current from a few days ago and decided to see if I could > figure out if I should be getting more Cx levels after enabling > C3/C6/C7 in the BIOS. However when setting: > > debug.acpi.layer="ACPI_ALL_DRIVERS" > debug.acpi.level="ACPI_LV_ALL" > > the system hangs at the Entropy harvesting line (I know those debug > settings are too much for debugging Cx support). It also hung when I > booted into single-user mode and tried to list the debug.acpi sysctls. > Although the system doesn't respond to keypresses, the system isn't > totally locked up: pressing the power button a couple of times triggers > the message that the system's not ready to switch into S5 mode. Well, can't really tell what's going on, but consider a possibility that the system is just very busy writing out all the debugging info. All in all, this needs further investigation. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 12 19:55:56 2010 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 449BC106566B for ; Sun, 12 Sep 2010 19:55:56 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from woodbine.london.02.net (woodbine.london.02.net [87.194.255.145]) by mx1.freebsd.org (Postfix) with ESMTP id 0CAA88FC0A for ; Sun, 12 Sep 2010 19:55:55 +0000 (UTC) Received: from unknown (94.193.93.212) by woodbine.london.02.net (8.5.124.10) id 4C886ABA0018B040; Sun, 12 Sep 2010 20:55:23 +0100 Date: Sun, 12 Sep 2010 20:55:21 +0100 From: Bruce Cran To: Andriy Gapon Message-ID: <20100912205521.00000d2d@unknown> In-Reply-To: <4C8D29E9.1030600@icyb.net.ua> References: <20100912201255.0000579a@unknown> <4C8D29E9.1030600@icyb.net.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Hang when booting with verbose ACPI debugging 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: Sun, 12 Sep 2010 19:55:56 -0000 On Sun, 12 Sep 2010 22:28:41 +0300 Andriy Gapon wrote: > Well, can't really tell what's going on, but consider a possibility > that the system is just very busy writing out all the debugging info. > All in all, this needs further investigation. There's no HDD activity, and I've tried waiting a couple of minutes. Also, the same lockup occurred when I replaced the ACPI_DEBUG_PRINT statements in acpi_cpu.c with printf and booted into multi-user normally. -- Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 13 11:06:49 2010 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 5262E1065694 for ; Mon, 13 Sep 2010 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 251D18FC17 for ; Mon, 13 Sep 2010 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8DB6neH001796 for ; Mon, 13 Sep 2010 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8DB6mOL001794 for freebsd-acpi@FreeBSD.org; Mon, 13 Sep 2010 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Sep 2010 11:06:48 GMT Message-Id: <201009131106.o8DB6mOL001794@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org 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: Mon, 13 Sep 2010 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o amd64/144551 acpi [acpi] ACPI issues on SuperMicro X7SPA-H o i386/144045 acpi [acpi] [panic] kernel trap with acpi enabled o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o i386/135447 acpi [i386] [request] Intel Core i7 and Nehalem-EP new feat o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode f kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o amd64/121439 acpi [boot] Installation of FreeBSD 7.0 fails: ACPI problem o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 f kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 60 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 13 17:07:44 2010 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 C118F106566B; Mon, 13 Sep 2010 17:07:44 +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 A07968FC19; Mon, 13 Sep 2010 17:07:43 +0000 (UTC) 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 UAA23459; Mon, 13 Sep 2010 20:07:42 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C8E5A5D.6000303@icyb.net.ua> Date: Mon, 13 Sep 2010 20:07:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100909 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alexander Motin 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> <4C8CF91A.4040804@FreeBSD.org> In-Reply-To: <4C8CF91A.4040804@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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: Mon, 13 Sep 2010 17:07:44 -0000 on 12/09/2010 19:00 Alexander Motin said the following: > > I am not sure this patch is complete: Well, I agree, it's far from complete. And situation is somewhat messy. > 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. ACPI specification suggests how to address this, but I am not sure if we want to follow that suggestion and how we would do that: ACPI> Notice in the example above that OSPM should anticipate the possibility of a _CST object providing more ACPI> than one entry with the same C_State_Type value. In this case OSPM must decide which C_State_Register ACPI> it will use to enter that C state. So it looks like the specification does tie C_State_Type to "C state". But then, in general, the specification looks confusing. It mentions C4, ..., Cn states; but then says that their enter/exit semantics should correspond to C1, C2, C3; but then it uses "1, 2, 3, *etc*" [emphasis mine] when it describes C State type. So, at least I am confused as to what they would designate with C4 - a state described in _CST with type of 4, or a forth state in _CST perhaps with a type of 3. And entry/exit semantics the state would have in the former case. I do not see an explicit answer in their wording. > 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. > Yes, I agree. It's just overall confusing. But you are correct that index of a C-state works better than "C-state-type" or whatever it can be called. And a user probably doesn't care much about the latter. But probably it's a good idea to report the type somewhere. I am also going to take a look how Linux and OpenSolaris name the C-states. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 14 08:56:48 2010 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 62964106566C for ; Tue, 14 Sep 2010 08:56:48 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9AC5A8FC0A for ; Tue, 14 Sep 2010 08:56:47 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA06825; Tue, 14 Sep 2010 11:44:46 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OvR8A-000MAy-6k; Tue, 14 Sep 2010 11:44:46 +0300 Message-ID: <4C8F35FD.2090603@freebsd.org> Date: Tue, 14 Sep 2010 11:44:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100912 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alexander Motin 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> <4C8CF91A.4040804@FreeBSD.org> <4C8E5A5D.6000303@icyb.net.ua> In-Reply-To: <4C8E5A5D.6000303@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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, 14 Sep 2010 08:56:48 -0000 on 13/09/2010 20:07 Andriy Gapon said the following: > I am also going to take a look how Linux and OpenSolaris name the C-states. Well, Linux does what you suggested, it uses index of a C-state as its name. There is one difference from our current code - if a C-state is skipped for some reason, then its index is not re-used, but the entry is marked as non-valid. So, if we skip "C2" for some reason, then "C3" will become "C2". Not so on Linux. Also, they print a type/class of a C state using C1, C2, C3 and "--" for higher/unknown types. Additionally, it seems that we do not currently have any support for Functional Fixed Hardware (FFH) way of providing C states. In this case _CST returns GAS of a register used to enter a C state with address space ID set to ACPI_ADR_SPACE_FIXED_HARDWARE (0x7f/127). Such addresses should be handled in a special way: ftp://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf Currently we simply (and silently) ignore such _CST entries. I think that this should be useful (if not necessary) with mwait. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 14 08:57:45 2010 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 7CD51106564A; Tue, 14 Sep 2010 08:57:45 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 866408FC17; Tue, 14 Sep 2010 08:57:44 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA07402; Tue, 14 Sep 2010 11:57:42 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OvRKg-000MBo-Au; Tue, 14 Sep 2010 11:57:42 +0300 Message-ID: <4C8F3905.5070403@freebsd.org> Date: Tue, 14 Sep 2010 11:57:41 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100912 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alexander Motin 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> <4C8CF91A.4040804@FreeBSD.org> <4C8E5A5D.6000303@icyb.net.ua> <4C8F35FD.2090603@freebsd.org> In-Reply-To: <4C8F35FD.2090603@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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, 14 Sep 2010 08:57:45 -0000 on 14/09/2010 11:44 Andriy Gapon said the following: > on 13/09/2010 20:07 Andriy Gapon said the following: >> I am also going to take a look how Linux and OpenSolaris name the C-states. > > Well, Linux does what you suggested, it uses index of a C-state as its name. > There is one difference from our current code - if a C-state is skipped for some > reason, then its index is not re-used, but the entry is marked as non-valid. > So, if we skip "C2" for some reason, then "C3" will become "C2". Not so on Linux. > Also, they print a type/class of a C state using C1, C2, C3 and "--" for > higher/unknown types. OpenSolaris, on the other hand, collapses multiple entries of the same type into a single entry using the most power-saving alternative. They also use the type as a C state reported name, index is not used in interfacing. So, hm, talk about confusing again :) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 14 09:05:09 2010 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 8179A1065670 for ; Tue, 14 Sep 2010 09:05:09 +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 02D4E8FC0C for ; Tue, 14 Sep 2010 09:05:08 +0000 (UTC) Received: by bwz15 with SMTP id 15so39060bwz.13 for ; Tue, 14 Sep 2010 02:05:07 -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=cBwG6T2eCpkWQIxP2W/BxoO6Qdva0w8565LFaoHHPt4=; b=EvW0yWDFZ5QOImfgZV05JDslFRN2lcBDuJSSgLLXvvNsvnQRIRkydDUOIkIu3llUli Y5H8+FtTYU1EAd/ripdHXrZPTCKPuyo/ElW6gA8C7SnjBbqIIiTudltLQplgfUn04sjH HDf428NQGtq0kS3EuG4Tb/fqGISo5Fyd8gW9c= 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=Tz1nrtAT1wh4kkav21WO7UG/52cbrgAVQW7JbZ1plnorwQegJLGMm1aNQlNflioODn wu18/xiQRv/Y3T8wv1asxmIxhEv60nWZlDruOvjX++pTE1pD9vlxqcTDTJopZqzXVgCz PTlge8eFmXXliYcgAE4GSP35wK+81O/05QcNY= Received: by 10.223.124.197 with SMTP id v5mr71495far.68.1284455107633; Tue, 14 Sep 2010 02:05:07 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id h12sm3289997faa.13.2010.09.14.02.05.05 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Sep 2010 02:05:06 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8F3AAE.9030001@FreeBSD.org> Date: Tue, 14 Sep 2010 12:04:46 +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> <4C8CF91A.4040804@FreeBSD.org> <4C8E5A5D.6000303@icyb.net.ua> <4C8F35FD.2090603@freebsd.org> <4C8F3905.5070403@freebsd.org> In-Reply-To: <4C8F3905.5070403@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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, 14 Sep 2010 09:05:09 -0000 Andriy Gapon wrote: > on 14/09/2010 11:44 Andriy Gapon said the following: >> on 13/09/2010 20:07 Andriy Gapon said the following: >>> I am also going to take a look how Linux and OpenSolaris name the C-states. >> Well, Linux does what you suggested, it uses index of a C-state as its name. >> There is one difference from our current code - if a C-state is skipped for some >> reason, then its index is not re-used, but the entry is marked as non-valid. >> So, if we skip "C2" for some reason, then "C3" will become "C2". Not so on Linux. >> Also, they print a type/class of a C state using C1, C2, C3 and "--" for >> higher/unknown types. > > OpenSolaris, on the other hand, collapses multiple entries of the same type into > a single entry using the most power-saving alternative. I don't think it is perfect choice. In such case it would be useless for ACPI BIOS to report extra states. The only case when I think can be reasonable to drop some items is if they are equal except using different entry methods. For example, one OS may prefer to use port read, while another may use MWAIT to be able to wake up without using IPI. > They also use the type as a C state reported name, index is not used in interfacing. In their case it is possible. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 14 16:06:57 2010 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 EDFCD1065679; Tue, 14 Sep 2010 16:06:57 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id BA8108FC08; Tue, 14 Sep 2010 16:06:57 +0000 (UTC) Received: from [10.0.5.50] (ppp-71-139-38-142.dsl.snfc21.pacbell.net [71.139.38.142]) by mail.root.org (Postfix) with ESMTP id 274405CE6; Tue, 14 Sep 2010 16:06:56 +0000 (UTC) Message-ID: <4C8F9D9F.4080704@root.org> Date: Tue, 14 Sep 2010 09:06:55 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) 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> <4C8CF91A.4040804@FreeBSD.org> <4C8E5A5D.6000303@icyb.net.ua> <4C8F35FD.2090603@freebsd.org> In-Reply-To: <4C8F35FD.2090603@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-acpi@freebsd.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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, 14 Sep 2010 16:06:58 -0000 Andriy Gapon wrote: > on 13/09/2010 20:07 Andriy Gapon said the following: >> I am also going to take a look how Linux and OpenSolaris name the C-states. > > Well, Linux does what you suggested, it uses index of a C-state as its name. > There is one difference from our current code - if a C-state is skipped for some > reason, then its index is not re-used, but the entry is marked as non-valid. > So, if we skip "C2" for some reason, then "C3" will become "C2". Not so on Linux. > Also, they print a type/class of a C state using C1, C2, C3 and "--" for > higher/unknown types. > > Additionally, it seems that we do not currently have any support for Functional > Fixed Hardware (FFH) way of providing C states. In this case _CST returns GAS > of a register used to enter a C state with address space ID set to > ACPI_ADR_SPACE_FIXED_HARDWARE (0x7f/127). Such addresses should be handled in a > special way: > ftp://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf > > Currently we simply (and silently) ignore such _CST entries. > I think that this should be useful (if not necessary) with mwait. I added some FFHW support for ACPI P-states. You can see that in the cpufreq code or in the speedstep driver. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 14 23:01:12 2010 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 8B913106566C; Tue, 14 Sep 2010 23:01:12 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id EE0218FC18; Tue, 14 Sep 2010 23:01:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 84BB71074D; Wed, 15 Sep 2010 08:01:09 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rSILU1pjQuZ; Wed, 15 Sep 2010 08:01:06 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Wed, 15 Sep 2010 08:01:06 +0900 (JST) Date: Wed, 15 Sep 2010 08:01:24 +0900 From: Taku YAMAMOTO To: Andriy Gapon Message-Id: <20100915080124.c6d53391.taku@tackymt.homeip.net> In-Reply-To: <4C8F35FD.2090603@freebsd.org> 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> <4C8CF91A.4040804@FreeBSD.org> <4C8E5A5D.6000303@icyb.net.ua> <4C8F35FD.2090603@freebsd.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__15_Sep_2010_08_01_24_+0900_YduQ=5Ge2cFM+HD5" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Motin , freebsd-acpi@freebsd.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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, 14 Sep 2010 23:01:12 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__15_Sep_2010_08_01_24_+0900_YduQ=5Ge2cFM+HD5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 14 Sep 2010 11:44:45 +0300 Andriy Gapon wrote: > Additionally, it seems that we do not currently have any support for Functional > Fixed Hardware (FFH) way of providing C states. In this case _CST returns GAS > of a register used to enter a C state with address space ID set to > ACPI_ADR_SPACE_FIXED_HARDWARE (0x7f/127). Such addresses should be handled in a > special way: > ftp://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf > > Currently we simply (and silently) ignore such _CST entries. > I think that this should be useful (if not necessary) with mwait. I have a proof-of-concept, quick'n'dirty patch against pre-r212541 to utilize FFH _CST. Unfortunately I have no time to catch up the latest and fantastic work by mav, though. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Wed__15_Sep_2010_08_01_24_+0900_YduQ=5Ge2cFM+HD5-- From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 14 23:11:29 2010 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 CDB5B1065670 for ; Tue, 14 Sep 2010 23:11:29 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id CD6598FC0C for ; Tue, 14 Sep 2010 23:11:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 2CE8F1074D for ; Wed, 15 Sep 2010 08:11:28 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzzZ0zBgU948 for ; Wed, 15 Sep 2010 08:11:25 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTP for ; Wed, 15 Sep 2010 08:11:25 +0900 (JST) Date: Wed, 15 Sep 2010 08:11:43 +0900 From: Taku YAMAMOTO To: freebsd-acpi@freebsd.org Message-Id: <20100915081143.c7783553.taku@tackymt.homeip.net> In-Reply-To: <20100915080124.c6d53391.taku@tackymt.homeip.net> 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> <4C8CF91A.4040804@FreeBSD.org> <4C8E5A5D.6000303@icyb.net.ua> <4C8F35FD.2090603@freebsd.org> <20100915080124.c6d53391.taku@tackymt.homeip.net> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__15_Sep_2010_08_11_43_+0900_VGPL5SoSZBB5p/0F" Subject: Follow-up: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 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, 14 Sep 2010 23:11:30 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__15_Sep_2010_08_11_43_+0900_VGPL5SoSZBB5p/0F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 15 Sep 2010 08:01:24 +0900 Taku YAMAMOTO wrote: > On Tue, 14 Sep 2010 11:44:45 +0300 > Andriy Gapon wrote: > > > Additionally, it seems that we do not currently have any support for Functional > > Fixed Hardware (FFH) way of providing C states. In this case _CST returns GAS > > of a register used to enter a C state with address space ID set to > > ACPI_ADR_SPACE_FIXED_HARDWARE (0x7f/127). Such addresses should be handled in a > > special way: > > ftp://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf > > > > Currently we simply (and silently) ignore such _CST entries. > > I think that this should be useful (if not necessary) with mwait. > > I have a proof-of-concept, quick'n'dirty patch against pre-r212541 > to utilize FFH _CST. > > Unfortunately I have no time to catch up the latest and fantastic work by mav, > though. Uh, the patch got eaten by mailman... Here it is. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Wed__15_Sep_2010_08_11_43_+0900_VGPL5SoSZBB5p/0F Content-Type: text/plain; name="native_cx-20100724.patch" Content-Disposition: attachment; filename="native_cx-20100724.patch" Content-Transfer-Encoding: 7bit diff -rup /sys/dev/acpica/acpi_cpu.c ./dev/acpica/acpi_cpu.c --- sys/dev/acpica/acpi_cpu.c 2010-02-11 17:50:21.000000000 +0900 +++ sys/dev/acpica/acpi_cpu.c 2010-05-12 05:21:13.000000000 +0900 @@ -65,6 +65,13 @@ struct acpi_cx { uint32_t trans_lat; /* Transition latency (usec). */ uint32_t power; /* Power consumed (mW). */ int res_type; /* Resource type for p_lvlx. */ +#ifdef ACPI_USE_NATIVE_CX +#define pseudo_BUS_SPACE_FFIXEDHW -1 /* FFixedHW pseudo resource */ + uint8_t vendor; /* Encoded as BitWidth */ + uint8_t classcode; /* Encoded as BitOffset */ + uint8_t arg1; /* Encoded as AccessWidth */ + uint64_t arg0; /* Encoded as Address */ +#endif /* ACPI_USE_NATIVE_CX */ }; #define MAX_CX_STATES 8 @@ -336,6 +343,9 @@ acpi_cpu_attach(device_t dev) * SMP control where each CPU can have different settings. */ sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3; +#ifdef ACPI_USE_NATIVE_CX /* XXX */ + sc->cpu_features |= ACPI_CAP_SMP_C1_NATIVE | ACPI_CAP_SMP_CX_NATIVE; +#endif if (devclass_get_drivers(acpi_cpu_devclass, &drivers, &drv_count) == 0) { for (i = 0; i < drv_count; i++) { if (ACPI_GET_FEATURES(drivers[i], &features) == 0) @@ -688,9 +698,13 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *s switch (cx_ptr->type) { case ACPI_STATE_C1: sc->cpu_non_c3 = i; +#ifdef ACPI_USE_NATIVE_CX + break; +#else cx_ptr++; sc->cpu_cx_count++; continue; +#endif case ACPI_STATE_C2: if (cx_ptr->trans_lat > 100) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, @@ -721,6 +735,21 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *s } #endif +#ifdef ACPI_USE_NATIVE_CX + /* Check for FFixedHW first. */ + if (acpi_PkgGasFFH(pkg, 0, &cx_ptr->vendor, &cx_ptr->classcode, &cx_ptr->arg1, &cx_ptr->arg0) == 0) { + /* We do not increment cpu_rid, because FixedHW isn't a resource. */ + cx_ptr->res_type = pseudo_BUS_SPACE_FFIXEDHW; + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "acpi_cpu%d: Got C%d - %d latency\n", + device_get_unit(sc->cpu_dev), cx_ptr->type, + cx_ptr->trans_lat)); + cx_ptr++; + sc->cpu_cx_count++; + continue; + } +#endif + /* Allocate the control register for C2 or C3. */ acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &sc->cpu_rid, &cx_ptr->p_lvlx, RF_SHAREABLE); @@ -779,6 +808,8 @@ acpi_cpu_startup(void *arg) if (sc->cpu_cx_count < cpu_cx_count) cpu_cx_count = sc->cpu_cx_count; } + if (cpu_cx_count <= 1) + return; } else { /* * We are using _CST mode, remove C3 state if necessary. @@ -859,14 +890,12 @@ acpi_cpu_startup_cx(struct acpi_cpu_soft (void *)sc, 0, acpi_cpu_usage_sysctl, "A", "percent usage for each Cx state"); -#ifdef notyet /* Signal platform that we can handle _CST notification. */ if (!cpu_cx_generic && cpu_cst_cnt != 0) { ACPI_LOCK(acpi); AcpiOsWritePort(cpu_smi_cmd, cpu_cst_cnt, 8); ACPI_UNLOCK(acpi); } -#endif } /* @@ -933,7 +962,11 @@ acpi_cpu_idle() * precisely calculate the time spent in C1 since the place we wake up * is an ISR. Assume we slept no more than half of quantum. */ - if (cx_next->type == ACPI_STATE_C1) { + if (cx_next->type == ACPI_STATE_C1 +#ifdef ACPI_USE_NATIVE_CX + && cx_next->vendor == 0 && cx_next->classcode == 0 +#endif + ) { AcpiHwRead(&start_time, &AcpiGbl_FADT.XPmTimerBlock); acpi_cpu_c1(); AcpiHwRead(&end_time, &AcpiGbl_FADT.XPmTimerBlock); @@ -958,6 +991,12 @@ acpi_cpu_idle() * is the only reliable time source. */ AcpiHwRead(&start_time, &AcpiGbl_FADT.XPmTimerBlock); +#ifdef ACPI_USE_NATIVE_CX + if (cx_next->res_type == pseudo_BUS_SPACE_FFIXEDHW) { + acpi_cpu_cx_native(cx_next->vendor, cx_next->classcode, cx_next->arg1, cx_next->arg0); + AcpiHwRead(&end_time, &AcpiGbl_FADT.XPmTimerBlock); + } else { +#endif CPU_GET_REG(cx_next->p_lvlx, 1); /* @@ -967,6 +1006,9 @@ acpi_cpu_idle() */ AcpiHwRead(&end_time, &AcpiGbl_FADT.XPmTimerBlock); AcpiHwRead(&end_time, &AcpiGbl_FADT.XPmTimerBlock); +#ifdef ACPI_USE_NATIVE_CX + } +#endif /* Enable bus master arbitration and disable bus master wakeup. */ if (cx_next->type == ACPI_STATE_C3 && diff -rup /sys/dev/acpica/acpi_package.c ./dev/acpica/acpi_package.c --- sys/dev/acpica/acpi_package.c 2010-05-06 21:14:43.080994553 +0900 +++ sys/dev/acpica/acpi_package.c 2010-05-12 05:22:33.000000000 +0900 @@ -103,11 +103,9 @@ acpi_PkgStr(ACPI_OBJECT *res, int idx, v return (0); } -int -acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, int *rid, - struct resource **dst, u_int flags) +static int +acpi_get_PkgGas(ACPI_OBJECT *res, int idx, ACPI_GENERIC_ADDRESS *gas) { - ACPI_GENERIC_ADDRESS gas; ACPI_OBJECT *obj; obj = &res->Package.Elements[idx]; @@ -115,11 +113,46 @@ acpi_PkgGas(device_t dev, ACPI_OBJECT *r obj->Buffer.Length < sizeof(ACPI_GENERIC_ADDRESS) + 3) return (EINVAL); - memcpy(&gas, obj->Buffer.Pointer + 3, sizeof(gas)); + memcpy(gas, obj->Buffer.Pointer + 3, sizeof(*gas)); + return (0); +} + +int +acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, int *rid, + struct resource **dst, u_int flags) +{ + ACPI_GENERIC_ADDRESS gas; + int r; + r = acpi_get_PkgGas(res, idx, &gas); + if (r != 0) + return (r); return (acpi_bus_alloc_gas(dev, type, rid, &gas, dst, flags)); } +int +acpi_PkgGasFFH(ACPI_OBJECT *res, int idx, uint8_t *vendor, uint8_t *classcode, + uint8_t *arg1, UINT64 *arg0) +{ + ACPI_GENERIC_ADDRESS gas; + int r; + + r = acpi_get_PkgGas(res, idx, &gas); + if (r != 0) + return (r); + + if (gas.SpaceId != ACPI_ADR_SPACE_FIXED_HARDWARE) + return (EOPNOTSUPP); + + /* Extract encoded values. */ + *vendor = gas.BitWidth; + *classcode = gas.BitOffset; + *arg1 = gas.AccessWidth; + *arg0 = gas.Address; + + return (0); +} + ACPI_HANDLE acpi_GetReference(ACPI_HANDLE scope, ACPI_OBJECT *obj) { diff -rup /sys/dev/acpica/acpivar.h ./dev/acpica/acpivar.h --- sys/dev/acpica/acpivar.h 2010-05-06 21:14:43.140066765 +0900 +++ sys/dev/acpica/acpivar.h 2010-05-10 05:29:23.000000000 +0900 @@ -201,6 +201,7 @@ extern struct mtx acpi_mutex; #define ACPI_CAP_SMP_DIFF_CX (1 << 6) /* MP Cx (different, using _CSD) */ #define ACPI_CAP_SMP_DIFF_TX (1 << 7) /* MP Tx (different, using _TSD) */ #define ACPI_CAP_SMP_C1_NATIVE (1 << 8) /* MP C1 support other than halt */ +#define ACPI_CAP_SMP_CX_NATIVE (1 << 9) /* MP Cx support other than halt */ /* * Quirk flags. @@ -449,6 +450,8 @@ int acpi_PkgInt32(ACPI_OBJECT *res, int int acpi_PkgStr(ACPI_OBJECT *res, int idx, void *dst, size_t size); int acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, int *rid, struct resource **dst, u_int flags); +int acpi_PkgGasFFH(ACPI_OBJECT *res, int idx, uint8_t *vendor, + uint8_t *classcode, uint8_t *arg1, UINT64 *arg0); ACPI_HANDLE acpi_GetReference(ACPI_HANDLE scope, ACPI_OBJECT *obj); /* diff -rup /sys/i386/acpica/acpi_machdep.c ./i386/acpica/acpi_machdep.c --- sys/i386/acpica/acpi_machdep.c 2010-05-06 21:15:10.955047053 +0900 +++ sys/i386/acpica/acpi_machdep.c 2010-05-11 04:51:27.000000000 +0900 @@ -560,6 +560,47 @@ acpi_cpu_c1() } /* + * vendor: ACPI_GENERIC_ADDRESS.BitWidth (8-bit). + * classcode: ACPI_GENERIC_ADDRESS.BitOffset (8-bit). + * arg1: ACPI_GENERIC_ADDRESS.AccessWidth (8-bit). + * arg0: ACPI_GENERIC_ADDRESS.Address (64-bit). + */ +void +acpi_cpu_cx_native(uint8_t vendor, uint8_t classcode, uint8_t arg1, uint64_t arg0) +{ + switch (vendor) { + case 1: /* Intel */ + switch (classcode) { + case 1: + /* + * C1 I/O then HLT. + * arg0: I/O port address to inb. + * arg1: not used (supposed to be 0). + */ + inb((u_int)arg0); + break; + + case 2: + /* + * Native C state insn, a.k.a. MWAIT. + * arg0[31:0] : hint for MWAIT (through EAX). + * arg1[0] : H/W-coordinated. + * arg1[1] : Requires bus-master avoidance. (?) + */ +#define MWAIT_INTR 0x01 /* an INT breaks MWAIT even if it's disabled. */ + cpu_mwait(MWAIT_INTR, (uint32_t)arg0); + return; + } + break; + + /* More vendors? */ + } + + /* Defaults to STI-HLT sequence. */ + __asm __volatile("sti; hlt"); +} + +/* * Support for mapping ACPI tables during early boot. This abuses the * crashdump map because the kernel cannot allocate KVA in * pmap_mapbios() when this is used. This makes the following diff -rup /sys/i386/i386/machdep.c ./i386/i386/machdep.c --- sys/i386/i386/machdep.c 2010-04-13 19:12:58.000000000 +0900 +++ sys/i386/i386/machdep.c 2010-05-13 05:54:57.941747275 +0900 @@ -1227,6 +1227,23 @@ cpu_idle_acpi(int busy) __asm __volatile("sti; hlt"); } +static int cpu_ident_mwait_ext = 0; + +static int +cpu_probe_mwait_ext(void) +{ + u_int regs[4]; /* XXX - should we prefer register_t? */ + + if (!(cpu_feature2 & CPUID2_MON)) + return (0); + do_cpuid(5 /* CPUID_MONITOR */, regs); + if ((regs[2/*ecx*/] & 0x03/*MON_EXT|MON_INTR*/) == 0x03/*both set*/) { + cpu_ident_mwait_ext = 1; + return (1); + } + return (0); +} + static int cpu_ident_amdc1e = 0; static int @@ -1322,6 +1339,14 @@ cpu_idle(int busy) #define MWAIT_C3 0x20 #define MWAIT_C4 0x30 +/* + * mwait extensions. + */ +#define MWAIT_INTR 0x01 + +/* + * monitorbuf usage. + */ #define MWAIT_DISABLED 0x0 #define MWAIT_WOKEN 0x1 #define MWAIT_WAITING 0x2 @@ -1359,6 +1384,27 @@ cpu_idle_mwait_hlt(int busy) cpu_mwait(0, MWAIT_C1); } +static void +cpu_idle_acpi_mwait(int busy) +{ + int *mwait; + + disable_intr(); + mwait = (int *)PCPU_PTR(monitorbuf); + *mwait = MWAIT_WAITING; + if (sched_runnable()) + goto done; + cpu_monitor(mwait, 0, 0); + if (*mwait == MWAIT_WAITING) { + if (cpu_idle_hook) + cpu_idle_hook(); + else + cpu_mwait(MWAIT_INTR, MWAIT_C1); + } +done: + enable_intr(); +} + int cpu_idle_wakeup(int cpu) { @@ -1367,7 +1413,8 @@ cpu_idle_wakeup(int cpu) if (cpu_idle_fn == cpu_idle_spin) return (1); - if (cpu_idle_fn != cpu_idle_mwait && cpu_idle_fn != cpu_idle_mwait_hlt) + if (cpu_idle_fn != cpu_idle_mwait && cpu_idle_fn != cpu_idle_mwait_hlt + && cpu_idle_fn != cpu_idle_acpi_mwait) return (0); pcpu = pcpu_find(cpu); mwait = (int *)pcpu->pc_monitorbuf; @@ -1395,6 +1442,7 @@ struct { { cpu_idle_amdc1e, "amdc1e" }, { cpu_idle_hlt, "hlt" }, { cpu_idle_acpi, "acpi" }, + { cpu_idle_acpi_mwait, "acpi_mwait" }, { NULL, NULL } }; @@ -1414,6 +1462,9 @@ idle_sysctl_available(SYSCTL_HANDLER_ARG if (strcmp(idle_tbl[i].id_name, "amdc1e") == 0 && cpu_ident_amdc1e == 0) continue; + if (strcmp(idle_tbl[i].id_name, "acpi_mwait") == 0 && + cpu_ident_mwait_ext == 0) + continue; p += sprintf(p, "%s, ", idle_tbl[i].id_name); } error = sysctl_handle_string(oidp, avail, 0, req); @@ -1447,6 +1498,9 @@ idle_sysctl(SYSCTL_HANDLER_ARGS) if (strcmp(idle_tbl[i].id_name, "amdc1e") == 0 && cpu_ident_amdc1e == 0) continue; + if (strcmp(idle_tbl[i].id_name, "acpi_mwait") == 0 && + cpu_ident_mwait_ext == 0) + continue; if (strcmp(idle_tbl[i].id_name, buf)) continue; cpu_idle_fn = idle_tbl[i].id_fn; @@ -2954,6 +3008,8 @@ init386(first) thread0.td_pcb->pcb_ext = 0; thread0.td_frame = &proc0_tf; + if (cpu_probe_mwait_ext()) + cpu_idle_fn = cpu_idle_acpi_mwait; if (cpu_probe_amdc1e()) cpu_idle_fn = cpu_idle_amdc1e; } diff -rup /sys/i386/include/acpica_machdep.h ./i386/include/acpica_machdep.h --- sys/i386/include/acpica_machdep.h 2009-10-07 06:34:28.915016725 +0900 +++ sys/i386/include/acpica_machdep.h 2010-05-11 04:43:31.000000000 +0900 @@ -94,9 +94,11 @@ extern int acpi_release_global_lock(uint #define COMPILER_DEPENDENT_INT64 long long #define COMPILER_DEPENDENT_UINT64 unsigned long long #define ACPI_USE_NATIVE_DIVIDE +#define ACPI_USE_NATIVE_CX void acpi_SetDefaultIntrModel(int model); void acpi_cpu_c1(void); +void acpi_cpu_cx_native(uint8_t vendor, uint8_t classcode, uint8_t arg1, uint64_t arg0); void *acpi_map_table(vm_paddr_t pa, const char *sig); void acpi_unmap_table(void *table); vm_paddr_t acpi_find_table(const char *sig); --Multipart=_Wed__15_Sep_2010_08_11_43_+0900_VGPL5SoSZBB5p/0F-- From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 15 20:24:43 2010 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C37E1065670 for ; Wed, 15 Sep 2010 20:24:43 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id EA7B78FC12 for ; Wed, 15 Sep 2010 20:24:42 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 15 Sep 2010 12:56:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.56,372,1280732400"; d="scan'208";a="325020188" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by azsmga001.ch.intel.com with ESMTP; 15 Sep 2010 12:56:20 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx602.amr.corp.intel.com ([10.22.226.211]) with mapi; Wed, 15 Sep 2010 12:56:20 -0700 From: "Moore, Robert" To: "Moore, Robert" Date: Wed, 15 Sep 2010 12:56:18 -0700 Thread-Topic: ACPICA version 20100915 released Thread-Index: ActVEA/lEjqVQhg3Sna4NfRIaVIiXQ== Message-ID: <4911F71203A09E4D9981D27F9D830858AF1B2C4E@orsmsx503.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 15 Sep 2010 20:38:16 +0000 Cc: Subject: ACPICA version 20100915 released 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: Wed, 15 Sep 2010 20:24:43 -0000 15 September 2010. Summary of changes for version 20100915: This release is available at www.acpica.org/downloads 1) ACPI CA Core Subsystem: Removed the AcpiOsDerivePciId OSL interface. The various host implementatio= ns of this function were not OS-dependent and are now obsolete and can be r= emoved from all host OSLs. This function has been replaced by AcpiHwDeriveP= ciId, which is now part of the ACPICA core code. AcpiHwDerivePciId has been= implemented without recursion. Adds one new module, hwpci.c. ACPICA BZ 857= . Implemented a dynamic repair for _HID and _CID strings. The following probl= ems are now repaired at runtime: 1) Remove a leading asterisk in the string= , and 2) the entire string is uppercased. Both repairs are in accordance wi= th the ACPI specification and will simplify host driver code. ACPICA BZ 871= . The ACPI_THREAD_ID type is no longer configurable, internally it is now alw= ays UINT64. This simplifies the ACPICA code, especially any printf output. = UINT64 is the only common data type for all thread_id types across all oper= ating systems. It is now up to the host OSL to cast the native thread_id ty= pe to UINT64 before returning the value to ACPICA (via AcpiOsGetThreadId). = Lin Ming, Bob Moore. Added the ACPI_INLINE type to enhance the ACPICA configuration. The "inline= " keyword is not standard across compilers, and this type allows inline to = be configured on a per-compiler basis. Lin Ming. Made the system global AcpiGbl_SystemAwakeAndRunning publically available. = Added an extern for this boolean in acpixf.h. Some hosts utilize this value= during suspend/restore operations. ACPICA BZ 869. All code that implements error/warning messages with the "ACPI:" prefix has= been moved to a new module, utxferror.c. The UINT64_OVERLAY was moved to utmath.c, which is the only module where it= is used. ACPICA BZ 829. Lin Ming, Bob Moore. Example Code and Data Size: These are the sizes for the OS-independent acpi= ca.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug = version of the code includes the debug output trace mechanism and has a muc= h larger code and data size. Previous Release: Non-Debug Version: 89.1K Code, 19.0K Data, 108.1K Total Debug Version: 165.1K Code, 51.9K Data, 217.0K Total Current Release: Non-Debug Version: 89.9K Code, 19.0K Data, 108.9K Total Debug Version: 166.3K Code, 52.1K Data, 218.4K Total 2) iASL Compiler/Disassembler and Tools: iASL/Disassembler: Write ACPI errors to stderr instead of the output file. = This keeps the output files free of random error messages that may originat= e from within the namespace/interpreter code. Used this opportunity to merg= e all ACPI:-style messages into a single new module, utxferror.c. ACPICA BZ= 866. Lin Ming, Bob Moore. Tools: update some printfs for ansi warnings on size_t. Handle width change= of size_t on 32-bit versus 64-bit generations. Lin Ming. From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 17 21:26:02 2010 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 D58AC1065679 for ; Fri, 17 Sep 2010 21:26:02 +0000 (UTC) (envelope-from kuba.g4@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 56A5E8FC1A for ; Fri, 17 Sep 2010 21:26:01 +0000 (UTC) Received: by bwz15 with SMTP id 15so3891249bwz.13 for ; Fri, 17 Sep 2010 14:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=Ql+n7n37h2B5uqP97uhLYda55ewwX9+MWvZOcuzbrNw=; b=pzebDWuPS17IpaxazhQU2e4rAVvHgIQBwFkLsKul3bhfHOoOGE1uYRDZIIgHalLn60 blhWzw7yMIa1ZZaiiVexg0McLiflvxz5GDlsPYjoxafLg/WuZ9LhTzjSKEFN8kVyzP0g R7XjRMkQjtdz5esWcKcV6BAInYjaUeHNe+pVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=wLRQRJnnNHJr25LrwGxLwOyLxhPKwFwmaFrBofoWOVIp8LOBB/+NGFCjZYAfx3WWpL myty0d4sBOEQD9+u0QDtwLACaUpdDs1rEDePL79aYlu5D+3iW4qvIRcRMe/wPD6IqMAc ugP5e9Tj3WmCSqt1SahcuYa9pCsnQ9VYCZ+po= Received: by 10.204.67.138 with SMTP id r10mr4350783bki.103.1284758760653; Fri, 17 Sep 2010 14:26:00 -0700 (PDT) Received: from [10.0.0.22] (ip-94-42-54-132.multimo.pl [94.42.54.132]) by mx.google.com with ESMTPS id f18sm4020667bkf.15.2010.09.17.14.25.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Sep 2010 14:25:58 -0700 (PDT) Message-ID: <4C93DCE3.5030706@gmail.com> Date: Fri, 17 Sep 2010 23:25:55 +0200 From: kuba User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Lanikai/3.1.3 MIME-Version: 1.0 To: Andriy Gapon , freebsd-acpi@freebsd.org References: <20100829235431.J86162@sola.nimnet.asn.au> <20100830183330.Y29840@sola.nimnet.asn.au> <4C7BBCFE.4030804@icyb.net.ua> <20100831003546.K29840@sola.nimnet.asn.au> <4C8095A2.90506@icyb.net.ua> <4C80E650.7010706@icyb.net.ua> In-Reply-To: <4C80E650.7010706@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: acpi shows wrong battery state 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: Fri, 17 Sep 2010 21:26:02 -0000 Sorry, but for couple of days,I didn't have access to the Internet. >> I've noticed that always after installation on "clean" system acpi >> shows proper battery state( 8.0 and 8.1), but when I install xorg, >> dbus, kde and reboot I will be dealing with acpi errors... again. > Look for other things that you can correlate - like first reboot after booting to > other OS, etc. > I've compiled 9.0-current kernel yesterday, and there is still the same problem. I've also noticed that after 8.1 installation, there is 50% (more or less? maybe it is stupid, but i don't have any idea how it works,) chance that acpiconf -i batt will show good state. I have already pasted my configs, the new ones are similar. Plesase remeber that I am new BSD user, and not everything you say to me is perfectly clear :) But I am determined to use this system.. cheers, kuba