From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 20:29:17 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 326291065670; Thu, 26 Mar 2009 20:29:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E50098FC16; Thu, 26 Mar 2009 20:29:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 8915546B06; Thu, 26 Mar 2009 16:29:16 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2QKTAct085752; Thu, 26 Mar 2009 16:29:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: dandee@hellteam.net Date: Thu, 26 Mar 2009 16:29:05 -0400 User-Agent: KMail/1.9.7 References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <49CB9972.4030502@FreeBSD.org> <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> In-Reply-To: <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903261629.06238.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Mar 2009 16:29:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9171/Thu Mar 26 13:49:28 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, "'Stephane E. Potvin'" Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:29:17 -0000 On Thursday 26 March 2009 3:51:51 pm Daniel Dvor=E1k wrote: > Hi all, >=20 > 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 ? The example is enough, we just need someone to test the patch and make sure= it=20 fixes the problem. > DD >=20 > -----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 >=20 > 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= =20 > > 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= =20 > > accidental bug. Perhaps Nate can chime in with why? > >=20 >=20 > The intent when I added support for cx states on SMP systems was to use t= he > 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 be= en > a few errors found in it over time so I wouldn't be surprised if there we= re > some still lurking. >=20 > Could you send me privately a copy of your ASL and a verbose boot log? >=20 > Steph >=20 >=20 =2D-=20 John Baldwin