Re: P-state setting suddenly disappeared, what gives?
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?
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?
-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?
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"