Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat, 05 Nov 2016, Pavel Machek wrote: > On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote: > > On Sat, 05 Nov 2016, Pavel Machek wrote: > > > Hmm, thanks for the pointer. But it seems like I'll have to build my > > > own, as /proc/acpi/ibm does not follow the usual infrastructure... > > > > /proc/acpi/ibm has been deprecated for years. 99% of the functionality > > is available through more modern, standard interfaces. > > Right, I see sensors can do it these days. Would it be good to expose > them as /sys/class/thermal/thermal_zone*, too? I don't like the idea of touching vendor-screwup-land like thermal zones, especially when thinkpads *already* have thermal zones and they must come from the very same sensors... This would need a lot of careful studying and planning. > Is it known what various fields in /proc/acpi/ibm/thermal measure? It varies with each model. You can map it out with better precision by using a cold spray while doing an "open-heart" surgery on the thinkpad. I kid you not, that's how they were mapped for some models. Look for information about this in thinkwiki: http://www.thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_X60 The battery-pack-related sensor that is stuck at 50°C is something the Lenovo Yamato labs guys wouldn't be clear about. They told me to look at what the Windows drivers do, but that would require (1) Windows in the first place, and (2) clean room reverse engineering protocols. > Basically... 100C is okay for semiconductors, but I'd prefer not to > kill the hard drive Well, that first sensor getting to 100°C is your CPU for sure. > > thinkpad-acpi is supposed to export standard hwmon temperature sensors > > as well. Try them instead, please. > > Heh, I just finished python to work with /proc/acpi/ibm. Oh well. Hey, I *did* properly document that driver, and the documentation is even mostly up-to-date... Please refer to Documentation/laptops/thinkpad-acpi.txt in the kernel tree. -- Henrique Holschuh -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH v2 1/3] thinkpad_acpi: Move tablet detection into separate function
On Sat, 05 Nov 2016, Darren Hart wrote: > On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote: > > Suggested by Daniel Martin > > > > Lenovo's having a bit of fun randomly changing what hotkey events and > > acpi handles they use for reporting tablet mode, so unfortunately this > > means we're definitely going to need to probe for multiple types of > > tablet mode support. Since the hotkey_init() is already a lot larger > > then it should be, let's split up this detection into it's own function > > to make things a little easier to read. > > > > As well, since we're going to have multiple types of tablet modes, make > > hotkey_tablet into an enum so we can also use it to indicate the type of > > tablet mode reporting the machine supports. > > > > Changes since v1: > > - Don't use bool for in_tablet_mode (fixes complaints from kbuild test > > robot) > > > > This series doesn't apply cleanly now (simple fuzz). > > Once we hear back from Henrique on his enum preference and thoughts on the > refactoring (which looks reasonable to me), please resubmit this series and I don't mind the enum usage, as long as it is correct. As you said, the driver is not consistent there. I also don't mind the refactoring. -- Henrique Holschuh -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! BTW.. This machine has nasty habit of hanging during kernel boot when it is "hot".. which makes reboots unplesant here. Ideas would be welcome how to debug that. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat 2016-11-05 16:04:58, Henrique de Moraes Holschuh wrote: > On Sat, 05 Nov 2016, Pavel Machek wrote: > > [ 825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something > > is extremely hot! > > [ 825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A > > 33 N/A 47 50 N/A N/A N/A N/A N/A N/A > > Oh boy, that must be the second time in a decade that I see that > codepath triggering. It is the second-level alert that the ThinkPad is > about to catch fire. > > It should have logged a "is too hot!" first-level alert earlier, but > this depends on the EC and not the driver. Maybe the temperature raised > too fast. I don't think I'm seeing the "is too hot" messages. Actually.. even the "THERMAL EMERGENCY" messages seem to have too low severity, so they are hidden in syslogs -- they don't go to all the consoles. > In Windows, the system would attempt to hibernate or shutdown. I would > be quite happy to have thinkpad-acpi trigger such behavior as well, > patches (or guidance) are welcome ;-) Sorry, just guidance for now: +#include + orderly_poweroff(true); [can be called from weird contexts, afaict]. > Anyway, if that temperature goes about 1~2°C higher, the EC should cut > power to your motherboard. Apparently, the built-in thermal protection > clock modulation on the Intel processor is somehow saving your box from > that forced power-off. Actually, the machine _will_ shut down some time after that. It seems that one of acpi trip points jumps to 128C which forces shutdown. Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote: > On Sat, 05 Nov 2016, Pavel Machek wrote: > > Hmm, thanks for the pointer. But it seems like I'll have to build my > > own, as /proc/acpi/ibm does not follow the usual infrastructure... > > /proc/acpi/ibm has been deprecated for years. 99% of the functionality > is available through more modern, standard interfaces. Right, I see sensors can do it these days. Would it be good to expose them as /sys/class/thermal/thermal_zone*, too? Is it known what various fields in /proc/acpi/ibm/thermal measure? Basically... 100C is okay for semiconductors, but I'd prefer not to kill the hard drive > thinkpad-acpi is supposed to export standard hwmon temperature sensors > as well. Try them instead, please. Heh, I just finished python to work with /proc/acpi/ibm. Oh well. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH v2 1/3] thinkpad_acpi: Move tablet detection into separate function
On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote: > Suggested by Daniel Martin > > Lenovo's having a bit of fun randomly changing what hotkey events and > acpi handles they use for reporting tablet mode, so unfortunately this > means we're definitely going to need to probe for multiple types of > tablet mode support. Since the hotkey_init() is already a lot larger > then it should be, let's split up this detection into it's own function > to make things a little easier to read. > > As well, since we're going to have multiple types of tablet modes, make > hotkey_tablet into an enum so we can also use it to indicate the type of > tablet mode reporting the machine supports. > > Changes since v1: > - Don't use bool for in_tablet_mode (fixes complaints from kbuild test > robot) > This series doesn't apply cleanly now (simple fuzz). Once we hear back from Henrique on his enum preference and thoughts on the refactoring (which looks reasonable to me), please resubmit this series and review Documentation/SubmittingPatches for the changelog (below ---) and please be consistent in your placement of "v2" in the subject [PATCH vX N/M] prefix. Most all of my feedback here is minor, but there were enough little things that added up and I'd like to see this resubmitted as a series with those addressed that applies cleanly - largely to make sure I haven't missed context and somehow merged the wrong bits. Thanks Lyude, -- Darren Hart Intel Open Source Technology Center -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 3/3 v3] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode
On Mon, Oct 31, 2016 at 06:55:34PM -0400, Lyude wrote:
> For whatever reason, the X1 Yoga doesn't support the normal method of
> querying for tablet mode. Instead of providing the MHKG method under the
> hotkey handle, we're instead given the CMMD method under the EC handle.
> Values on this handle are either 0x1, laptop mode, or 0x6, tablet mode.
>
> Changes since v1:
> - Clarify kernel output when finding the tablet mode switch
> Changes since v2:
> - Rebase on top of previous patch
> - Use an enum for hotkey_tablet. This does make a bit more sense then
> just adding another flag.
> - Call hotkey_tablet_mode_notify_change() when getting TABLET_CHANGED
> event.
These go below the ---
>
> Cc: Daniel Martin
> Signed-off-by: Lyude
> ---
> drivers/platform/x86/thinkpad_acpi.c | 37
>
> 1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index 92e8986..4df4153 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -190,6 +190,9 @@ enum tpacpi_hkey_event_t {
> TP_HKEY_EV_LID_OPEN = 0x5002, /* laptop lid opened */
> TP_HKEY_EV_TABLET_TABLET= 0x5009, /* tablet swivel up */
> TP_HKEY_EV_TABLET_NOTEBOOK = 0x500a, /* tablet swivel down */
> + TP_HKEY_EV_TABLET_CHANGED = 0x60c0, /* X1 Yoga (2016):
> +* enter/leave tablet mode
> +*/
> TP_HKEY_EV_PEN_INSERTED = 0x500b, /* tablet pen inserted */
> TP_HKEY_EV_PEN_REMOVED = 0x500c, /* tablet pen removed */
> TP_HKEY_EV_BRGHT_CHANGED= 0x5010, /* backlight control event */
> @@ -305,6 +308,7 @@ static struct {
> enum {
> TP_HOTKEY_TABLET_NONE = 0,
> TP_HOTKEY_TABLET_USES_MHKG = 1,
> + TP_HOTKEY_TABLET_USES_CMMD = 2,
1 and 2 will follow automatically, no need to specify.
Pending Henrique's preference on inline enum or external definition.
> } hotkey_tablet;
> u32 kbdlight:1;
> u32 light:1;
> @@ -2062,6 +2066,8 @@ static void hotkey_poll_setup(const bool may_warn);
>
> /* HKEY.MHKG() return bits */
> #define TP_HOTKEY_TABLET_MASK (1 << 3)
> +/* ThinkPad X1 Yoga (2016) */
> +#define TP_EC_CMMD_TABLET_MODE 0x6
>
> static int hotkey_get_wlsw(void)
> {
> @@ -2086,10 +2092,23 @@ static int hotkey_get_tablet_mode(int *status)
> {
> int s;
>
> - if (!acpi_evalf(hkey_handle, &s, "MHKG", "d"))
> - return -EIO;
> + switch (tp_features.hotkey_tablet) {
> + case TP_HOTKEY_TABLET_USES_MHKG:
> + if (!acpi_evalf(hkey_handle, &s, "MHKG", "d"))
> + return -EIO;
> +
> + *status = ((s & TP_HOTKEY_TABLET_MASK) != 0);
> + break;
> + case TP_HOTKEY_TABLET_USES_CMMD:
> + if (!acpi_evalf(ec_handle, &s, "CMMD", "d"))
> + return -EIO;
> +
> + *status = (s == TP_EC_CMMD_TABLET_MODE);
> + break;
> + default:
> + break;
> + }
>
> - *status = ((s & TP_HOTKEY_TABLET_MASK) != 0);
> return 0;
> }
>
> @@ -3127,10 +3146,14 @@ hotkey_init_tablet_mode(void)
> char *type;
> bool in_tablet_mode;
>
> - /* For X41t, X60t, X61t Tablets... */
> if (acpi_evalf(hkey_handle, &res, "MHKG", "qd")) {
> + /* For X41t, X60t, X61t Tablets... */
> tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_MHKG;
> type = "MHKG";
> + } else if (acpi_evalf(ec_handle, &res, "CMMD", "qd")) {
> + /* For X1 Yoga (2016) */
> + tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_CMMD;
> + type = "CMMD";
> }
>
> if (!tp_features.hotkey_tablet)
> @@ -3928,6 +3951,12 @@ static bool hotkey_notify_6xxx(const u32 hkey,
> *ignore_acpi_ev = true;
> return true;
>
> + case TP_HKEY_EV_TABLET_CHANGED:
> + tpacpi_input_send_tabletsw();
> + hotkey_tablet_mode_notify_change();
> + *send_acpi_ev = false;
> + break;
> +
> default:
> pr_warn("unknown possible thermal alarm or keyboard event
> received\n");
> known = false;
> --
> 2.7.4
>
>
--
Darren Hart
Intel Open Source Technology Center
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH 1/3] thinkpad_acpi: Move tablet detection into separate function
On Mon, Oct 31, 2016 at 06:55:32PM -0400, Lyude wrote:
> Suggested by Daniel Martin
Down below with the other -by: tags please.
>
> Lenovo's having a bit of fun randomly changing what hotkey events and
Please avoid contractions in documentation in general.
> acpi handles they use for reporting tablet mode, so unfortunately this
> means we're definitely going to need to probe for multiple types of
> tablet mode support. Since the hotkey_init() is already a lot larger
> then it should be, let's split up this detection into it's own function
s/then/than/ (nit, but since I'm commenting anyway...)
s/it's/its/
> to make things a little easier to read.
>
> As well, since we're going to have multiple types of tablet modes, make
> hotkey_tablet into an enum so we can also use it to indicate the type of
> tablet mode reporting the machine supports.
>
> Signed-off-by: Lyude
> Cc: Daniel Martin
> ---
> drivers/platform/x86/thinkpad_acpi.c | 50
> +++-
> 1 file changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index b65ce75..369b483 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -302,7 +302,10 @@ static struct {
> u32 hotkey:1;
> u32 hotkey_mask:1;
> u32 hotkey_wlsw:1;
> - u32 hotkey_tablet:1;
> + enum {
> + TP_HOTKEY_TABLET_NONE = 0,
> + TP_HOTKEY_TABLET_USES_MHKG = 1,
1 will follow automatically, no need to specify explicitly.
enum usage in this driver is not very consistent, but I don't particularly care
to have it defined within the struct, but I'll leave that for Henrique to
decide.
> + } hotkey_tablet;
> u32 kbdlight:1;
> u32 light:1;
> u32 light_status:1;
> @@ -3117,6 +3120,34 @@ static const struct tpacpi_quirk
> tpacpi_hotkey_qtable[] __initconst = {
> typedef u16 tpacpi_keymap_entry_t;
> typedef tpacpi_keymap_entry_t tpacpi_keymap_t[TPACPI_HOTKEY_MAP_LEN];
>
> +static int
> +hotkey_init_tablet_mode(void)
> +{
> + int res;
> + char *type;
> + bool in_tablet_mode;
Declare variables in reverse line length order please:
bool in_tablet_mode;
char *type;
int res;
> +
> + /* For X41t, X60t, X61t Tablets... */
> + if (acpi_evalf(hkey_handle, &res, "MHKG", "qd")) {
> + tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_MHKG;
> + in_tablet_mode = !!(res & TP_HOTKEY_TABLET_MASK);
> + type = "MHKG";
> + }
> +
> + if (!tp_features.hotkey_tablet)
> + return 0;
> +
> + pr_info("Tablet mode switch found (type: %s), currently in %s mode\n",
> + type, in_tablet_mode ? "tablet" : "laptop");
> +
> + res = add_to_attr_set(hotkey_dev_attributes,
> + &dev_attr_hotkey_tablet_mode.attr);
> + if (res)
> + return -1;
> +
> + return in_tablet_mode;
> +}
> +
> static int __init hotkey_init(struct ibm_init_struct *iibm)
> {
> /* Requirements for changing the default keymaps:
> @@ -3464,17 +3495,6 @@ static int __init hotkey_init(struct ibm_init_struct
> *iibm)
> res = add_to_attr_set(hotkey_dev_attributes,
> &dev_attr_hotkey_radio_sw.attr);
>
> - /* For X41t, X60t, X61t Tablets... */
> - if (!res && acpi_evalf(hkey_handle, &status, "MHKG", "qd")) {
> - tp_features.hotkey_tablet = 1;
> - tabletsw_state = !!(status & TP_HOTKEY_TABLET_MASK);
> - pr_info("possible tablet mode switch found; "
> - "ThinkPad in %s mode\n",
> - (tabletsw_state) ? "tablet" : "laptop");
> - res = add_to_attr_set(hotkey_dev_attributes,
> - &dev_attr_hotkey_tablet_mode.attr);
> - }
> -
> if (!res)
> res = register_attr_set_with_sysfs(
> hotkey_dev_attributes,
> @@ -3482,6 +3502,12 @@ static int __init hotkey_init(struct ibm_init_struct
> *iibm)
> if (res)
> goto err_exit;
>
> + res = hotkey_init_tablet_mode();
> + if (res < 0)
> + goto err_exit;
> +
> + tabletsw_state = res;
> +
> /* Set up key map */
> hotkey_keycode_map = kmalloc(TPACPI_HOTKEY_MAP_SIZE,
> GFP_KERNEL);
> --
> 2.7.4
>
>
--
Darren Hart
Intel Open Source Technology Center
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/list
Re: [ibm-acpi-devel] [PATCH v2] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode
On Sat, Nov 05, 2016 at 11:45:22AM -0700, Darren Hart wrote: > On Thu, Oct 27, 2016 at 03:46:44PM -0400, Lyude wrote: > > For whatever reason, the X1 Yoga doesn't support the normal method of > > querying for tablet mode. Instead of providing the MHKG method under the > > hotkey handle, we're instead given the CMMD method under the EC handle. > > Values on this handle are either 0x1, laptop mode, or 0x6, tablet mode. > > > > Changes since v1: > > - Clarify kernel output when finding the tablet mode switch > > These two lines go below the --- below (they aren't meant to be part of the > permanent commit message). Please see Documentation/SubmittingPatches. > > I've queued this to testing as it addresses Henrique's change request. > Henrique, > I'll add your Reviewed-by if you send it along, or drop it if you have more > reservations. Scratch that, I see there is a new series with this patch in it. Will respond there. -- Darren Hart Intel Open Source Technology Center -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH v2] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode
On Sat, 05 Nov 2016, Darren Hart wrote: > On Thu, Oct 27, 2016 at 03:46:44PM -0400, Lyude wrote: > > For whatever reason, the X1 Yoga doesn't support the normal method of > > querying for tablet mode. Instead of providing the MHKG method under the > > hotkey handle, we're instead given the CMMD method under the EC handle. > > Values on this handle are either 0x1, laptop mode, or 0x6, tablet mode. > > > > Changes since v1: > > - Clarify kernel output when finding the tablet mode switch > > These two lines go below the --- below (they aren't meant to be part of the > permanent commit message). Please see Documentation/SubmittingPatches. > > I've queued this to testing as it addresses Henrique's change request. > Henrique, > I'll add your Reviewed-by if you send it along, or drop it if you have more > reservations. No reservations, since it was tested to not regress previous thinkpads. -- Henrique Holschuh -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH v2] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode
On Thu, Oct 27, 2016 at 03:46:44PM -0400, Lyude wrote: > For whatever reason, the X1 Yoga doesn't support the normal method of > querying for tablet mode. Instead of providing the MHKG method under the > hotkey handle, we're instead given the CMMD method under the EC handle. > Values on this handle are either 0x1, laptop mode, or 0x6, tablet mode. > > Changes since v1: > - Clarify kernel output when finding the tablet mode switch These two lines go below the --- below (they aren't meant to be part of the permanent commit message). Please see Documentation/SubmittingPatches. I've queued this to testing as it addresses Henrique's change request. Henrique, I'll add your Reviewed-by if you send it along, or drop it if you have more reservations. Thanks, -- Darren Hart Intel Open Source Technology Center -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat, 05 Nov 2016, Pavel Machek wrote: > [ 825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something > is extremely hot! > [ 825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A 33 > N/A 47 50 N/A N/A N/A N/A N/A N/A Oh boy, that must be the second time in a decade that I see that codepath triggering. It is the second-level alert that the ThinkPad is about to catch fire. It should have logged a "is too hot!" first-level alert earlier, but this depends on the EC and not the driver. Maybe the temperature raised too fast. In Windows, the system would attempt to hibernate or shutdown. I would be quite happy to have thinkpad-acpi trigger such behavior as well, patches (or guidance) are welcome ;-) Anyway, if that temperature goes about 1~2°C higher, the EC should cut power to your motherboard. Apparently, the built-in thermal protection clock modulation on the Intel processor is somehow saving your box from that forced power-off. -- Henrique Holschuh -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat, 05 Nov 2016, Pavel Machek wrote: > Hmm, thanks for the pointer. But it seems like I'll have to build my > own, as /proc/acpi/ibm does not follow the usual infrastructure... /proc/acpi/ibm has been deprecated for years. 99% of the functionality is available through more modern, standard interfaces. thinkpad-acpi is supposed to export standard hwmon temperature sensors as well. Try them instead, please. Also, thinkpad-acpi will report the EC thermal sensors. They don't need to (and most often won't) match whatever you read from the processor core(s). -- Henrique Holschuh -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > > Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also > > > under > > > load, scaling_max_freq changes. But at that point, we are already > > > around 98C... and bios_limit stays the same all the time in v4.9. > > > > ...while in v4.8-rc1, bios limit goes to 1.0 GHz at 90C, and > > temperature just doesn't go above that. > > > > Does it make sense to try with v4.8-final? > I sent some suggestion to try in previous email to add more prints and > enable debug in acpi-cpufreq. Let's try that first. We need to fix > anyway even if 4.8-final has this issue. Ok, you should have results in your mailbox now. If you want me to do some more testing, let me know. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > > > > > It is possible. Can you add either add printk > > > in acpi_processor_ppc_has_changed() or use ftrace and see do you > > > get to > > > these functions > > > > > > acpi_processor_ppc_init() > > > acpi_processor_ppc_has_changed() > > > acpi_processor_ppc_notifier() > > > > > > ? > > > > Yes, these seem to be called. Here's the log: Ok, burnP6 pushes cpu to 102C rather quickly. dmesg is below. Thanks, Pavel cpu: scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 temp: 82 [65, 82, 65, 44, 66, 33, 33, 44, 51] fan: 2874 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 85 [82, 85, 82, 44, 69, 33, 33, 44, 51] fan: 2874 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 91 [91, 87, 91, 44, 72, 33, 33, 44, 51] fan: 3151 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 94 [94, 88, 94, 44, 74, 33, 33, 44, 51] fan: 3151 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 96 [96, 90, 96, 44, 76, 33, 33, 44, 52] fan: 3531 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 98 [98, 91, 98, 45, 78, 33, 33, 44, 52] fan: 3566 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 100 [100, 92, 100, 44, 79, 33, 33, 44, 52] fan: 3575 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 101 [101, 93, 101, 44, 81, 33, 33, 44, 52] fan: 3594 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 102 [102, 93, 102, 45, 82, 33, 33, 44, 53] fan: 3596 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 102 [102, 91, 102, 44, 83, 33, 33, 44, 53] fan: 3598 cpu: scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8 temp: 101 [101, 78, 101, 45, 83, 33, 33, 44, 54] fan: 3599 cpu: scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8 temp: 84 [84, 75, 84, 45, 81, 33, 33, 44, 54] [ 21.594684] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 21.703638] NFSD: starting 90-second grace period (net c5015600) [ 27.941612] ppc_notifier [ 27.944682] ppc_notifier: mutex [ 27.947639] ppc = 0 [ 27.950576] ppc_notifier: verify within [ 27.953522] ppc = 0 freq-limit 1833000 [ 27.956474] ppc_notifier [ 27.961414] ppc_notifier [ 27.963050] ppc_notifier: mutex [ 27.964674] ppc = 0 [ 27.966246] ppc_notifier: verify within [ 27.967808] ppc = 0 freq-limit 1833000 [ 27.969404] ppc_notifier [ 32.974593] iwl3945 :03:00.0: loaded firmware version 15.32.2.9 [ 46.298794] wlan0: authenticate with 00:00:00:00:00:01 [ 46.303301] wlan0: send auth to 00:00:00:00:00:01 (try 1/3) [ 46.305173] wlan0: authenticated [ 46.308558] wlan0: associate with 00:00:00:00:00:01 (try 1/3) [ 46.311352] wlan0: RX AssocResp from 00:00:00:00:00:01 (capab=0x401 status=0 aid=4) [ 46.313568] wlan0: associated [ 80.213718] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 80.213744] acpi_cpufreq: get_cur_val = 1555 [ 80.213746] acpi_cpufreq: cur freq = 100 [ 80.215276] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 80.215280] acpi_cpufreq: get_cur_val = 2077 [ 80.215282] acpi_cpufreq: cur freq = 1333000 [ 85.233419] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 85.233441] acpi_cpufreq: get_cur_val = 1555 [ 85.233444] acpi_cpufreq: cur freq = 100 [ 85.235230] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 85.235235] acpi_cpufreq: get_cur_val = 1555 [ 85.235238] acpi_cpufreq: cur freq = 100 [ 90.241835] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 90.241841] acpi_cpufreq: get_cur_val = 2860 [ 90.241843] acpi_cpufreq: cur freq = 1833000 [ 90.242820] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 90.242825] acpi_cpufreq: get_cur_val = 2860 [ 90.242826] acpi_cpufreq: cur freq = 1833000 [ 95.249622] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 95.249628] acpi_cpufreq: get_cur_val = 2860 [ 95.249630] acpi_cpufreq: cur freq = 1833000 [ 95.250608] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 95.250613] acpi_cpufreq: get_cur_val = 2860 [ 95.250614] acpi_cpufreq: cur freq = 1833000 [ 100.257505] acpi_cpufreq: get_cur_freq_on_cpu (0) [ 100.257510] acpi_cpufreq: get_cur_val = 1555 [ 100.257513] acpi_cpufreq: cur freq = 100 [ 100.258490] acpi_cpufreq: get_cur_freq_on_cpu (1) [ 100.258496] acpi_cpufreq: get_cur_val = 2860 [ 100.
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Sat 2016-11-05 14:53:13, Pavel Machek wrote: > Hi! > > > > Ok, can do, let me recompile and reboot. > > > > > > > > > > > When temperature limit is reached acpi_processor_ppc_notifier() > > > > should > > > > be called. > > > > > > No, that's not correct for ACPI passive trip points, is it? If I > > > recall correctly, those should be monitored even when temperature is > > > below them so that it does not reach them...? > > No if BIOS is sending PPC, it will be called. You can try first in 4.8. > > > > Also try > > > > Don't run workload, just on an idle system. > > > > # echo 1 > /sys/class/thermal/cooling_device2/cur_state > > monitor the scaling_max_freq, it should reduce > > > > # echo 2 > /sys/class/thermal/cooling_device2/cur_state > > monitor the scaling_max_freq, it should reduce > > Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also under > load, scaling_max_freq changes. But at that point, we are already > around 98C... and bios_limit stays the same all the time in v4.9. ...while in v4.8-rc1, bios limit goes to 1.0 GHz at 90C, and temperature just doesn't go above that. Does it make sense to try with v4.8-final? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > Ok, can do, let me recompile and reboot. > > > > > > > > When temperature limit is reached acpi_processor_ppc_notifier() > > > should > > > be called. > > > > No, that's not correct for ACPI passive trip points, is it? If I > > recall correctly, those should be monitored even when temperature is > > below them so that it does not reach them...? > No if BIOS is sending PPC, it will be called. You can try first in 4.8. > > Also try > > Don't run workload, just on an idle system. > > # echo 1 > /sys/class/thermal/cooling_device2/cur_state > monitor the scaling_max_freq, it should reduce > > # echo 2 > /sys/class/thermal/cooling_device2/cur_state > monitor the scaling_max_freq, it should reduce Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also under load, scaling_max_freq changes. But at that point, we are already around 98C... and bios_limit stays the same all the time in v4.9. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Fri 2016-11-04 23:20:53, Pandruvada, Srinivas wrote: > On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote: > > Hi! > > > > [...] > > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > It is possible. Can you add either add printk > in acpi_processor_ppc_has_changed() or use ftrace and see do you get to > these functions > > acpi_processor_ppc_init() > acpi_processor_ppc_has_changed() > acpi_processor_ppc_notifier() > > ? Ok, can do, let me recompile and reboot. > When temperature limit is reached acpi_processor_ppc_notifier() should > be called. No, that's not correct for ACPI passive trip points, is it? If I recall correctly, those should be monitored even when temperature is below them so that it does not reach them...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > So we seem to have thermal or ACPI regression in v4.9-rc3. > > > To me, there are two problems, > the first one is a 4.9-rc regression that BIOS limit stops working, > results in overheating because of high cpu frequency. I agree with > Srinivas to check acpi_cpufreq driver code for this one. Ok. > the second problem is that thermal passive cooling can not prevent the > system from overheating, when there is no BIOS limit. To debug this, > you can enable thermal dynamic debug by > echo 'module thermal_sys +fp' > /sys/kernel/debug/dynamic_debug/control How is thermal passive cooling different from BIOS limit? Is this related? pavel@duo:/sys/class/thermal/cooling_device1$ grep -r . . ./cur_state:0 ./power/runtime_active_kids:0 ./power/runtime_suspended_time:0 grep: ./power/autosuspend_delay_ms: Input/output error ./power/runtime_enabled:disabled ./power/runtime_active_time:0 ./power/control:auto ./power/async:disabled ./power/runtime_usage:0 ./power/runtime_status:unsupported ./type:Processor ./max_state:10 Hmm. I seem to get _some_ throttling, even when bios_limit is still 1.8GHz, but I don't understand where it comes from. And yes, 'thermal_sys +fp' seems to produce some output. [I did not get absolute records in >100C range this time, but still there are "THERMAL EMERGENCY:" messages from thinkpad_acpi already...] [14049.733423] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is extremely hot! [14049.735412] thinkpad_acpi: temperatures (Celsius): 92 50 N/A 80 32 N/A 32 N/A 50 59 N/A N/A N/A N/A N/A N/A [14049.736557] update_temperature: thermal thermal_zone1: last_temperature=92000, current_temperature=93000 [14049.736570] thermal_zone_trip_update: thermal thermal_zone1: Trip1[type=1,temp=92500]:trend=1,throttle=1 [14049.736577] get_target_state: thermal cooling_device2: cur_state=0 [14049.736580] thermal_zone_trip_update: thermal cooling_device2: old_target=0, target=1 [14049.736586] get_target_state: thermal cooling_device1: cur_state=0 [14049.736589] thermal_zone_trip_update: thermal cooling_device1: old_target=0, target=1 [14049.736593] thermal_cdev_update: thermal cooling_device2: zone1->target=1 [14049.736643] thermal_cdev_update: thermal cooling_device2: set to state 1 [14049.736647] thermal_cdev_update: thermal cooling_device1: zone1->target=1 [14049.73] thermal_cdev_update: thermal cooling_device1: set to state 1 [14049.808333] update_temperature: thermal thermal_zone1: last_temperature=93000, current_temperature=91000 [14049.808352] thermal_zone_trip_update: thermal thermal_zone1: Trip1[type=1,temp=92500]:trend=2,throttle=0 [14049.808360] get_target_state: thermal cooling_device2: cur_state=1 [14049.808364] thermal_zone_trip_update: thermal cooling_device2: old_target=1, target=0 [14049.808371] get_target_state: thermal cooling_device1: cur_state=1 [14049.808375] thermal_zone_trip_update: thermal cooling_device1: old_target=1, target=0 [14049.808381] thermal_cdev_update: thermal cooling_device2: zone1->target=0 [14049.808409] thermal_cdev_update: thermal cooling_device2: set to state 0 [14049.808414] thermal_cdev_update: thermal cooling_device1: zone1->target=0 [14049.808432] thermal_cdev_update: thermal cooling_device1: set to state 0 [14049.888385] update_temperature: thermal thermal_zone1: last_temperature=91000, current_temperature=92000 [14049.888401] thermal_zone_trip_update: thermal thermal_zone1: Trip1[type=1,temp=92500]:trend=1,throttle=0 [14049.888408] get_target_state: thermal cooling_device2: cur_state=0 [14049.888411] thermal_zone_trip_update: thermal cooling_device2: old_target=0, target=0 [14049.888416] get_target_state: thermal cooling_device1: cur_state=0 [14049.888419] thermal_zone_trip_update: thermal cooling_device1: old_target=0, target=0 [14051.312646] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is extremely hot! [14051.314442] thinkpad_acpi: temperatures (Celsius): 93 50 N/A 80 32 N/A 32 N/A 50 59 N/A N/A N/A N/A N/A N/A [14051.315544] update_temperature: thermal thermal_zone1: last_temperature=92000, current_temperature=94000 [14051.315557] thermal_zone_trip_update: thermal thermal_zone1: Trip1[type=1,temp=92500]:trend=1,throttle=1 [14051.315564] get_target_state: thermal cooling_device2: cur_state=0 [14051.315567] thermal_zone_trip_update: thermal cooling_device2: old_target=0, target=1 [14051.315572] get_target_state: thermal cooling_device1: cur_state=0 [14051.315575] thermal_zone_trip_update: thermal cooling_device1: old_target=0, target=1 [14051.315579] thermal_cdev_update: thermal cooling_device2: zone1->target=1 [14051.315629] thermal_cdev_update: thermal cooling_device2: set to state 1 [14051.315633] thermal_cdev_update: thermal cooling_device1: zone1->target=1 [14051.315652] thermal_cdev_update: thermal cooling_device1: set to state 1 [14051.334873] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is extremely hot! [14051.337322] thinkpad_acpi: temperatures (Celsius): 93 50 N/A 8
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > Under v4.8-rc, behaviour is different: bios_limit goes to 1GHz there > when temperature is around 84C at the thermal zone. That keeps > ibm/thermal temperatures under 90C, and no "thermal emergency" > messages in syslog. Argh. So v4.9 thermal management does not work. v4.8 passive thermal management works _too well_, keeping fan at cca 3200 rpm, far below 3700 rpm it can reach. CPU is getting throttled, and fan is not even running at full speed. I can manually control the fan with thinkpad_acpi.fan_control=1... I guess I can write some scripts? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote: > Hi! > > > > > I'd prefer mails over bugzilla for now... > > > > 4.9-rc2 has bios_limit: > > > > pavel@duo:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > > 1833000 > > > > and it has thermal zones: > > > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 127000 > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_type > > critical > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp 97000 > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_type > > critical > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp 92500 > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_type > > passive > > > > ..so it should slow down CPU at 92C. > > > > So lets push the temperature up a bit... > > > > sudo watch cat /proc/acpi/ibm/thermal > > /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > > /sys/devices/virtual/thermal/thermal_zone1/temp /sys/devices/syste > > m/cpu/cpu0/cpufreq/cpuinfo_cur_freq > > > > temperatures: 98 49 -128 85 28 -128 28 -128 49 58 -128 -128 -128 > > -128 -128 -128 > > 1833000 > > 95000 > > 1833000 > > > > Hmm. bios_limit does not seem to change, even when the temperature > > is > > clearly above the trip point. (It is also interestng that acpi/ibm > > reports bigger temperatures than > > /sys/devices/virtual/thermal/thermal_zone1/temp . I have seen 103C > > there.) > Under v4.8-rc, behaviour is different: bios_limit goes to 1GHz there > when temperature is around 84C at the thermal zone. > That keeps > ibm/thermal temperatures under 90C, and no "thermal emergency" > messages in syslog. > > So we seem to have thermal or ACPI regression in v4.9-rc3. > To me, there are two problems, the first one is a 4.9-rc regression that BIOS limit stops working, results in overheating because of high cpu frequency. I agree with Srinivas to check acpi_cpufreq driver code for this one. the second problem is that thermal passive cooling can not prevent the system from overheating, when there is no BIOS limit. To debug this, you can enable thermal dynamic debug by echo 'module thermal_sys +fp' > /sys/kernel/debug/dynamic_debug/control thanks, rui > Best regards, > > > Pavel > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build
Hi! > > 4.9-rc2 has bios_limit: > > > > pavel@duo:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > > 1833000 > > > > and it has thermal zones: > > > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 127000 > > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_type critical > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp 97000 > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_type critical > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp 92500 > > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_type passive > > > It will not act if there is no binding information. Do you have more > files in this folder? > > grep -r . * in /sys/class/thermal will be helpful. Yes, I do. Here you go: pavel@duo:/data/l/linux$ sudo grep -ri . /sys/class/thermal/* /sys/class/thermal/cooling_device0/cur_state:0 /sys/class/thermal/cooling_device0/power/runtime_active_kids:0 /sys/class/thermal/cooling_device0/power/runtime_suspended_time:0 grep: /sys/class/thermal/cooling_device0/power/autosuspend_delay_ms: Input/output error /sys/class/thermal/cooling_device0/power/runtime_enabled:disabled /sys/class/thermal/cooling_device0/power/runtime_active_time:0 /sys/class/thermal/cooling_device0/power/control:auto /sys/class/thermal/cooling_device0/power/async:disabled /sys/class/thermal/cooling_device0/power/runtime_usage:0 /sys/class/thermal/cooling_device0/power/runtime_status:unsupported /sys/class/thermal/cooling_device0/type:LCD /sys/class/thermal/cooling_device0/max_state:7 /sys/class/thermal/cooling_device1/cur_state:0 /sys/class/thermal/cooling_device1/power/runtime_active_kids:0 /sys/class/thermal/cooling_device1/power/runtime_suspended_time:0 grep: /sys/class/thermal/cooling_device1/power/autosuspend_delay_ms: Input/output error /sys/class/thermal/cooling_device1/power/runtime_enabled:disabled /sys/class/thermal/cooling_device1/power/runtime_active_time:0 /sys/class/thermal/cooling_device1/power/control:auto /sys/class/thermal/cooling_device1/power/async:disabled /sys/class/thermal/cooling_device1/power/runtime_usage:0 /sys/class/thermal/cooling_device1/power/runtime_status:unsupported /sys/class/thermal/cooling_device1/type:Processor /sys/class/thermal/cooling_device1/max_state:10 /sys/class/thermal/cooling_device2/cur_state:0 /sys/class/thermal/cooling_device2/power/runtime_active_kids:0 /sys/class/thermal/cooling_device2/power/runtime_suspended_time:0 grep: /sys/class/thermal/cooling_device2/power/autosuspend_delay_ms: Input/output error /sys/class/thermal/cooling_device2/power/runtime_enabled:disabled /sys/class/thermal/cooling_device2/power/runtime_active_time:0 /sys/class/thermal/cooling_device2/power/control:auto /sys/class/thermal/cooling_device2/power/async:disabled /sys/class/thermal/cooling_device2/power/runtime_usage:0 /sys/class/thermal/cooling_device2/power/runtime_status:unsupported /sys/class/thermal/cooling_device2/type:Processor /sys/class/thermal/cooling_device2/max_state:10 /sys/class/thermal/thermal_zone0/passive:0 /sys/class/thermal/thermal_zone0/available_policies:step_wise /sys/class/thermal/thermal_zone0/policy:step_wise /sys/class/thermal/thermal_zone0/mode:enabled grep: /sys/class/thermal/thermal_zone0/offset: Input/output error grep: /sys/class/thermal/thermal_zone0/integral_cutoff: Input/output error /sys/class/thermal/thermal_zone0/power/runtime_active_kids:0 /sys/class/thermal/thermal_zone0/power/runtime_suspended_time:0 grep: /sys/class/thermal/thermal_zone0/power/autosuspend_delay_ms: Input/output error /sys/class/thermal/thermal_zone0/power/runtime_enabled:disabled /sys/class/thermal/thermal_zone0/power/runtime_active_time:0 /sys/class/thermal/thermal_zone0/power/control:auto /sys/class/thermal/thermal_zone0/power/async:disabled /sys/class/thermal/thermal_zone0/power/runtime_usage:0 /sys/class/thermal/thermal_zone0/power/runtime_status:unsupported grep: /sys/class/thermal/thermal_zone0/k_d: Input/output error /sys/class/thermal/thermal_zone0/trip_point_0_type:critical /sys/class/thermal/thermal_zone0/type:acpitz grep: /sys/class/thermal/thermal_zone0/slope: Input/output error grep: /sys/class/thermal/thermal_zone0/k_po: Input/output error grep: /sys/class/thermal/thermal_zone0/k_i: Input/output error grep: /sys/class/thermal/thermal_zone0/sustainable_power: Input/output error /sys/class/thermal/thermal_zone0/trip_point_0_temp:127000 grep: /sys/class/thermal/thermal_zone0/k_pu: Input/output error /sys/class/thermal/thermal_zone0/temp:58000 /sys/class/thermal/thermal_zone1/available_policies:step_wise /sys/class/thermal/thermal_zone1/policy:step_wise /sys/class/thermal/thermal_zone1/mode:enabled /sys/class/thermal/thermal_zone1/trip_point_1_type:passive grep: /sys/class/thermal/thermal_zone1/offset: Input/output error grep: /sys/class/thermal/thermal_zone1/integral_cutoff: Input/output error /sys/class/thermal/thermal_zone1/power/runtime_active_kids:0 /sys/class/thermal/thermal_zone1/power/runtime_suspended_time:0
