Current problem reports assigned to freebsd-acpi@FreeBSD.org
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. ___ 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
Fwd: Re: Problems with amd FX 8 core and freq scaling
-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 s...@freebsd.org
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-
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);
___
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: Re: Problems with amd FX 8 core and freq scaling
On 11 November 2013 12:00, Jung-uk Kim j...@freebsd.org 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 ___ 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: Problems with amd FX 8 core and freq scaling
-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 j...@freebsd.org 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-
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
Re: Problems with amd FX 8 core and freq scaling
On Mon, 2013-11-11 at 16:47 -0500, Jung-uk Kim wrote: -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 j...@freebsd.org 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- ___ 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 Let me test this on my fx-8150 tonight. What should I look for as a test failure/success? sean signature.asc Description: This is a digitally signed message part
