Re: P-state setting suddenly disappeared, what gives?

2013-11-15 Thread 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
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


Re: P-state setting suddenly disappeared, what gives?

2013-11-15 Thread John Baldwin
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
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


Re: P-state setting suddenly disappeared, what gives?

2013-11-14 Thread Jung-uk Kim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.

Jung-uk Kim

1.  See http://docs.freebsd.org/cgi/mid.cgi?4B698DD8.4010404 for
current implementation.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQEcBAEBAgAGBQJShVknAAoJEHyflib82/FGzwkH/2M9EwyFJRL5Edo4QWstNw8r
9tDWKzzkRqCB3D0+QSvOTA+ZbOnnoTwQAfLyyWZEJcz3kWuN5KLqjix4zFzX3F//
NGuhmsDDqa8OQ4wAL6ZL9RP+O1S6pc9j1W1Q7FG96G94trVjsVXRubvwosHca1YL
SD2OK0UMxGPf9jqu9nSilh3j6Ry3w+LeQbg8aEjUPltwOQzPIxV34pwWzX0EeENG
HkTeO82F5o8Gj0l55KZKl+qi64HAujbqFuZv6OdZxetrP61Z1SeqqkOQez++Z9oM
kwlKF/xev2+Z3bJNChgV+FQtQ4eapBTSpAj1bvjEsGfSKCDaIlIftDhmFi80Sf0=
=co85
-END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


P-state setting suddenly disappeared, what gives?

2013-11-14 Thread Adrian Chadd
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?

Thanks!



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"