Skip to contentSkip to conversation

intel_idle: work around errate VLP52 on Baytrail CPUs

PATCH In review Jochen Hein 5 participants 10 messages Dec 19, 2016 – Jan 11, 2017 1 message not in the archive Intel idle driver

lore
Share & tools
lore

Jochen Hein

author
#0 lore raw

PATCH 1/1 intel_idle: work around errate VLP52 on Baytrail CPUs

There are frequent hangs on Baytrail CPUs according to
https://bugzilla.kernel.org/show_bug.cgi?id=109051.
This patch works around the errata by disabling C6.

According to the discussion in the bug and private mail it might be useful to include the workaround in mainline.

Signed-off-by Jochen Hein <[email protected]>
Cc [email protected]
drivers/idle/intel_idle.c renamed from drivers/idle/intel_idle.c.orig +32 -0
@@ -1210,6 +1210,34 @@
 
 }
 /*
+ * byt_idle_state_table_update(void)
+ *
+ * On BYT, we have errata VLP52 and disable C6.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=109051A
+ * http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-n3520-j2850-celeron-n2920-n2820-n2815-n2806-j1850-j1750-spec-update.pdf
+ * VLP52 EOI Transactions May Not be Sent if Software Enters Core C6 During an Interrupt Service Routine.
+
+Problem:
+If core C6 is entered after the start of an interrupt service routine but before a write
+to the APIC EOI (End of Interrupt) register, and the core is woken up by an event
+other than a fixed interrupt source the core may drop the EOI transaction the next
+time APIC EOI register is written and further interrupts from the same or lower
+priority level will be blocked.
+
+Implication:
+EOI transactions may be lost and interrupts may be blocked when core C6 is used
+during interrupt service routines.
+
+Workaround:
+It is possible for the firmware to contain a workaround for this erratum.
+ */
+static void byt_idle_state_table_update(void)
+{
+	printk(PREFIX "byt_idle_state_table_update reached\n");
+	byt_cstates[1].disabled = 1;	/* C6N-BYT */
+	byt_cstates[2].disabled = 1;	/* C6S-BYT */
+}
+/*
  * sklh_idle_state_table_update(void)
  *
  * On SKL-H (model 0x5e) disable C8 and C9 if:

@@ -1264,6 +1292,10 @@
 	case 0x3e: /* IVT */
 		ivt_idle_state_table_update();
 		break;
+	case 0x37: /* BYT */
+		printk(PREFIX "intel_idle_state_table_update BYT 0x37 reached\n");
+		byt_idle_state_table_update();
+		break;
 	case 0x5c: /* BXT */
 		bxt_idle_state_table_update();
 		break;
Signature · 1 line
The only problem with troubleshooting is that the trouble shoots back.
maintainer
#1 lore raw

CC Jacob Pan.

Quoted 67 lines · Jochen Hein

There are frequent hangs on Baytrail CPUs according to
https://bugzilla.kernel.org/show_bug.cgi?id=109051.
This patch works around the errata by disabling C6.

According to the discussion in the bug and private mail it might be useful to include the workaround in mainline.

Signed-off-by Jochen Hein <[email protected]>
Cc [email protected]
drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 renamed from drivers/idle/intel_idle.c.orig 2016-09-24 10:10:18.000000000 +0200 +32 -1
@@ -1210,6 +1210,34 @@
 
 }
 /*
+ * byt_idle_state_table_update(void)
+ *
+ * On BYT, we have errata VLP52 and disable C6.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=109051A
+ * http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-n3520-j2850-celeron-n2920-n2820-n2815-n2806-j1850-j1750-spec-update.pdf
+ * VLP52 EOI Transactions May Not be Sent if Software Enters Core C6 During an Interrupt Service Routine.
+
+Problem:
+If core C6 is entered after the start of an interrupt service routine but before a write
+to the APIC EOI (End of Interrupt) register, and the core is woken up by an event
+other than a fixed interrupt source the core may drop the EOI transaction the next
+time APIC EOI register is written and further interrupts from the same or lower
+priority level will be blocked.
+
+Implication:
+EOI transactions may be lost and interrupts may be blocked when core C6 is used
+during interrupt service routines.
+
+Workaround:
+It is possible for the firmware to contain a workaround for this erratum.
+ */
+static void byt_idle_state_table_update(void)
+{
+       printk(PREFIX "byt_idle_state_table_update reached\n");
+       byt_cstates[1].disabled = 1;    /* C6N-BYT */
+       byt_cstates[2].disabled = 1;    /* C6S-BYT */
+}
+/*
  * sklh_idle_state_table_update(void)
  *
  * On SKL-H (model 0x5e) disable C8 and C9 if:

@@ -1264,6 +1292,10 @@
        case 0x3e: /* IVT */
                ivt_idle_state_table_update();
                break;
