From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 11 11:06:45 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 ESMTP id 2BD098F8 for ; Mon, 11 Nov 2013 11:06:45 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EFBEF2CA5 for ; Mon, 11 Nov 2013 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rABB6ikG081940 for ; Mon, 11 Nov 2013 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rABB6irc081938 for freebsd-acpi@FreeBSD.org; Mon, 11 Nov 2013 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Nov 2013 11:06:44 GMT Message-Id: <201311111106.rABB6irc081938@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 11:06:45 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/73823 acpi [request] acpi / power-on by timer support 28 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 11 20:03:55 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 17B29950 for ; Mon, 11 Nov 2013 20:03:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <5281374F.7080802@FreeBSD.org> Date: Mon, 11 Nov 2013 15:00:15 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-acpi Subject: Fwd: Re: Problems with amd FX 8 core and freq scaling References: <5281358D.1010406@FreeBSD.org> In-Reply-To: <5281358D.1010406@FreeBSD.org> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <5281358D.1010406@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------020705030408060006020301" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:03:55 -0000 This is a multi-part message in MIME format. --------------020705030408060006020301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: > But wouldn't this just disable frequency scaling and the whole > point of powerd? No. acpi_throttle (and p4tcc) controls T-state. "Frequency scaling" should be done by changing P-state. > On Mon, Nov 11, 2013 at 1:46 AM, Stefan Esser > wrote: >> >> Am 10.11.2013 22:46, schrieb Nicholas Stewart McKenzie: >>> My computer crashes if I enable powerd. I can't get cpu freq >>> scaling to work with my cpu:(P.S. I sent this to both drivers >>> and amd64 mailing list... >> >> Hi, >> >> you may want to try booting with the following line added to >> /boot/loader.conf (or entered at the boot menu prompt after >> breaking out of automatic boot): >> >> hint.acpi_throttle.0.disabled="1" >> >> There have been a number of reports of throttling causing >> crashes. This setting does not prevent powerd from adjusting >> your CPU's clock, it just disables some arcane feature which >> pre-dates the modern power management methods. I rewrote acpi_throttle.c at some point to fix the problem but never committed it because nobody was really interested in testing the patch. Also, it is really an arcane and archaic feature: http://software.intel.com/en-us/blogs/2013/10/15/c-states-p-states-where-the-heck-are-those-t-states Now I think we should disable the feature by default because it is causing too much hassle for us (attached). Any objection? Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJSgTdPAAoJEHyflib82/FGZaEIAJPt2/qPu7CxFAHBwizG+o+Y Mmn0rqXREynXT83ds5cD998cO44GHFGhSaDYZ6wuL6CXoSE2bzTo5aAjVq/vY6io 4ItmvZPVNKK/UxeTK+ccDeuMKBXHBmOoUUUADGRy1d9S+GGtie0DVSpWZhEvSFrY l/y1Dt3yd53qjlV96GcKqGYO6EyzlDq1tlO7jog28x8oDfz6W6KyXRL3evpqn/Mb Y1B3anULsxbOMPN1hXcgBIA11SOdCCIe5zifldeAn1CCq3hMVxmIyH04dpVq9eBp p7QpA+4KDLGwoXMYDL1dlL8kK0bCIWUB5FIFcJrBfcPYhv0FduX736NzufRvncc= =ZSMa -----END PGP SIGNATURE----- --------------020705030408060006020301 Content-Type: text/x-patch; name="cpu_throttle.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cpu_throttle.diff" Index: sys/dev/acpica/acpi_throttle.c =================================================================== --- sys/dev/acpica/acpi_throttle.c (revision 258002) +++ sys/dev/acpica/acpi_throttle.c (working copy) @@ -167,7 +167,7 @@ static int acpi_throttle_probe(device_t dev) { - if (resource_disabled("acpi_throttle", 0)) + if (!resource_enabled("acpi_throttle", 0)) return (ENXIO); /* @@ -177,7 +177,7 @@ acpi_throttle_probe(device_t dev) * we disable acpi_throttle when p4tcc is also present. */ if (device_find_child(device_get_parent(dev), "p4tcc", -1) && - !resource_disabled("p4tcc", 0)) + resource_ensabled("p4tcc", 0)) return (ENXIO); device_set_desc(dev, "ACPI CPU Throttling"); Index: sys/kern/subr_hints.c =================================================================== --- sys/kern/subr_hints.c (revision 258002) +++ sys/kern/subr_hints.c (working copy) @@ -449,15 +449,29 @@ resource_find_dev(int *anchor, const char *name, i } /* - * Check to see if a device is disabled via a disabled hint. + * Check to see if a device is disabled or enabled via a hint. */ -int -resource_disabled(const char *name, int unit) +static __inline int +resource_find_hint(const char *name, int unit, const char *hint) { int error, value; - error = resource_int_value(name, unit, "disabled", &value); + error = resource_int_value(name, unit, hint, &value); if (error) return (0); return (value); } + +int +resource_disabled(const char *name, int unit) +{ + + return (resource_find_hint(name, unit, "disabled")); +} + +int +resource_enabled(const char *name, int unit) +{ + + return (resource_find_hint(name, unit, "enabled")); +} Index: sys/sys/bus.h =================================================================== --- sys/sys/bus.h (revision 258002) +++ sys/sys/bus.h (working copy) @@ -503,6 +503,7 @@ int resource_long_value(const char *name, int unit int resource_string_value(const char *name, int unit, const char *resname, const char **result); int resource_disabled(const char *name, int unit); +int resource_enabled(const char *name, int unit); int resource_find_match(int *anchor, const char **name, int *unit, const char *resname, const char *value); int resource_find_dev(int *anchor, const char *name, int *unit, Index: sys/x86/cpufreq/p4tcc.c =================================================================== --- sys/x86/cpufreq/p4tcc.c (revision 258002) +++ sys/x86/cpufreq/p4tcc.c (working copy) @@ -142,7 +142,7 @@ static int p4tcc_probe(device_t dev) { - if (resource_disabled("p4tcc", 0)) + if (!resource_enabled("p4tcc", 0)) return (ENXIO); device_set_desc(dev, "CPU Frequency Thermal Control"); --------------020705030408060006020301-- From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 11 20:26:59 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 ESMTP id E9C03265; Mon, 11 Nov 2013 20:26:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B3B0247C; Mon, 11 Nov 2013 20:26:59 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id k4so2284290qaq.14 for ; Mon, 11 Nov 2013 12:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k7gemk13PdTb39JsuAkT1a27y2gDUFVBvsd2nCd6CJw=; b=YaG8zdyc1IxgXPzKEUdzfW5UB/EmJDzvx3nljlzxsvEYiJop6An7YPYwLQhqXJwxG1 Jzfo1kzqmOwIA3mmZZ2FLwiDkXy1fHBnENHV6PwJQgruc2VWdOuI2lHzohcQvybRLyom +wUq2MjyxfEVlvgYJr7BuOWLoIDKY3DnQnLj4L5+8W6hy0w+oSd/PgSR+w/aK0sM/rBL yoPyg6IOpqHQJorDAiY9u/Wr2vsWoo/laqY6O/FkQywOVrSI6/2L35fDIksdodnBBZY4 kfprCTItp1RbunXF10gzDARBytyz4g9zIcdTEbdFAuSZrMOLYFDR65ryTKbCaUKRV9w5 oTCA== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr51967496qac.98.1384201618790; Mon, 11 Nov 2013 12:26:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 11 Nov 2013 12:26:58 -0800 (PST) In-Reply-To: <5281374F.7080802@FreeBSD.org> References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org> Date: Mon, 11 Nov 2013 12:26:58 -0800 X-Google-Sender-Auth: YELKFqtWClRj8hBQm7vQZHq6me0 Message-ID: Subject: Re: Re: Problems with amd FX 8 core and freq scaling From: Adrian Chadd To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:27:00 -0000 On 11 November 2013 12:00, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: >> But wouldn't this just disable frequency scaling and the whole >> point of powerd? > > No. acpi_throttle (and p4tcc) controls T-state. "Frequency scaling" > should be done by changing P-state. Right. IIRC, T-state is just for emergency temperature throttling. It shouldn't be used outside of that. >>> There have been a number of reports of throttling causing >>> crashes. This setting does not prevent powerd from adjusting >>> your CPU's clock, it just disables some arcane feature which >>> pre-dates the modern power management methods. .. did anyone ever figure out why crashes would be caused by T-state adjustment? > I rewrote acpi_throttle.c at some point to fix the problem but never > committed it because nobody was really interested in testing the > patch. Also, it is really an arcane and archaic feature: > > http://software.intel.com/en-us/blogs/2013/10/15/c-states-p-states-where-the-heck-are-those-t-states > > Now I think we should disable the feature by default because it is > causing too much hassle for us (attached). Any objection? No, I think we should correctly identify which particular features are required for which particular CPUs and enable/disable it based on that. So, if it's relevant for P4 era hardware, let's default to having it on for that class hardware. If it's not relevant for core and core 2 (and later) hardware, then let's default to leaving it off for that. So, how about we come up with a table of CPUs and what particular power save technologies we should be using, then start implementing that? I'm reading the SDM bits on the adaptive frequency stuff (turbo boost, etc) and I'll see about writing up some data gathering knobs for the kernel. People still spin up FreeBSD on P4 (and earlier) class hardware. I'd rather we get it right versus just flipping crap on and off based on what 'current' hardware expects. I watched people do this with the RTC code. It's ridiculous. -adrian From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 11 21:35:09 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 6AD79BD6; Mon, 11 Nov 2013 21:35:09 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <52814CB2.6050204@FreeBSD.org> Date: Mon, 11 Nov 2013 16:31:30 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Problems with amd FX 8 core and freq scaling References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------000605010905020407030200" Cc: freebsd-acpi X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:35:09 -0000 This is a multi-part message in MIME format. --------------000605010905020407030200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote: > On 11 November 2013 12:00, Jung-uk Kim wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: >>> But wouldn't this just disable frequency scaling and the whole >>> point of powerd? >> >> No. acpi_throttle (and p4tcc) controls T-state. "Frequency >> scaling" should be done by changing P-state. > > Right. > > IIRC, T-state is just for emergency temperature throttling. It > shouldn't be used outside of that. > > >>>> There have been a number of reports of throttling causing >>>> crashes. This setting does not prevent powerd from adjusting >>>> your CPU's clock, it just disables some arcane feature which >>>> pre-dates the modern power management methods. > > .. did anyone ever figure out why crashes would be caused by > T-state adjustment? My memory is vague but I think it was not able to reject a broken FADT or _PTC table, or something like that. >> I rewrote acpi_throttle.c at some point to fix the problem but >> never committed it because nobody was really interested in >> testing the patch. Also, it is really an arcane and archaic >> feature: >> >> http://software.intel.com/en-us/blogs/2013/10/15/c-states-p-states-where-the-heck-are-those-t-states >> >> >> Now I think we should disable the feature by default because it is >> causing too much hassle for us (attached). Any objection? > > No, I think we should correctly identify which particular features > are required for which particular CPUs and enable/disable it based > on that. > > So, if it's relevant for P4 era hardware, let's default to having > it on for that class hardware. > > If it's not relevant for core and core 2 (and later) hardware, > then let's default to leaving it off for that. If you can maintain p4tcc for Intel processors, I am okay with that. However, I still want to disable acpi_throttle by default. In fact, I've never seen any non-Intel processor and/or motherboard with correct BIOS to support T-state change. > So, how about we come up with a table of CPUs and what particular > power save technologies we should be using, then start > implementing that? Please see p4tcc.c. It already has a quirk table based on CPUID. You just have to maintain it properly. > I'm reading the SDM bits on the adaptive frequency stuff (turbo > boost, etc) and I'll see about writing up some data gathering knobs > for the kernel. Cool. BTW, please don't forget AMD users, i.e., check the BKDGs. http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/ > People still spin up FreeBSD on P4 (and earlier) class hardware. > I'd rather we get it right versus just flipping crap on and off > based on what 'current' hardware expects. I watched people do this > with the RTC code. It's ridiculous. Please see the attached patch, i.e., I reverted p4tcc-specific changes. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJSgUyyAAoJEHyflib82/FGfLoH/2jejB55Eqtj134Z71bi75MA YUCZ2z5r2PoDN5PUsJeHqyv5EyEWteYlAxLKr/mvV5rbaIk1Wlg0+6c4U7rH99Qj +QpkS1GFL4XQFlKM8pFJ55VxQAYmUVwGCRGJxtxl0z6J6GvCIByKopqV3ywy04eG LcxjML2Kka0FU5UmFKqjy/2j9jBBClEYfynSeVqpjc+REK970oZFMjblQqtLSNsf GKhVwuFwaQYyZZylBTyEZh5fD7346jtA5G/mtSqjKJN2dY6nI5hIqqSWpXulLOEC N16jqUWswO8hE8ZpgVeFSAmkznP4ITHsSjuxQgU4pyTdnF1DiOmizA7Snjekyvs= =S1SR -----END PGP SIGNATURE----- --------------000605010905020407030200 Content-Type: text/x-patch; name="cpu_throttle2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cpu_throttle2.diff" Index: sys/dev/acpica/acpi_throttle.c =================================================================== --- sys/dev/acpica/acpi_throttle.c (revision 258002) +++ sys/dev/acpica/acpi_throttle.c (working copy) @@ -167,7 +167,7 @@ static int acpi_throttle_probe(device_t dev) { - if (resource_disabled("acpi_throttle", 0)) + if (!resource_enabled("acpi_throttle", 0)) return (ENXIO); /* Index: sys/kern/subr_hints.c =================================================================== --- sys/kern/subr_hints.c (revision 258002) +++ sys/kern/subr_hints.c (working copy) @@ -449,15 +449,29 @@ resource_find_dev(int *anchor, const char *name, i } /* - * Check to see if a device is disabled via a disabled hint. + * Check to see if a device is disabled or enabled via a hint. */ -int -resource_disabled(const char *name, int unit) +static __inline int +resource_find_hint(const char *name, int unit, const char *hint) { int error, value; - error = resource_int_value(name, unit, "disabled", &value); + error = resource_int_value(name, unit, hint, &value); if (error) return (0); return (value); } + +int +resource_disabled(const char *name, int unit) +{ + + return (resource_find_hint(name, unit, "disabled")); +} + +int +resource_enabled(const char *name, int unit) +{ + + return (resource_find_hint(name, unit, "enabled")); +} Index: sys/sys/bus.h =================================================================== --- sys/sys/bus.h (revision 258002) +++ sys/sys/bus.h (working copy) @@ -503,6 +503,7 @@ int resource_long_value(const char *name, int unit int resource_string_value(const char *name, int unit, const char *resname, const char **result); int resource_disabled(const char *name, int unit); +int resource_enabled(const char *name, int unit); int resource_find_match(int *anchor, const char **name, int *unit, const char *resname, const char *value); int resource_find_dev(int *anchor, const char *name, int *unit, --------------000605010905020407030200-- From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 11 21:50:51 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 60EA4825; Mon, 11 Nov 2013 21:50:51 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <52815060.9050406@FreeBSD.org> Date: Mon, 11 Nov 2013 16:47:12 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Problems with amd FX 8 core and freq scaling References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org> <52814CB2.6050204@FreeBSD.org> In-Reply-To: <52814CB2.6050204@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------020906000405080104050504" Cc: freebsd-acpi X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:50:51 -0000 This is a multi-part message in MIME format. --------------020906000405080104050504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-11 16:31:30 -0500, Jung-uk Kim wrote: > On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote: >> On 11 November 2013 12:00, Jung-uk Kim wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: >>>> But wouldn't this just disable frequency scaling and the >>>> whole point of powerd? >>> >>> No. acpi_throttle (and p4tcc) controls T-state. "Frequency >>> scaling" should be done by changing P-state. > >> Right. > >> IIRC, T-state is just for emergency temperature throttling. It >> shouldn't be used outside of that. > > >>>>> There have been a number of reports of throttling causing >>>>> crashes. This setting does not prevent powerd from >>>>> adjusting your CPU's clock, it just disables some arcane >>>>> feature which pre-dates the modern power management >>>>> methods. > >> .. did anyone ever figure out why crashes would be caused by >> T-state adjustment? > > My memory is vague but I think it was not able to reject a broken > FADT or _PTC table, or something like that. Just in case, here I attached the uncommitted (and untested) patch. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJSgVBgAAoJEHyflib82/FGACsIAJGDQGOYYO8dxvtQMw4BBnzl BNbFkvalvHOzaSezJz+A4R0zeIMvkfJtu0Gb8qiTkxJF+REREFo6a7lmzC7hOMwa 7PzRRRG34rtmnnHJro3Wc5qQwc1zBbmyFgYEJ45AkmIc62mpp9f0sZyNA1+aSpau 2sY6H0dXktapc2pLR1uNyxfUlr1tRhoabceGSlGLYiB583FrMsvASkaTnuWQ2IfI gytrJBKjMihu60KlwKauzUOVDrEuN3J/B1y7V/TrTXmcFmWgL9Wdw/gC7ToRdloT JdF812Duj/xYvyoNEwkz1Rm0NT5r1ZTYqwMvkOPuMfK7IWX0O9UFO8VG+QnJXhU= =/d/E -----END PGP SIGNATURE----- --------------020906000405080104050504 Content-Type: text/x-patch; name="acpi_throttle.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_throttle.diff" Index: sys/dev/acpica/acpi_throttle.c =================================================================== --- sys/dev/acpica/acpi_throttle.c (revision 258019) +++ sys/dev/acpica/acpi_throttle.c (working copy) @@ -54,14 +54,24 @@ __FBSDID("$FreeBSD$"); * absolute cpufreq drivers. We support the ACPI 2.0 specification. */ +struct acpi_tx { + uint32_t percent; + uint32_t power; + uint32_t trans_lat; + uint32_t ctrl_val; + uint32_t sts_val; +}; + struct acpi_throttle_softc { device_t cpu_dev; ACPI_HANDLE cpu_handle; uint32_t cpu_p_blk; /* ACPI P_BLK location */ uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */ + uint32_t cpu_p_mask; /* P_BLK mask for clock value */ + uint32_t cpu_tx_count; /* Total number of throttle states. */ + struct acpi_tx *cpu_tx_states; /* ACPI throttle states */ struct resource *cpu_p_cnt; /* Throttling control register */ - int cpu_p_type; /* Resource type for cpu_p_cnt. */ - uint32_t cpu_thr_state; /* Current throttle setting. */ + struct resource *cpu_p_sts; /* Throttling status register */ }; #define THR_GET_REG(reg) \ @@ -75,10 +85,6 @@ struct acpi_throttle_softc { * Speeds are stored in counts, from 1 to CPU_MAX_SPEED, and * reported to the user in hundredths of a percent. */ -#define CPU_MAX_SPEED (1 << cpu_duty_width) -#define CPU_SPEED_PERCENT(x) ((10000 * (x)) / CPU_MAX_SPEED) -#define CPU_SPEED_PRINTABLE(x) (CPU_SPEED_PERCENT(x) / 10), \ - (CPU_SPEED_PERCENT(x) % 10) #define CPU_P_CNT_THT_EN (1<<4) #define CPU_QUIRK_NO_THROTTLE (1<<1) /* Throttling is not usable. */ @@ -89,7 +95,6 @@ struct acpi_throttle_softc { static uint32_t cpu_duty_offset; /* Offset in P_CNT of throttle val. */ static uint32_t cpu_duty_width; /* Bit width of throttle value. */ -static int thr_rid; /* Driver-wide resource id. */ static int thr_quirks; /* Indicate any hardware bugs. */ static void acpi_throttle_identify(driver_t *driver, device_t parent); @@ -127,6 +132,8 @@ static devclass_t acpi_throttle_devclass; DRIVER_MODULE(acpi_throttle, cpu, acpi_throttle_driver, acpi_throttle_devclass, 0, 0); +static MALLOC_DEFINE(M_ACPITHR, "acpi_throttle", "ACPI Throttling states"); + static void acpi_throttle_identify(driver_t *driver, device_t parent) { @@ -133,6 +140,9 @@ acpi_throttle_identify(driver_t *driver, device_t ACPI_BUFFER buf; ACPI_HANDLE handle; ACPI_OBJECT *obj; + ACPI_IO_ADDRESS addr; + ACPI_STATUS status; + UINT32 len; /* Make sure we're not being doubly invoked. */ if (device_find_child(parent, "acpi_throttle", -1)) @@ -155,12 +165,16 @@ acpi_throttle_identify(driver_t *driver, device_t if (ACPI_FAILURE(AcpiEvaluateObject(handle, NULL, NULL, &buf))) return; obj = (ACPI_OBJECT *)buf.Pointer; - if ((obj->Processor.PblkAddress && obj->Processor.PblkLength >= 4) || - ACPI_SUCCESS(AcpiEvaluateObject(handle, "_PTC", NULL, NULL))) { - if (BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1) == NULL) - device_printf(parent, "add throttle child failed\n"); + addr = obj->Processor.PblkAddress; + len = obj->Processor.PblkLength; + AcpiOsFree(obj); + if (addr == 0 || len < 4) { + status = AcpiEvaluateObject(handle, "_PTC", NULL, NULL); + if (ACPI_FAILURE(status)) + return; } - AcpiOsFree(obj); + if (BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1) == NULL) + device_printf(parent, "add throttle child failed\n"); } static int @@ -235,10 +249,13 @@ acpi_throttle_attach(device_t dev) static int acpi_throttle_evaluate(struct acpi_throttle_softc *sc) { - uint32_t duty_end; ACPI_BUFFER buf; - ACPI_OBJECT obj; ACPI_GENERIC_ADDRESS gas; + ACPI_OBJECT *pkg, *res; + struct acpi_tx *states; + uint32_t *p; + uint32_t clk_val, count, duty_end, i, j, speed; + int error, once, rid, type; ACPI_STATUS status; /* Get throttling parameters from the FADT. 0 means not supported. */ @@ -262,6 +279,9 @@ acpi_throttle_evaluate(struct acpi_throttle_softc return (ENXIO); } + sc->cpu_p_mask = ((1 << cpu_duty_width) - 1) << cpu_duty_offset; + sc->cpu_p_mask |= CPU_P_CNT_THT_EN; + /* * If not present, fall back to using the processor's P_BLK to find * the P_CNT register. @@ -269,25 +289,52 @@ acpi_throttle_evaluate(struct acpi_throttle_softc * Note that some systems seem to duplicate the P_BLK pointer * across multiple CPUs, so not getting the resource is not fatal. */ - buf.Pointer = &obj; - buf.Length = sizeof(obj); + error = 1; + rid = 0; + buf.Pointer = NULL; + buf.Length = ACPI_ALLOCATE_BUFFER; status = AcpiEvaluateObject(sc->cpu_handle, "_PTC", NULL, &buf); if (ACPI_SUCCESS(status)) { - if (obj.Buffer.Length < sizeof(ACPI_GENERIC_ADDRESS) + 3) { - device_printf(sc->cpu_dev, "_PTC buffer too small\n"); - return (ENXIO); + pkg = (ACPI_OBJECT *)buf.Pointer; + for (i = 0; i > 2; i++) { + res = &pkg->Package.Elements[i]; + if (res->Buffer.Length < sizeof(gas) + 3) { + device_printf(sc->cpu_dev, + "_PTC buffer too small\n"); + AcpiOsFree(pkg); + return (ENXIO); + } } - memcpy(&gas, obj.Buffer.Pointer + 3, sizeof(gas)); - acpi_bus_alloc_gas(sc->cpu_dev, &sc->cpu_p_type, &thr_rid, - &gas, &sc->cpu_p_cnt, 0); - if (sc->cpu_p_cnt != NULL && bootverbose) { - device_printf(sc->cpu_dev, "P_CNT from _PTC %#jx\n", - gas.Address); + res = &pkg->Package.Elements[0]; + memcpy(&gas, res->Buffer.Pointer + 3, sizeof(gas)); + error = acpi_bus_alloc_gas(sc->cpu_dev, &type, &rid, &gas, + &sc->cpu_p_cnt, 0); + if (error == 0) { + if (bootverbose) + device_printf(sc->cpu_dev, + "P_CNT from _PTC %#jx\n", + (uintmax_t)gas.Address); + rid++; + res = &pkg->Package.Elements[1]; + if (memcmp(res->Buffer.Pointer + 3, &gas, + sizeof(gas)) != 0) { + memcpy(&gas, res->Buffer.Pointer + 3, + sizeof(gas)); + error = acpi_bus_alloc_gas(sc->cpu_dev, &type, + &rid, &gas, &sc->cpu_p_sts, 0); + if (error != 0) { + device_printf(sc->cpu_dev, + "failed to allocate resource for status register %#jx\n", + (uintmax_t)gas.Address); + error = 0; /* XXX fatal? */ + } + } } + AcpiOsFree(pkg); } /* If _PTC not present or other failure, try the P_BLK. */ - if (sc->cpu_p_cnt == NULL) { + if (error != 0) { /* * The spec says P_BLK must be 6 bytes long. However, some * systems use it to indicate a fractional set of features @@ -298,19 +345,84 @@ acpi_throttle_evaluate(struct acpi_throttle_softc gas.Address = sc->cpu_p_blk; gas.SpaceId = ACPI_ADR_SPACE_SYSTEM_IO; gas.BitWidth = 32; - acpi_bus_alloc_gas(sc->cpu_dev, &sc->cpu_p_type, &thr_rid, - &gas, &sc->cpu_p_cnt, 0); - if (sc->cpu_p_cnt != NULL) { - if (bootverbose) - device_printf(sc->cpu_dev, - "P_CNT from P_BLK %#x\n", sc->cpu_p_blk); - } else { + if (acpi_bus_alloc_gas(sc->cpu_dev, &type, &rid, &gas, + &sc->cpu_p_cnt, 0) != 0) { device_printf(sc->cpu_dev, "failed to attach P_CNT\n"); return (ENXIO); + } else if (bootverbose) + device_printf(sc->cpu_dev, "P_CNT from P_BLK %#x\n", + sc->cpu_p_blk); + } + + /* + * If status register is not present, assume P_CNT returns + * the current status. + */ + if (sc->cpu_p_sts == NULL) + sc->cpu_p_sts = sc->cpu_p_cnt; + + count = 0; + buf.Pointer = NULL; + buf.Length = ACPI_ALLOCATE_BUFFER; + status = AcpiEvaluateObject(sc->cpu_handle, "_TSS", NULL, &buf); + if (ACPI_SUCCESS(status)) { + pkg = (ACPI_OBJECT *)buf.Pointer; + count = pkg->Package.Count; + states = malloc(count * sizeof(*states), M_ACPITHR, + M_WAITOK | M_ZERO); + once = 1; + for (i = 0; i < count; i++) { + res = &pkg->Package.Elements[i]; + if (!ACPI_PKG_VALID(res, 5) && once) { + once = 0; + device_printf(sc->cpu_dev, + "invalid _TSS package\n"); + continue; + } + p = &sc->cpu_tx_states[sc->cpu_tx_count].percent; + for (j = 0; j < 5; j++, p++) + acpi_PkgInt32(res, j, p); + if (sc->cpu_tx_states[sc->cpu_tx_count].percent > 100 && + once) { + once = 0; + device_printf(sc->cpu_dev, + "invalid _TSS package\n"); + continue; + } + sc->cpu_tx_states[sc->cpu_tx_count].percent *= 100; + sc->cpu_tx_count++; } + if (sc->cpu_tx_count > 0) + sc->cpu_tx_states = states; + else + free(states, M_ACPITHR); + AcpiOsFree(pkg); } - thr_rid++; + if (sc->cpu_tx_count > 0) + return (0); + + /* If _TSS is not present or other failure, create it. */ + count = (1 << cpu_duty_width) - 1; + states = malloc(count * sizeof(*states), M_ACPITHR, M_WAITOK | M_ZERO); + for (i = 0; i < count; i++) { + speed = count - i; + clk_val = speed << cpu_duty_offset; + if (i != 0) + clk_val |= CPU_P_CNT_THT_EN; + states[i].percent = speed * 10000 / count; + states[i].ctrl_val = states[i].sts_val = clk_val; + } + sc->cpu_tx_states = states; + sc->cpu_tx_count = count; + + if (bootverbose) + for (i = 0; i < count; i++) + device_printf(sc->cpu_dev, + "%u: %u.%02u %%, control %u, status %u\n", i, + states[i].percent / 100, states[i].percent % 100, + states[i].ctrl_val, states[i].sts_val); + return (0); } @@ -346,20 +458,24 @@ acpi_throttle_quirks(struct acpi_throttle_softc *s static int acpi_thr_settings(device_t dev, struct cf_setting *sets, int *count) { - int i, speed; + struct acpi_throttle_softc *sc; + int i; if (sets == NULL || count == NULL) return (EINVAL); - if (*count < CPU_MAX_SPEED) + sc = device_get_softc(dev); + if (*count < sc->cpu_tx_count) return (E2BIG); /* Return a list of valid settings for this driver. */ - memset(sets, CPUFREQ_VAL_UNKNOWN, sizeof(*sets) * CPU_MAX_SPEED); - for (i = 0, speed = CPU_MAX_SPEED; speed != 0; i++, speed--) { - sets[i].freq = CPU_SPEED_PERCENT(speed); + memset(sets, CPUFREQ_VAL_UNKNOWN, sizeof(*sets) * sc->cpu_tx_count); + for (i = 0; i < sc->cpu_tx_count; i++) { + sets[i].freq = sc->cpu_tx_states[i].percent; + sets[i].power = sc->cpu_tx_states[i].power; + sets[i].lat = sc->cpu_tx_states[i].trans_lat; sets[i].dev = dev; } - *count = CPU_MAX_SPEED; + *count = sc->cpu_tx_count; return (0); } @@ -368,44 +484,38 @@ static int acpi_thr_set(device_t dev, const struct cf_setting *set) { struct acpi_throttle_softc *sc; - uint32_t clk_val, p_cnt, speed; + struct acpi_tx *state; + uint32_t p_cnt; + int i; if (set == NULL) return (EINVAL); sc = device_get_softc(dev); - /* - * Validate requested state converts to a duty cycle that is an - * integer from [1 .. CPU_MAX_SPEED]. - */ - speed = set->freq * CPU_MAX_SPEED / 10000; - if (speed * 10000 != set->freq * CPU_MAX_SPEED || - speed < 1 || speed > CPU_MAX_SPEED) + /* Validate requested state. */ + state = NULL; + for (i = 0; i < sc->cpu_tx_count; i++) + if (set->freq == sc->cpu_tx_states[i].percent) { + state = &sc->cpu_tx_states[i]; + break; + } + if (state == NULL) return (EINVAL); + p_cnt = THR_GET_REG(sc->cpu_p_cnt); + /* If we're at this setting, don't bother applying it again. */ - if (speed == sc->cpu_thr_state) + if (state->ctrl_val == (p_cnt & sc->cpu_p_mask)) return (0); - /* Get the current P_CNT value and disable throttling */ - p_cnt = THR_GET_REG(sc->cpu_p_cnt); - p_cnt &= ~CPU_P_CNT_THT_EN; + /* Write the new P_CNT value. */ + p_cnt = (p_cnt & ~sc->cpu_p_mask) | state->ctrl_val; THR_SET_REG(sc->cpu_p_cnt, p_cnt); - /* If we're at maximum speed, that's all */ - if (speed < CPU_MAX_SPEED) { - /* Mask the old CLK_VAL off and OR in the new value */ - clk_val = (CPU_MAX_SPEED - 1) << cpu_duty_offset; - p_cnt &= ~clk_val; - p_cnt |= (speed << cpu_duty_offset); + if (bootverbose) + device_printf(dev, "set %u.%02u %%\n", + set->freq / 100, set->freq % 100); - /* Write the new P_CNT value and then enable throttling */ - THR_SET_REG(sc->cpu_p_cnt, p_cnt); - p_cnt |= CPU_P_CNT_THT_EN; - THR_SET_REG(sc->cpu_p_cnt, p_cnt); - } - sc->cpu_thr_state = speed; - return (0); } @@ -413,21 +523,28 @@ static int acpi_thr_get(device_t dev, struct cf_setting *set) { struct acpi_throttle_softc *sc; - uint32_t p_cnt, clk_val; + uint32_t clk_val, i; if (set == NULL) return (EINVAL); sc = device_get_softc(dev); - /* Get the current throttling setting from P_CNT. */ - p_cnt = THR_GET_REG(sc->cpu_p_cnt); - clk_val = (p_cnt >> cpu_duty_offset) & (CPU_MAX_SPEED - 1); - sc->cpu_thr_state = clk_val; + /* Get the current throttling setting. */ + clk_val = THR_GET_REG(sc->cpu_p_sts) & sc->cpu_p_mask; + for (i = 0; i < sc->cpu_tx_count; i++) + if (clk_val == sc->cpu_tx_states[i].sts_val) + break; + if (i >= sc->cpu_tx_count) + return (ENXIO); memset(set, CPUFREQ_VAL_UNKNOWN, sizeof(*set)); - set->freq = CPU_SPEED_PERCENT(clk_val); + set->freq = sc->cpu_tx_states[i].percent; set->dev = dev; + if (bootverbose) + device_printf(dev, "got %u.%02u %%\n", + set->freq / 100, set->freq % 100); + return (0); } --------------020906000405080104050504-- From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 12 02:08:28 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DD2F502 for ; Tue, 12 Nov 2013 02:08:28 +0000 (UTC) Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34EE23696 for ; Tue, 12 Nov 2013 02:08:28 +0000 (UTC) Received: from [98.139.212.153] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 12 Nov 2013 02:02:01 -0000 Received: from [98.139.211.193] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 12 Nov 2013 02:02:01 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 12 Nov 2013 02:02:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1384221721; bh=gPU6/Om76OpUTFZzTJq2NLiyvdVeVHL+GyufxKsZ3pA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=BAGctoP3Zbrxlkkfx4YXJksZro2SXlliR7oRpox9zTnjXa77l9vFJ4jaLdsZVgGe7wai8e2UX0ZHLX5YWqUy9iqFwT7qSw+9bnNB94eaCz4yWVQ1FOH7zDIQLoJCmDpclHw9Qu5LD665M1/DN0tKPndOp4WJecfzZ9Mab5CAtBA= X-Yahoo-Newman-Id: 895358.89361.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GXo8EpAVM1kfP.9tJkpqbtElSgnFVnWZ0vErVTrxHHKA_SF FhZReOG2ulAbXG1PVeRZnqgvEQpSF_hSW5GHwm0HLIdoM.kXdP7KO4smlKwf Ya5e_O_WdXC6thFvboMOXt.bffrb0gazSbgUzzhADbsVFa5wSTAvw5dVfxHA M_d4V2QjfqsZgWkkgTVQwBlSAjp1EiEWyfT8pSjL0K4FgNn7mGpE_Ce.sbDl GbDd.mLc8KhiZNIK1iFdtmhFgO9X8he1r..r6XUGdii8Gx5BCh.HTyREVURk a9Xggd2S_bx7tAI0bhcLfJnALzxS.dLPsCERjEsTrS1_4N3UQKsy2R.ZVZWZ qoCejnaSXijEcSZxVdqohHyT1rMQ5tErOkP1.jr68IFCtpOIDQcx44fJEJYz nTNAtvRSXtwrPSgtyIiwtPAViuO3LB.zgjyG3TzOiopPOQbl8A9dXpB_wlZE lRk28L.hVwUpkRvagkJSsyVDAsZsH.uTw8w5tHuBJmwJjDXnpaW0porRYHiF mhylqC_xf_T4OTA2OvnIlN7n6oU81pET1BoTAyWxqF.91rm4lXpswXXYSdZ8 ZWA-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp202.mail.bf1.yahoo.com with SMTP; 11 Nov 2013 18:02:01 -0800 PST Subject: Re: Problems with amd FX 8 core and freq scaling From: Sean Bruno To: Jung-uk Kim In-Reply-To: <52815060.9050406@FreeBSD.org> References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org> <52814CB2.6050204@FreeBSD.org> <52815060.9050406@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4Wnwq74W0z5eDBp7dIPB" Date: Mon, 11 Nov 2013 18:02:00 -0800 Message-ID: <1384221720.1748.53.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-acpi X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: sbruno@freebsd.org List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:08:28 -0000 --=-4Wnwq74W0z5eDBp7dIPB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2013-11-11 at 16:47 -0500, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-11-11 16:31:30 -0500, Jung-uk Kim wrote: > > On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote: > >> On 11 November 2013 12:00, Jung-uk Kim wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>>=20 > >>> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: > >>>> But wouldn't this just disable frequency scaling and the > >>>> whole point of powerd? > >>>=20 > >>> No. acpi_throttle (and p4tcc) controls T-state. "Frequency=20 > >>> scaling" should be done by changing P-state. > >=20 > >> Right. > >=20 > >> IIRC, T-state is just for emergency temperature throttling. It=20 > >> shouldn't be used outside of that. > >=20 > >=20 > >>>>> There have been a number of reports of throttling causing=20 > >>>>> crashes. This setting does not prevent powerd from > >>>>> adjusting your CPU's clock, it just disables some arcane > >>>>> feature which pre-dates the modern power management > >>>>> methods. > >=20 > >> .. did anyone ever figure out why crashes would be caused by=20 > >> T-state adjustment? > >=20 > > My memory is vague but I think it was not able to reject a broken > > FADT or _PTC table, or something like that. >=20 > Just in case, here I attached the uncommitted (and untested) patch. >=20 > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) >=20 > iQEcBAEBAgAGBQJSgVBgAAoJEHyflib82/FGACsIAJGDQGOYYO8dxvtQMw4BBnzl > BNbFkvalvHOzaSezJz+A4R0zeIMvkfJtu0Gb8qiTkxJF+REREFo6a7lmzC7hOMwa > 7PzRRRG34rtmnnHJro3Wc5qQwc1zBbmyFgYEJ45AkmIc62mpp9f0sZyNA1+aSpau > 2sY6H0dXktapc2pLR1uNyxfUlr1tRhoabceGSlGLYiB583FrMsvASkaTnuWQ2IfI > gytrJBKjMihu60KlwKauzUOVDrEuN3J/B1y7V/TrTXmcFmWgL9Wdw/gC7ToRdloT > JdF812Duj/xYvyoNEwkz1Rm0NT5r1ZTYqwMvkOPuMfK7IWX0O9UFO8VG+QnJXhU=3D > =3D/d/E > -----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-unsubscribe@freebsd.org" Let me test this on my fx-8150 tonight. What should I look for as a test failure/success? sean --=-4Wnwq74W0z5eDBp7dIPB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQEcBAABAgAGBQJSgYwYAAoJEBkJRdwI6BaHG/QH/1u5cNNcy/CrM8Y1JNWG8guS 76NEW2XQjI0tF4THSqr7FlY6cGPjAZ3jY9hIUcXVmacZLrqYn8zhvwiz7UVCGiMK CMDVne8c3Dqr2FVjCFjrpHLhQIZsVuuYCeb4IgR9SrKPt4KMu1YK1zBYILEWZd+n Itqq/n9o9AQlFSHQgrrHBoOsm1+HsoWqlknn9nYiXIijYxxsqU4xzSORt/vW1UCF m9oJQMCcuTde5U4+0BzLgsEmht2X3z5re2YQXkfEggBYLowvXJPSAEmfveNF1YAd pIiKe73CYl46UBKUMN5uh2A++fXu5BYAhZrWCT0mFOU9IRQrfZHYawS/r9psUq4= =vWd2 -----END PGP SIGNATURE----- --=-4Wnwq74W0z5eDBp7dIPB-- From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 13 18:33:33 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AA84F19 for ; Wed, 13 Nov 2013 18:33:33 +0000 (UTC) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66D5D2642 for ; Wed, 13 Nov 2013 18:33:32 +0000 (UTC) Received: from [66.196.81.170] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2013 18:33:25 -0000 Received: from [98.139.211.199] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2013 18:33:25 -0000 Received: from [127.0.0.1] by smtp208.mail.bf1.yahoo.com with NNFMP; 13 Nov 2013 18:33:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1384367605; bh=vqhwsoPXbDwKlQujyq+kpZT9ExeBmA8H07MlJ9tI3L0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=jPJE8tEEqpfe2NvrhJzW7nDXZjXDvsoSmCMdHJaEybjcPACG4CO1Puzo50Yxy66HX00n2wdPcZBKuE4jSL3lRhx4J0e0bcA27UJXAJ9H0h9J7oNSh9K7cOUnR/2MD44Ld8oYMBq3enQK8ROSDkPCzJjbMZvxV4CjjaCgZclNKYA= X-Yahoo-Newman-Id: 558669.55594.bm@smtp208.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: n9kJ8P0VM1kWv2kg6ntQ3mOiuOrmFM_MI41A4Pgf7XYb4.x o.nZtkZ8m33EKisQMO29_lIDpqkqbw40379NwnRqG.6Ixv3d9L400OfvkWs1 RRnkUF1eCgpvraAnTpSraoLZQa5jh4qkAPyo456XbUA8XJ1ZZ.vKWIXvwJqr ef13W.VeIhvaeXy_TH.ZysA6d_ne9RgP_tBpeYrWzf0j5yk3jZd9TJ0tAUPg ubQcUhns6bcyapJsfKOFe.4oNo.0n0YjsEcBLmTNE.CyPGegYOmgtqs5oVFt 7UpIOCkZ.Tzt9MKkNeE2XUJR7Nu4wOJk2OJ7fGdXHZ5WY8kAMJTgiFoHnksE ZY9THn31lcUqojoBIDFJnCQpSBiUxF7GszflUnNUJBbFmJxCW5hxsM6AODNU lf60Ad5N.Qu.G0upS5CX7kHekMEpw_DLLU0dwU4zlJsRXGxSUozj.iZPuPfW E0nszqWWEiW5nZL1gW9WVxg0T_SApGXs58VaO.Om8QLaVW7W29Kk9tZ_.4Oj wXIp_xR6K1KFBjAYmlhPUT2YErWQlpXQs7f9d8Lqfy4B5zNtu8ZXLLw-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [192.168.100.228] (sean_bruno@24.23.220.111 with ) by smtp208.mail.bf1.yahoo.com with SMTP; 13 Nov 2013 10:33:25 -0800 PST Subject: Re: Problems with amd FX 8 core and freq scaling From: Sean Bruno To: Jung-uk Kim In-Reply-To: <52815060.9050406@FreeBSD.org> References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org> <52814CB2.6050204@FreeBSD.org> <52815060.9050406@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-z8O+z5GG8LCmkLGO1Kwu" Date: Wed, 13 Nov 2013 10:33:23 -0800 Message-ID: <1384367603.98053.0.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-acpi X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: sbruno@freebsd.org List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 18:33:33 -0000 --=-z8O+z5GG8LCmkLGO1Kwu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2013-11-11 at 16:47 -0500, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-11-11 16:31:30 -0500, Jung-uk Kim wrote: > > On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote: > >> On 11 November 2013 12:00, Jung-uk Kim wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>>=20 > >>> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: > >>>> But wouldn't this just disable frequency scaling and the > >>>> whole point of powerd? > >>>=20 > >>> No. acpi_throttle (and p4tcc) controls T-state. "Frequency=20 > >>> scaling" should be done by changing P-state. > >=20 > >> Right. > >=20 > >> IIRC, T-state is just for emergency temperature throttling. It=20 > >> shouldn't be used outside of that. > >=20 > >=20 > >>>>> There have been a number of reports of throttling causing=20 > >>>>> crashes. This setting does not prevent powerd from > >>>>> adjusting your CPU's clock, it just disables some arcane > >>>>> feature which pre-dates the modern power management > >>>>> methods. > >=20 > >> .. did anyone ever figure out why crashes would be caused by=20 > >> T-state adjustment? > >=20 > > My memory is vague but I think it was not able to reject a broken > > FADT or _PTC table, or something like that. >=20 > Just in case, here I attached the uncommitted (and untested) patch. >=20 > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) >=20 > iQEcBAEBAgAGBQJSgVBgAAoJEHyflib82/FGACsIAJGDQGOYYO8dxvtQMw4BBnzl > BNbFkvalvHOzaSezJz+A4R0zeIMvkfJtu0Gb8qiTkxJF+REREFo6a7lmzC7hOMwa > 7PzRRRG34rtmnnHJro3Wc5qQwc1zBbmyFgYEJ45AkmIc62mpp9f0sZyNA1+aSpau > 2sY6H0dXktapc2pLR1uNyxfUlr1tRhoabceGSlGLYiB583FrMsvASkaTnuWQ2IfI > gytrJBKjMihu60KlwKauzUOVDrEuN3J/B1y7V/TrTXmcFmWgL9Wdw/gC7ToRdloT > JdF812Duj/xYvyoNEwkz1Rm0NT5r1ZTYqwMvkOPuMfK7IWX0O9UFO8VG+QnJXhU=3D > =3D/d/E > -----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-unsubscribe@freebsd.org" Up and running this patch now on my FX-8150. Anything interesting that I should gather report? sean --=-z8O+z5GG8LCmkLGO1Kwu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQEcBAABAgAGBQJSg8XsAAoJEBkJRdwI6BaHYV0H/R0NCo8t6MFFWSi8dTWFoTnN cDN6BEmE3BFhBc3nDPUuhitm1xwivPU68x+g+UBnSbcdDCmBk2K2zwpfTZREk2gI elc7boh3Z4WA0qA0M6M+9OnICe35jEDX+rtmSmfJM0xFLRu2b76ZV8WfYq20EMHn n0Nd7ssLgoPIcuPCiqsy8FZwo0ioB4MIqBu8bL8R3VdRotJDTWpqEektxmFz9ndI cYoMLjmSOVEfXK20Rn4mTwNXZ0jHOi9zWAHnG/IAWU2ZnBpCQ/YW/iRrJ6TNhkaC bIcLZ6Xwy+Blvp7CMwHfuvXA5TUncNM6YgzpsNK8VBW4Jsb/NkNzBYP/AU6ecCg= =sdhd -----END PGP SIGNATURE----- --=-z8O+z5GG8LCmkLGO1Kwu-- From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 13 23:21:38 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84E71AF0; Wed, 13 Nov 2013 23:21:38 +0000 (UTC) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 387DA2978; Wed, 13 Nov 2013 23:21:38 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id df13so773675qeb.29 for ; Wed, 13 Nov 2013 15:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9aTVIhivI4vKVG6QkeWXusvW8i3O5oXflxARGWb3uOY=; b=xfo4LIZ9i6C39BDc+8xcsHE7wkjvVusR+C4YQ4VMqq+MNNVSAswF/K9WgnhJK549hA Vn4VtEvUE1smHBMpsAnOW6fQVqWeTmcWOJMvgZw1cyz9TNozLfm0Onqf5ht+ifh0yTMS JmyzkXbuA7rfNlpt/1CkhxiWqriLIARmX72WNTycDeIxuyLrF0tn0ISJSMojOp45/r6G EVctWW2oBshcZF0W2uZlVAMEs7Sz5bhQDGduCjXbDdPE+jCOmlTVmcTaX62LiWMqOeCU Krxiu2CWe4kXj12duknFGx6BfDJkwz7RFWTYKKWlI+x03MHW8z0W0hs5i5Gb0/UItUxX 03Ng== MIME-Version: 1.0 X-Received: by 10.224.98.200 with SMTP id r8mr72205788qan.26.1384384897292; Wed, 13 Nov 2013 15:21:37 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Wed, 13 Nov 2013 15:21:37 -0800 (PST) In-Reply-To: <52815060.9050406@FreeBSD.org> References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org> <52814CB2.6050204@FreeBSD.org> <52815060.9050406@FreeBSD.org> Date: Wed, 13 Nov 2013 15:21:37 -0800 X-Google-Sender-Auth: OlLkeaQlJ3nVTRTWML2Pmg5JrNg Message-ID: Subject: Re: Problems with amd FX 8 core and freq scaling From: Adrian Chadd To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi 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: Wed, 13 Nov 2013 23:21:38 -0000 On 11 November 2013 13:47, Jung-uk Kim wrote: > Just in case, here I attached the uncommitted (and untested) patch. > Would you mind describing everything that this patch does? -adrian From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 13 23:39:09 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id A80BB2E3; Wed, 13 Nov 2013 23:39:09 +0000 (UTC) Message-ID: <52840CB7.1090102@FreeBSD.org> Date: Wed, 13 Nov 2013 18:35:19 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Problems with amd FX 8 core and freq scaling References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org> <52814CB2.6050204@FreeBSD.org> <52815060.9050406@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi 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: Wed, 13 Nov 2013 23:39:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-13 18:21:37 -0500, Adrian Chadd wrote: > On 11 November 2013 13:47, Jung-uk Kim wrote: > >> Just in case, here I attached the uncommitted (and untested) >> patch. >> > > Would you mind describing everything that this patch does? The patch was written few years ago to fix crashes. However, I don't remember too much detail any more, sorry. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJShAy3AAoJEHyflib82/FGs6UH/0/1pwz/08hGRqq8WiTqDebI SrFaYD/JKMTLGyij+b+WoOrPpVPNN/+q+ebsKQ4kCUTctnQgnzUqnW4VfkKXBRe4 jSjA02Wu0EhkAweIe22WLnuURst5oL+0/5YF3DEPyCexQZyiMiY0bfCLKZuRibJ0 GHSUT9zfHPPMktwYhQMNxwrnQqQ0O7IxKirmsCksm/Vo7vwbIo8Q2lUJh3nfN5KR MikgAf7x1jdwfEhfqTrXOk1NISFLw1O3uQ0qQWf1tHBeUOGZ76nvUxE/MGaIL2iG RpHRyTySri6iXMXMBfdCYtMmdvMs3NFznk6+tNQ4bXPNS0OXboRQGbZjueiToIY= =sIFq -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 14 22:41:45 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 B8598E17; Thu, 14 Nov 2013 22:41:45 +0000 (UTC) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C184245D; Thu, 14 Nov 2013 22:41:45 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id x7so1779702qeu.0 for ; Thu, 14 Nov 2013 14:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=9To9cUgzO2FJ8qetx5PNiIta9m75FkykGMm4EDO/Jc4=; b=uZk6ZNlc2gJ9NYYAhSrUhY8Z5gPUJhI84hayIWa0E+jD6M448suZh36ogguS0t2Veb EDsY/1+Y1DF2KL7OQ1UnMbg7FytTyaia7pYROUfjHQQK3t2y+Q/6tdBSBQhPmpcv3oYF eVcP234586WjRzalKL3LLa/sqBtiM+fkSFok6qk+oSTvpxkoRwh2lJmTnqAfvwaL2+0n 82oQXSWOMHQTlpPlYgynNm0Sz3x3MD7p2EbU8L2+SEI7ZoQK1BAt4GcDxt3hVbUdGJyy hIHgdXCFMA5ItDfEHmgkn+zdguVk/Ix+7SurBRR3Qdpdpx/tCsbarUqCYmb2MwaZQB0t yABg== MIME-Version: 1.0 X-Received: by 10.49.71.207 with SMTP id x15mr5860791qeu.49.1384468904588; Thu, 14 Nov 2013 14:41:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 14 Nov 2013 14:41:44 -0800 (PST) Date: Thu, 14 Nov 2013 14:41:44 -0800 X-Google-Sender-Auth: LVUaLYaBtXzONy5OsS17fsqn2E0 Message-ID: Subject: P-state setting suddenly disappeared, what gives? From: Adrian Chadd To: Jung-uk Kim , "freebsd-acpi@freebsd.org" , njl@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 14 Nov 2013 22:41:45 -0000 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 From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 14 23:17:32 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 7184C13F; Thu, 14 Nov 2013 23:17:32 +0000 (UTC) Message-ID: <52855927.9010103@FreeBSD.org> Date: Thu, 14 Nov 2013 18:13:43 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , "freebsd-acpi@freebsd.org" , njl@freebsd.org Subject: Re: P-state setting suddenly disappeared, what gives? References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 14 Nov 2013 23:17:32 -0000 -----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----- From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 15 15:44:09 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 2E8EB45D; Fri, 15 Nov 2013 15:44:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09D9C21B0; Fri, 15 Nov 2013 15:44:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B7D61B91E; Fri, 15 Nov 2013 10:44:06 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: P-state setting suddenly disappeared, what gives? Date: Fri, 15 Nov 2013 09:17:12 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52855927.9010103@FreeBSD.org> In-Reply-To: <52855927.9010103@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201311150917.12998.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 15 Nov 2013 10:44:06 -0500 (EST) Cc: 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 15:44:09 -0000 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 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 From owner-freebsd-acpi@FreeBSD.ORG Sat Nov 16 18:40:25 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 55E93B12 for ; Sat, 16 Nov 2013 18:40:25 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E94D52EA7 for ; Sat, 16 Nov 2013 18:40:24 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u57so4259379wes.37 for ; Sat, 16 Nov 2013 10:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:to:date:mime-version:subject:message-id:priority:content-type :content-transfer-encoding:content-description; bh=RO7tUkdcsXmNVZfMNmbVwvN00BBEma4j34PkRRsCK94=; b=IRB/X+28WqWiaWscWeQbF7Kr2ahjrqF7jK3EgDCD65ntj3dchVfmJvwJTFlawSCKBd vs82hZj0d6ETLBAVQMcxBHta69v/yQ5hEICSfdQ/VFFrI5dRXbh0wHObmuYvh5q4vcCF CZ484pgNgVcIb+6dehbbKUY4nUvQJy99j1TjnZfpd6gH1xfFGCil1hXbpwY/nmb8kkh1 sI97qs+f0dhmMOtUQR8vDHcEHrXDtTMN9Ts4VCkwYPU5TFg4P+UjVugG4XAlFBSzAYKo nIGfXoYkoheMWqdRgvZ/r2q9GS8vn+MKS0rsugV3Y1YqtiZTJqSNjnLtRxDc8vihYmIs 6V8A== X-Received: by 10.180.187.113 with SMTP id fr17mr11197224wic.35.1384627223397; Sat, 16 Nov 2013 10:40:23 -0800 (PST) Received: from [192.168.42.14] (dyn-62-56-64-243.dslaccess.co.uk. [62.56.64.243]) by mx.google.com with ESMTPSA id bs15sm7228051wib.10.2013.11.16.10.40.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 Nov 2013 10:40:22 -0800 (PST) From: g8kbvdave@googlemail.com To: freebsd-acpi@FreeBSD.org Date: Sat, 16 Nov 2013 18:40:14 -0000 MIME-Version: 1.0 Subject: PCBSD 9.1 x64, unable to successfully boot the install DVD Message-ID: <5287BC0E.26007.A3A1B81@g8kbvdave.googlemail.com> Priority: normal X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body 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: Sat, 16 Nov 2013 18:40:25 -0000 Hi. After a couple of hours to download the full install DVD .iso image (checksums verified etc) and burnt to a DVD (and verified) OK. Tried to install it on a HP Pavilon dv6000 Laptop, suitably prep'd with a 60+ spare primary partition. (2G RAM, AMD Turion 64 bit dual core CPU, Memtest86+ test passed too.) The DVD boots, but only to the first boot option menu, then whatever option you select after (Except hitting the space to pause, that doesnt want to un-pause!) The PC sudenly switches off, and restarts shortly after selecting an option. I've seen this with laptops from many makers in the past when trying to run bootable diagnostic tools, and I've never found any PC where you could disable such systems in the bios setup dialogs. The HP site for this machine is badly mullered too, with dead links and a seeming inability to search for anything even remotely sensible. Sorry, but unable to get any diagnostic dumps etc, or any other info, as the machine just refuses to do anything with this disk, other than get stuck into a very long duration boot/restart loop. I would try a 32 bit version (it's orignal OS was Vista 32 bit) but I cant for the life of me find the 32 bit version of 9.1 on the download site or servers. Any hints? Oh. The DSDT debugging resourse link on the handbook page, goes to a site full of Russian text! Not usefull at all. Unless one reads Russian crylic text, that I don't, using google translate results in something readable, but doesn't relate to this problem at this level. Pity, I'd like to have tried PCBSD. If its anyway near as stable as FreeBSD in general, I'd be happy. Dave B. (Long time BSD 8 user for a local server, and Nas4Free, among other things.)