From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 15 18:00:52 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4D641F9; Fri, 15 Nov 2013 18:00:52 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 412C12B1C; Fri, 15 Nov 2013 18:00:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id rAFHcoNN058036; Sat, 16 Nov 2013 04:38:50 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 16 Nov 2013 04:38:50 +1100 (EST) From: Ian Smith To: John Baldwin Subject: Re: P-state setting suddenly disappeared, what gives? In-Reply-To: <201311150917.12998.jhb@freebsd.org> Message-ID: <20131116041120.C44639@sola.nimnet.asn.au> References: <52855927.9010103@FreeBSD.org> <201311150917.12998.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, njl@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 18:00:53 -0000 On Fri, 15 Nov 2013, John Baldwin wrote: > On Thursday, November 14, 2013 6:13:43 pm Jung-uk Kim wrote: > > On 2013-11-14 17:41:44 -0500, Adrian Chadd wrote: > > > Hi all, > > > > > > I have this Lenovo T400 that I've been doing FreeBSD development on > > > for a while. > > > > > > It has a P8700 in it: > > > > > > CPU: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz (2527.07-MHz > > > 686-class CPU) > > > > > > Now, up until yesterday, ACPI exported the required twiddles to > > > enter various different P-states. > > > > > > However, as of sometime yesterday, it stopped being able to do so. > > > > > > sysctl dev.cpu.0.freq returns nothing. Setting it to something > > > retuns "device not configured." The frequency list (ie, the P-state > > > list) is still fine. > > > > > > I had to load cpufreq.ko to get the enhanced speedstep stuff to > > > show up, but (a) it doesn't support this CPU (and it seems to have > > > stopped growing EST bits after Pentium M CPUs..) and (b) setting > > > the frequency using it versus P-state settings doesn't save as much > > > power. > > > > > > I'd like to try and debug why the heck this is. > > > > > > The laptop still works fine, things are just not as "nice" as they > > > once were. > > > > > > Any ideas? Any suggestions on where to start debugging this? > > > > SSDT tables for Intel processors are usually dynamic and often times > > additional tables are loaded per _OSC or _PDC. [1] Basically, we > > advertise our capabilities from sys/dev/acpica/acpi_cpu.c, depending > > on loaded device drivers. Unfortunately, some times it is too late > > and some SSDTs are not properly loaded. Also, warm booting from other > > OSes to FreeBSD may cause similar problems. > > > > To debug the problem, you need to dump DSDT and SSDTs and try to > > understand _OSC (or _PDC), _PCT and _PSS for your system. > > Also, the reason that est.c doesn't hardcode tables for modern CPUs is that on > modern systems the tables are provided by ACPI via the acpi_perf(4) driver. I hate to mention it again without offering to write them, but alas, http://www.freebsd.org/cgi/man.cgi?query=acpi_perf&apropos=0&sektion=0&manpath=FreeBSD+10-current&arch=default&format=html as ever says: Sorry, no data found for `acpi_perf'. Nor any of the absolute or relative drivers listed in cpufreq(4). Good GSoC project? cheers, Ian