+       case 0x37: /* BYT */
+               printk(PREFIX "intel_idle_state_table_update BYT 0x37 reached\n");
+               byt_idle_state_table_update();
+               break;
        case 0x5c: /* BXT */
                bxt_idle_state_table_update();
                break;
 
--

The only problem with troubleshooting is that the trouble shoots back.

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): CA+8K-g=fXN9TWWxkV1AEEjXJLhwJEQ2PB434gKQ9Z7bL=yf+zA@mail.gmail.com

#3 lore raw

Hi,

Apologies, I apparently send some HTML in the email. Here is another attempt.

Kind regards,
Vincent

---------- Forwarded message ----------
From: "Vincent Gerris" <[email protected]>
Date: Dec 27, 2016 11:47
Subject: Re: [PATCH] intel_idle: work around errate VLP52 on Baytrail CPUs
To: "Rafael J. Wysocki" <[email protected]>
Cc: "Jochen Hein" <[email protected]>, "Len Brown" <[email protected]>, "Linux PM" <[email protected]>, "Jacob Pan" <[email protected]>, "Hans de Goede" <[email protected]>

Quoted 98 lines
Quoted 2 lines

Hi all,

Thank you Jochen Hein for creating the patch.
The patch fixed my problem and at least one other person with a N3530 processor.

I attached a patch for 4.8.x (needed some changes to constants) which also can be found here:
https://bugzilla.kernel.org/attachment.cgi?id=247621
I also added Hans de Goede in de CC, he supplied patches for the Cherry trail platform.

Is there anything we can do to accelerate adoption in the main kernel? Maybe Jacob can confirm it deals with the errata properly?

Thanks everyone,

Kind regards,
Vincent

Quoted 72 lines · Rafael J. Wysocki
Quoted 1 line

CC Jacob Pan.

Quoted 67 lines · Jochen Hein

There are frequent hangs on Baytrail CPUs according to
https://bugzilla.kernel.org/show_bug.cgi?id=109051.
This patch works around the errata by disabling C6.

According to the discussion in the bug and private mail it might be useful to include the workaround in mainline.

Signed-off-by Jochen Hein <[email protected]>
Cc [email protected]
drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 renamed from drivers/idle/intel_idle.c.orig 2016-09-24 10:10:18.000000000 +0200 +32 -1
@@ -1210,6 +1210,34 @@
 
 }
 /*
+ * byt_idle_state_table_update(void)
+ *
+ * On BYT, we have errata VLP52 and disable C6.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=109051A
+ * http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-n3520-j2850-celeron-n2920-n2820-n2815-n2806-j1850-j1750-spec-update.pdf
+ * VLP52 EOI Transactions May Not be Sent if Software Enters Core C6 During an Interrupt Service Routine.
+
+Problem:
+If core C6 is entered after the start of an interrupt service routine but before a write
+to the APIC EOI (End of Interrupt) register, and the core is woken up by an event
+other than a fixed interrupt source the core may drop the EOI transaction the next
+time APIC EOI register is written and further interrupts from the same or lower
+priority level will be blocked.
+
+Implication:
+EOI transactions may be lost and interrupts may be blocked when core C6 is used
+during interrupt service routines.
+
+Workaround:
+It is possible for the firmware to contain a workaround for this erratum.
+ */
+static void byt_idle_state_table_update(void)
+{
+       printk(PREFIX "byt_idle_state_table_update reached\n");
+       byt_cstates[1].disabled = 1;    /* C6N-BYT */
+       byt_cstates[2].disabled = 1;    /* C6S-BYT */
+}
+/*
  * sklh_idle_state_table_update(void)
  *
  * On SKL-H (model 0x5e) disable C8 and C9 if:

@@ -1264,6 +1292,10 @@
        case 0x3e: /* IVT */
                ivt_idle_state_table_update();
                break;
