From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 20:11:06 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 986C110656DC; Thu, 26 Mar 2009 20:11:06 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from lucifer.hellteam.net (lucifer.hellteam.net [88.86.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1D14F8FC1A; Thu, 26 Mar 2009 20:11:05 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from smtp.hellteam.net (rik.hellteam.net [78.108.102.225]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by lucifer.hellteam.net (Postfix) with ESMTPS id 3236810B4; Thu, 26 Mar 2009 20:55:27 +0100 (CET) Received: from gandalf (gandalf.tocnet28.jspoj.czf [10.40.8.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.hellteam.net (Postfix) with ESMTPSA id 3BCCD57004F; Thu, 26 Mar 2009 20:51:51 +0100 (CET) From: =?iso-8859-1?Q?Daniel_Dvor=E1k?= To: "'Stephane E. Potvin'" , "'John Baldwin'" References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> <200903261050.51602.jhb@freebsd.org> <49CB9972.4030502@FreeBSD.org> Date: Thu, 26 Mar 2009 20:51:51 +0100 Organization: Projekt HELL Message-ID: <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49CB9972.4030502@FreeBSD.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Thread-Index: AcmuJV8k2YX85jS8Qsm/mMvpDja+BwAJpaxw Cc: 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 Reply-To: dandee@hellteam.net 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 20:11:08 -0000 Hi all, I found out this error on the other computers. Will it be helpful for analyzing to send infromation about cpu, acpi table and so on ? Or is = the first example enough ? DD -----Original Message----- From: Stephane E. Potvin [mailto:sepotvin@FreeBSD.org]=20 Sent: Thursday, March 26, 2009 4:04 PM To: John Baldwin Cc: Bruce Cran; Daniel Dvor(=E1k; freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: = Invalid argument John Baldwin wrote: > On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: >> On Thu, 26 Mar 2009 09:37:50 -0400 >> John Baldwin wrote: >> >>> No, the code is doing things differently on purpose (though I'm not=20 >>> completely sure why). For _CST it sets cpu_cx_count to the maximum=20 >>> Cx level supported by any CPU in the system. For non-_CST it sets=20 >>> it to the maximum Cx level supported by all CPUs in the system. I=20 >>> think it is correct for cpu_cx_count to always start at 0 and only=20 >>> be bumped up to a higher setting. Setting it to 3 would be very=20 >>> wrong for the _CST case as I've seen CPUs that support C4. >> From briefly reading through the specifications I'd assumed the=20 >> maximum power state was C3. >=20 > For the non _CST case that is all that is defined, yes. However, _CST = > is a variable length array of Cx states, so it can support arbitrary=20 > numbers of states. >=20 >> I had thought the _CST block was wrong because in=20 >> acpi_cpu_global_cx_lowest_sysctl it validates the new value against=20 >> cpu_cx_count; if one CPU has a lower cx state than the others, then=20 >> won't this tell the other CPUs to use an unsupported state? >=20 > It depends on if the CPU driver is smart enough to cap requests to > sc->cpu_cx_count, though if it does presumably it would do that in the > cx_generic case as well. I'm not sure why it behaves differently for=20 > the _CST case, but I do think it is on purpose at least rather than an = > accidental bug. Perhaps Nate can chime in with why? >=20 The intent when I added support for cx states on SMP systems was to use = the same maximum cx_state for all CPUs when _CST is not used (cx_generic case) and to respect per-processor maximum cx_state when _CST is present = and can be used. This whole piece of code is really convoluted and there's = been a few errors found in it over time so I wouldn't be surprised if there = were some still lurking. Could you send me privately a copy of your ASL and a verbose boot log? Steph