Date: Fri, 15 Nov 2013 09:17:12 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Cc: njl@freebsd.org Subject: Re: P-state setting suddenly disappeared, what gives? Message-ID: <201311150917.12998.jhb@freebsd.org> In-Reply-To: <52855927.9010103@FreeBSD.org> References: <CAJ-Vmom9tT2yvJu9D5R=Uyg47TKGX9mkP8M2My8XQZFezdjiyA@mail.gmail.com> <52855927.9010103@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201311150917.12998.jhb>