+       case 0x37: /* BYT */
+               printk(PREFIX "intel_idle_state_table_update BYT 0x37 reached\n");
+               byt_idle_state_table_update();
+               break;
        case 0x5c: /* BXT */
                bxt_idle_state_table_update();
                break;
 
--

The only problem with troubleshooting is that the trouble shoots back.

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

reviewer
#4 lore raw
Quoted 27 lines
Quoted 27 lines
Quoted 27 lines · Jochen Hein
Quoted 26 lines

There are frequent hangs on Baytrail CPUs according to
https://bugzilla.kernel.org/show_bug.cgi?id=109051.
This patch works around the errata by disabling C6.

According to the discussion in the bug and private mail it might be useful to include the workaround in mainline.

Signed-off-by Jochen Hein <[email protected]>
Cc [email protected]
drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 renamed from drivers/idle/intel_idle.c.orig 2016-09-24 10:10:18.000000000 +0200 +9 -0
@@ -1210,6 +1210,34 @@
 
 }
 /*
+ * byt_idle_state_table_update(void)
+ *
+ * On BYT, we have errata VLP52 and disable C6.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=109051A
+ * http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-n3520-j2850-celeron-n2920-n2820-n2815-n2806-j1850-j1750-spec-update.pdf
+ * VLP52 EOI Transactions May Not be Sent if Software Enters Core C6 During an Interrupt Service Routine.
+
+Problem:
+If core C6 is entered after the start of an interrupt service routine but before a write
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 line 1229

Quoted 8 lines
drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 renamed from drivers/idle/intel_idle.c.orig 2016-09-24 10:10:18.000000000 +0200 +8 -0
+to the APIC EOI (End of Interrupt) register, and the core is woken up by an event
+other than a fixed interrupt source the core may drop the EOI transaction the next
+time APIC EOI register is written and further interrupts from the same or lower
+priority level will be blocked.
+
+Implication:
+EOI transactions may be lost and interrupts may be blocked when core C6 is used
+during interrupt service routines.

Exactly how is it possible for Linux to enter idle and issue an MWAIT from _within_ an interrupt handler?

Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 renamed from drivers/idle/intel_idle.c.orig 2016-09-24 10:10:18.000000000 +0200 +10 -0
+Workaround:
+It is possible for the firmware to contain a workaround for this erratum.
+ */
+static void byt_idle_state_table_update(void)
+{
+       printk(PREFIX "byt_idle_state_table_update reached\n");
+       byt_cstates[1].disabled = 1;    /* C6N-BYT */
+       byt_cstates[2].disabled = 1;    /* C6S-BYT */
+}
+/*
  * sklh_idle_state_table_update(void)
  *
  * On SKL-H (model 0x5e) disable C8 and C9 if:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 line 1298

Quoted 8 lines
drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 renamed from drivers/idle/intel_idle.c.orig 2016-09-24 10:10:18.000000000 +0200 +4 -0
@@ -1264,6 +1292,10 @@
        case 0x3e: /* IVT */
                ivt_idle_state_table_update();
                break;
+       case 0x37: /* BYT */
+               printk(PREFIX "intel_idle_state_table_update BYT 0x37 reached\n");
+               byt_idle_state_table_update();
+               break;

If the right strategy were to disable C6 for all of BYT, then the right implementation
would be to delete those states from byt_cstates[], rather than for a routine to mark
them as disabled. Note that a user can not later enable a state that is marked as disabled here, it is never registered with cpuidle, and thus the effect is exactly the same as if the entry were never in the table in the first place.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 line 1301

