P-state setting suddenly disappeared, what gives?

[Ian Smith]

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