Quoted 4 lines
drivers/idle/intel_idle.c 2016-10-16 07:36:51.142862573 +0200 renamed from drivers/idle/intel_idle.c.orig 2016-09-24 10:10:18.000000000 +0200 +0 -0
        case 0x5c: /* BXT */
                bxt_idle_state_table_update();
                break;

thanks,
Len Brown, Intel Open Source Technology Center

author
#5 lore raw

Hi Len,

Quoted 6 lines · Len Brown
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines · Jochen Hein
Quoted 4 lines

There are frequent hangs on Baytrail CPUs according to
https://bugzilla.kernel.org/show_bug.cgi?id=109051.
This patch works around the errata by disabling C6.

Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines

drivers/idle/intel_idle.c line 1229

Quoted 10 lines
drivers/idle/intel_idle.c renamed from drivers/idle/intel_idle.c.orig +10 -0
+Problem:
+If core C6 is entered after the start of an interrupt service routine but before a write
+to the APIC EOI (End of Interrupt) register, and the core is woken up by an event
+other than a fixed interrupt source the core may drop the EOI transaction the next
+time APIC EOI register is written and further interrupts from the same or lower
+priority level will be blocked.
+
+Implication:
+EOI transactions may be lost and interrupts may be blocked when core C6 is used
+during interrupt service routines.

Exactly how is it possible for Linux to enter idle and issue an MWAIT from _within_ an interrupt handler?

I really have no idea - all I can say is that for all Kernels < 4.9 I had to disable C6 to have a stable system.
4.9 seems stable for me now.

Quoted 22 lines
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
drivers/idle/intel_idle.c renamed from drivers/idle/intel_idle.c.orig +10 -0
+Workaround:
+It is possible for the firmware to contain a workaround for this erratum.
+ */
+static void byt_idle_state_table_update(void)
+{
+       printk(PREFIX "byt_idle_state_table_update reached\n");
+       byt_cstates[1].disabled = 1;    /* C6N-BYT */
+       byt_cstates[2].disabled = 1;    /* C6S-BYT */
+}
+/*
  * sklh_idle_state_table_update(void)
  *
  * On SKL-H (model 0x5e) disable C8 and C9 if:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

drivers/idle/intel_idle.c line 1298

Quoted 8 lines
drivers/idle/intel_idle.c renamed from drivers/idle/intel_idle.c.orig +4 -0
@@ -1264,6 +1292,10 @@
        case 0x3e: /* IVT */
                ivt_idle_state_table_update();
                break;
+       case 0x37: /* BYT */
+               printk(PREFIX "intel_idle_state_table_update BYT 0x37 reached\n");
+               byt_idle_state_table_update();
+               break;
Quoted 7 lines

If the right strategy were to disable C6 for all of BYT, then the right implementation
would be to delete those states from byt_cstates[], rather than for a routine to mark
them as disabled. Note that a user can not later enable a state that is marked as disabled here, it is never registered with cpuidle, and thus the effect is exactly the same as if the entry were never in the table in the first place.

Would that be a useful workaround for older stable kernels? I think we should try to get stable systems to the affected users.

Jochen

Signature · 1 line
The only problem with troubleshooting is that the trouble shoots back.
reviewer
#6 lore raw

It is not possible for Linux to enter idle from within an interrupt handler. Thus, it is not possible for the cited errata to be the root cause of this problem.

Quoted 3 lines

- all I can say is that for all Kernels < 4.9 I
had to disable C6 to have a stable system.
4.9 seems stable for me now.

Linux-4.9 does not contain the patch do disable c6 on BYT.
And so that patch can not be the reason for the reported change in stability.

I understand that this stability problem is difficult to get one's hands around --
many have reported that it was gone, only to later report that it wasn't really gone...

If you have something that can quickly determine if the problem is present or if the problem is gone, that would be extremely valuable.

It would also be very interesting to know what C-states are actually being used on your particular platform. For example, your patch disabled c6, but did not disable c7. I would be interested to know on a ststem such as yours, if disabling c67 was sufficient, and if the platform was still able to make use of c7.

You can see if you are actually using c7 by running turbostat on an idle system:

# turbostat --debug -o ts.out sleep 10
and show the ts.out
Quoted 10 lines
Quoted 7 lines

If the right strategy were to disable C6 for all of BYT, then the right implementation
would be to delete those states from byt_cstates[], rather than for a routine to mark
them as disabled. Note that a user can not later enable a state that is marked as disabled here, it is never registered with cpuidle, and thus the effect is exactly the same as if the entry were never in the table in the first place.

Would that be a useful workaround for older stable kernels? I think we should try to get stable systems to the affected users.

This workaround is already available in the form of cmdline:
intel_idle.max_cstate=1

not all systems need/want that workaround.

thanks,
Len Brown, Intel Open Source Technology Center

#7 lore raw

Hi,

First of all I want to thank you for getting involved, it seems intel is the one that knows best how to address this and get to the root cause.

Quoted 8 lines · Len Brown

It is not possible for Linux to enter idle from within an interrupt handler. Thus, it is not possible for the cited errata to be the root cause of this problem.

Quoted 3 lines

- all I can say is that for all Kernels < 4.9 I
had to disable C6 to have a stable system.
4.9 seems stable for me now.

For me 4.9.0 is not stable either and at least someone with gentoo on 4.9.0 rc1 reported freezes too.
Although it takes longer before it happens, it still freezes (N3520 on Lenovo Yoga 2 11 with latest BIOS).

Quoted 10 lines

Linux-4.9 does not contain the patch do disable c6 on BYT.
And so that patch can not be the reason for the reported change in stability.

I understand that this stability problem is difficult to get one's hands around --
many have reported that it was gone, only to later report that it wasn't really gone...

If you have something that can quickly determine if the problem is present or if the problem is gone, that would be extremely valuable.

For me I can usually trigger the freeze by a combination playing video and network/bluetooth traffic.
What usually freezes it in minutes, is playing video from a network share, copying that file at the same time and stream audio over bluetooth.

Quoted 8 lines

It would also be very interesting to know what C-states are actually being used on your particular platform. For example, your patch disabled c6, but did not disable c7. I would be interested to know on a ststem such as yours, if disabling c67 was sufficient, and if the platform was still able to make use of c7.

You can see if you are actually using c7 by running turbostat on an idle system:

If I am not mistaken, this is output from a patched 4.8 kernel from powertop using Jochens patch :

          Package   |             Core    |            CPU 0
                    |                     | C0 active   0,8%
                    |                     | POLL        0,0%    0,0 ms
                    | C1 (cc1)   14,7%    | C1-BYT     10,4%    4,3 ms
C2 (pc2)    0,0%    |                     |
C3 (pc3)    0,0%    |                     |
C6 (pc6)    0,0%    | C6 (cc6)   81,7%    |
                    |                     | C7S-BYT     3,1%    6,5 ms
                    |             Core    |            CPU 1
                    |                     | C0 active   1,6%
                    |                     | POLL        0,0%    0,0 ms
                    | C1 (cc1)   89,1%    | C1-BYT     56,2%    2,7 ms
                    |                     |
                    |                     |
                    | C6 (cc6)    4,1%    |
                    |                     | C7S-BYT     0,0%    0,0 ms
                    |             Core    |            CPU 2
                    |                     | C0 active   0,3%
                    |                     | POLL        0,0%    0,0 ms
                    | C1 (cc1)   10,7%    | C1-BYT      5,8%    8,9 ms
                    |                     |
                    |                     |
                    | C6 (cc6)   88,1%    |
                    |                     | C7S-BYT    19,5%   31,9 ms
                    |             Core    |            CPU 3
                    |                     | C0 active   0,2%
                    |                     | POLL        0,0%    0,0 ms
                    | C1 (cc1)   17,3%    | C1-BYT     10,2%   11,3 ms
                    |                     |
                    |                     |
                    | C6 (cc6)   82,0%    |
Quoted 11 lines
# turbostat --debug -o ts.out sleep 10
and show the ts.out
Quoted 7 lines
Quoted 7 lines

If the right strategy were to disable C6 for all of BYT, then the right implementation
would be to delete those states from byt_cstates[], rather than for a routine to mark
them as disabled. Note that a user can not later enable a state that is marked as disabled here, it is never registered with cpuidle, and thus the effect is exactly the same as if the entry were never in the table in the first place.

I don't fully grasp this, but if the errata causes this, wouldn't it be more transparent to mark it as such so disable it?
Are we really sure the errata does not cause this? If so, is there a recommended way from intel on how to patch this?

Quoted 8 lines
Quoted 3 lines

Would that be a useful workaround for older stable kernels? I think we should try to get stable systems to the affected users.

This workaround is already available in the form of cmdline:
intel_idle.max_cstate=1

not all systems need/want that workaround.

I think there are 2 main reasons why we do not want kernel parameters:
1. normal users will have difficulties doing this (I don't like it either :) )
2. it's not a structural solution

Quoted 3 lines

thanks,
Len Brown, Intel Open Source Technology Center

I saw your patch for auto-demotion, I will test it and report within a few days. I will also do further testing with the 4.9 kernel. I hope we can get things stable one way or the other :).

Thanks a lot,
Vincent Gerris

#8 lore raw
Quoted 8 lines · On Wed, 28 Dec 2016 13:56:25 +0100 Vincent Gerris <[email protected]> wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

If the right strategy were to disable C6 for all of BYT, then the right implementation
would be to delete those states from byt_cstates[], rather than for a routine to mark
them as disabled. Note that a user can not later enable a state that is marked as disabled here, it is never registered with cpuidle, and thus the effect is exactly the same as if the entry were never in the table in the first place.

Quoted 4 lines

I don't fully grasp this, but if the errata causes this, wouldn't it be more transparent to mark it as such so disable it?
Are we really sure the errata does not cause this? If so, is there a recommended way from intel on how to patch this?

I don't think the EOI errata is relevant to this issue. As Len pointed out, it is impossible to enter C6 or run idle task during ISR.

However, this errata might be the cause of the issue you seen, as you mentioned you encounter the issue while playing media with audio i presume? While I am looking for a fix, could you try without audio see if it still hangs?

"VLP70. LPE Audio Playback May Result in System Hang
Problem: Extended audio playback with the LPE (Low Power Engine) may result in a system hang if the SOC concurrently enters C6 or deeper sleep states. Implication: The system may hang when this erratum occurs.
Workaround: It is possible for the driver to contain a workaround for this erratum."

reviewer
#9 lore raw
In reply to Vincent Gerris

Re: powertop

turbostat is more useful. The pre-release I uploaded to the bug report includes some baytrail specific support:

https://bugzilla.kernel.org/show_bug.cgi?id=109051#c661

Quoted 3 lines

I saw your patch for auto-demotion, I will test it and report within a few days. I will also do further testing with the 4.9 kernel. I hope we can get things stable one way or the other :).

Current thinking is that we have multiple issues here, and enabling auto-demotion
simply hides the actual root causes.

Sound is one known root cause, as Jacob pointed out. Hopefully we'll have a fix for that one shortly.

I'm testing w/o sound, and still can provoke a failure in under 30 minutes.

Len Brown, Intel Open Source Technology Center

#10 lore raw
Quoted 11 lines · On Wed, 11 Jan 2017 18:14:12 -0500 Len Brown <[email protected]> wrote:

Re: powertop

turbostat is more useful. The pre-release I uploaded to the bug report includes some baytrail specific support:

https://bugzilla.kernel.org/show_bug.cgi?id=109051#c661

Quoted 3 lines

I saw your patch for auto-demotion, I will test it and report within a few days. I will also do further testing with the 4.9 kernel. I hope we can get things stable one way or the other :).

Quoted 7 lines

Current thinking is that we have multiple issues here, and enabling auto-demotion
simply hides the actual root causes.

Sound is one known root cause, as Jacob pointed out. Hopefully we'll have a fix for that one shortly.

+Vinod & Subhransu
Could you send out Baytrail VLP70 SST driver workaround patch for testing?

Quoted 4 lines

I'm testing w/o sound, and still can provoke a failure in under 30 minutes.

Len Brown, Intel Open Source Technology Center

[