Commit-ID: 7815701c5cd7276b712d898b3cf49c55e587dbb1
Gitweb: http://git.kernel.org/tip/7815701c5cd7276b712d898b3cf49c55e587dbb1
Author: Thomas Gleixner
AuthorDate: Fri, 3 Apr 2015 02:12:03 +0200
Committer: Ingo Molnar
CommitDate: Fri, 3 Apr 2015 08:44:34 +0200
ACPI/idle: Use explicit
From: Len Brown
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 2194324d8bbbad1b179c08b6095649b06abd62d5 upstream.
Linux uses CPUID.MWAIT.EDX to validate the C-states
reported by ACPI, silently discarding states which
are not supported by the
From: Rafael J. Wysocki
Add an ->enter_freeze callback routine, acpi_idle_enter_freeze(), to
the ACPI cpuidle driver and point ->enter_freeze to it for all the
C2-type and C3-type states that don't need to fall back to C1
(which may be halt-induced and that will re-enable interrupts on
exit from
idle_boot_override depends on x86 and ia64 now, and we can not
foresee it will be used on ARM or ARM64, so move the code into
CONFIG_X86 and CONFIG_IA64 #ifdefs to make processor_core.c
can be compiled on ARM64.
Signed-off-by: Hanjun Guo
---
drivers/acpi/processor_core.c | 47 +
idle_boot_override depends on x86 and ia64 now, and we can not
foresee it will be used on ARM or ARM64, so move the code into
CONFIG_X86 and CONFIG_IA64 #ifdefs to make processor_core.c
can be compiled on ARM64.
Signed-off-by: Hanjun Guo
---
drivers/acpi/processor_core.c | 47 +
On 2014-2-18 9:13, Rafael J. Wysocki wrote:
> On Saturday, February 08, 2014 09:10:16 PM Hanjun Guo wrote:
>> idle_boot_override depends on x86 and ia64 now, and we can not
>> foresee it will be used on ARM or ARM64,so move the code into
>> CONFIG_X86 and CONFIG_IA64 #ifdefs to make processor_core.
On Saturday, February 08, 2014 09:10:16 PM Hanjun Guo wrote:
> idle_boot_override depends on x86 and ia64 now, and we can not
> foresee it will be used on ARM or ARM64,so move the code into
> CONFIG_X86 and CONFIG_IA64 #ifdefs to make processor_core.c
> can be compiled on ARM64.
>
> Signed-off-by:
idle_boot_override depends on x86 and ia64 now, and we can not
foresee it will be used on ARM or ARM64,so move the code into
CONFIG_X86 and CONFIG_IA64 #ifdefs to make processor_core.c
can be compiled on ARM64.
Reviewed-by: Lan Tianyu
Signed-off-by: Hanjun Guo
---
drivers/acpi/processor_core.c
2014-02-08 Hanjun Guo :
> idle_boot_override depends on x86 and ia64 now, and we can not
> foresee it will be used on ARM or ARM64,so move the code into
> CONFIG_X86 and CONFIG_IA64 #ifdefs to make processor_core.c
> can be compiled on ARM64.
>
Reviewed-by: Lan Tianyu
> Signed-off-by: Hanjun Guo
idle_boot_override depends on x86 and ia64 now, and we can not
foresee it will be used on ARM or ARM64,so move the code into
CONFIG_X86 and CONFIG_IA64 #ifdefs to make processor_core.c
can be compiled on ARM64.
Signed-off-by: Hanjun Guo
---
drivers/acpi/processor_core.c | 40 ++
On 2014-1-21 7:34, Rafael J. Wysocki wrote:
> On Monday, January 20, 2014 10:08:41 PM Hanjun Guo wrote:
>> On 2014年01月18日 21:47, Rafael J. Wysocki wrote:
>>> On Saturday, January 18, 2014 11:52:18 AM Hanjun Guo wrote:
On 2014-1-18 11:45, Hanjun Guo wrote:
> On 2014-1-17 20:06, Sudeep Holla
On Monday, January 20, 2014 10:08:41 PM Hanjun Guo wrote:
> On 2014年01月18日 21:47, Rafael J. Wysocki wrote:
> > On Saturday, January 18, 2014 11:52:18 AM Hanjun Guo wrote:
> >> On 2014-1-18 11:45, Hanjun Guo wrote:
> >>> On 2014-1-17 20:06, Sudeep Holla wrote:
> On 17/01/14 02:03, Hanjun Guo wr
On 2014年01月18日 21:47, Rafael J. Wysocki wrote:
On Saturday, January 18, 2014 11:52:18 AM Hanjun Guo wrote:
On 2014-1-18 11:45, Hanjun Guo wrote:
On 2014-1-17 20:06, Sudeep Holla wrote:
On 17/01/14 02:03, Hanjun Guo wrote:
Move idle_boot_override out of the arch directory to be a single enum
i
On Saturday, January 18, 2014 11:52:18 AM Hanjun Guo wrote:
> On 2014-1-18 11:45, Hanjun Guo wrote:
> > On 2014-1-17 20:06, Sudeep Holla wrote:
> >> On 17/01/14 02:03, Hanjun Guo wrote:
> >>> Move idle_boot_override out of the arch directory to be a single enum
> >>> including both platforms values
On 2014-1-18 11:45, Hanjun Guo wrote:
> On 2014-1-17 20:06, Sudeep Holla wrote:
>> On 17/01/14 02:03, Hanjun Guo wrote:
>>> Move idle_boot_override out of the arch directory to be a single enum
>>> including both platforms values, this will make it rather easier to
>>> avoid ifdefs around which def
LT and MWAIT are x86
> specific and may not make sense for other architectures.
yes, this is the strange part, the value is arch-dependent.
>
> It will also require every architecture using ACPI to export
> boot_option_idle_override which may not be really required.
so, how about forge
On 17/01/14 02:03, Hanjun Guo wrote:
> Move idle_boot_override out of the arch directory to be a single enum
> including both platforms values, this will make it rather easier to
> avoid ifdefs around which definitions are for which processor in
> generally used ACPI code.
>
> IDLE_FORCE_MWAIT for
Move idle_boot_override out of the arch directory to be a single enum
including both platforms values, this will make it rather easier to
avoid ifdefs around which definitions are for which processor in
generally used ACPI code.
IDLE_FORCE_MWAIT for IA64 is not used anywhere, so romove it.
No fun
On Thu, Dec 19, 2013 at 12:13:29PM -0800, H. Peter Anvin wrote:
> On 12/19/2013 12:09 PM, tip-bot for Peter Zijlstra wrote:
> > diff --git a/drivers/thermal/intel_powerclamp.c
> > b/drivers/thermal/intel_powerclamp.c
> > index 8f181b3..e8275f2 100644
> > --- a/drivers/thermal/intel_powerclamp.c
>
On 12/19/2013 12:09 PM, tip-bot for Peter Zijlstra wrote:
> diff --git a/drivers/thermal/intel_powerclamp.c
> b/drivers/thermal/intel_powerclamp.c
> index 8f181b3..e8275f2 100644
> --- a/drivers/thermal/intel_powerclamp.c
> +++ b/drivers/thermal/intel_powerclamp.c
> @@ -438,9 +438,7 @@ static int
Commit-ID: 16824255394f55adf31b9a96a9965d8c15bdac4c
Gitweb: http://git.kernel.org/tip/16824255394f55adf31b9a96a9965d8c15bdac4c
Author: Peter Zijlstra
AuthorDate: Thu, 12 Dec 2013 15:08:36 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 19 Dec 2013 11:54:44 -0800
x86, acpi, idle
People seem to delight in writing wrong and broken mwait idle routines;
collapse the lot.
This leaves mwait_play_dead() the sole remaining user of __mwait() and
new __mwait() users are probably doing it wrong.
Also remove __sti_mwait() as its unused.
Cc: ar...@linux.intel.com
Cc: jacob.jun@l
People seem to delight in writing wrong and broken mwait idle routines;
collapse the lot.
This leaves mwait_play_dead() the sole remaining user of __mwait() and
new __mwait() users are probably doing it wrong.
Also remove __sti_mwait() as its unused.
Cc: ar...@linux.intel.com
Cc: jacob.jun@l
On 11/20/2013 8:33 AM, Peter Zijlstra wrote:
On Wed, Nov 20, 2013 at 08:24:47AM -0800, Arjan van de Ven wrote:
On 11/20/2013 2:58 AM, Peter Zijlstra wrote:
So pretty silly actually; you cannot do a store (any store) in between
monitor and mwait.
you can
just not to the cacheline you are watch
On Wed, Nov 20, 2013 at 08:24:47AM -0800, Arjan van de Ven wrote:
> On 11/20/2013 2:58 AM, Peter Zijlstra wrote:
> >So pretty silly actually; you cannot do a store (any store) in between
> >monitor and mwait.
>
> you can
> just not to the cacheline you are watching (or things that alias with that)
is running.
turbostate shows 100% C0. ftrace shows kernel coming in and out of idle
frequently.
Both ACPI idle and intel_idle behaves the same way. I have to do the
following change to allow entering C-states again.
That doesn't make any sense; current_set_polling_and_test() returns the
turbostate shows 100% C0. ftrace shows kernel coming in and out of idle
> > frequently.
> >
> > Both ACPI idle and intel_idle behaves the same way. I have to do the
> > following change to allow entering C-states again.
> That doesn't make any sense; current_set_pol
state shows 100% C0. ftrace shows kernel coming in and out of idle
> frequently.
>
> Both ACPI idle and intel_idle behaves the same way. I have to do the
> following change to allow entering C-states again.
>
> diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h
&
e, wtf are you guys smoking?
>
I applied this patch on top of upstream kernel (801a760) and found out
my machine completely failed to enter idle when nothing is running.
turbostate shows 100% C0. ftrace shows kernel coming in and out of idle
frequently.
Both ACPI idle and intel_idle behaves
On Tue, Nov 19, 2013 at 03:51:43PM +0100, Peter Zijlstra wrote:
> That said, that drive is completely wrecked. It uses
> preempt_enable_no_resched() wrong too, it has uncommented barriers..
>
> Dude, wtf are you guys smoking?
---
Subject: sched: Take away preempt_enable_no_resched() and friends f
On Tue, Nov 19, 2013 at 06:22:43AM -0800, Arjan van de Ven wrote:
> >diff --git a/drivers/thermal/intel_powerclamp.c
> >b/drivers/thermal/intel_powerclamp.c
> >index 8f181b3f842b..e8275f2df9af 100644
> >--- a/drivers/thermal/intel_powerclamp.c
> >+++ b/drivers/thermal/intel_powerclamp.c
> >@@ -438
On Tue, Nov 19, 2013 at 06:22:43AM -0800, Arjan van de Ven wrote:
> >diff --git a/drivers/thermal/intel_powerclamp.c
> >b/drivers/thermal/intel_powerclamp.c
> >index 8f181b3f842b..e8275f2df9af 100644
> >--- a/drivers/thermal/intel_powerclamp.c
> >+++ b/drivers/thermal/intel_powerclamp.c
> >@@ -438
diff --git a/drivers/thermal/intel_powerclamp.c
b/drivers/thermal/intel_powerclamp.c
index 8f181b3f842b..e8275f2df9af 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -438,9 +438,7 @@ static int clamp_thread(void *arg)
*/
On Tue, 2013-11-19 at 12:31 +0100, Peter Zijlstra wrote:
> People seem to delight in writing wrong and broken mwait idle routines;
> collapse the lot.
>
> This leaves mwait_play_dead() the sole remaining user of __mwait() and
> new __mwait() users are probably doing it wrong.
>
> Also remove __s
On Tuesday, November 19, 2013 12:31:53 PM Peter Zijlstra wrote:
> People seem to delight in writing wrong and broken mwait idle routines;
> collapse the lot.
>
> This leaves mwait_play_dead() the sole remaining user of __mwait() and
> new __mwait() users are probably doing it wrong.
>
> Also remo
People seem to delight in writing wrong and broken mwait idle routines;
collapse the lot.
This leaves mwait_play_dead() the sole remaining user of __mwait() and
new __mwait() users are probably doing it wrong.
Also remove __sti_mwait() as its unused.
Signed-off-by: Peter Zijlstra
---
Mike, doe
From: Daniel Lezcano
The different definitions are not used anywhere in the code.
Signed-off-by: Daniel Lezcano
Signed-off-by: Len Brown
---
drivers/acpi/processor_idle.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index
From: Daniel Lezcano
These different headers are not needed.
Signed-off-by: Daniel Lezcano
Signed-off-by: Len Brown
---
drivers/acpi/processor_idle.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
From: Daniel Lezcano
The cpuidle_device is retrieved in the function by using directly
the global variable. But the caller of this function already have
this device and it can be passed as a parameter. That is one small
step to encapsulate the code more.
Signed-off-by: Daniel Lezcano
Signed-off
From: Daniel Lezcano
Len Brown sent a patch to remove this field in the intel_idle driver.
The other user of this field is the davinci cpuidle driver and a
patch has been sent to remove the usage of it.
This patch removes the last user of this field.
Signed-off-by: Daniel Lezcano
Signed-off-by
From: "Srivatsa S. Bhat"
On a KVM guest, when a CPU is taken offline and brought back online, we hit
the following NULL pointer dereference:
[ 45.400843] Unregister pv shared memory for cpu 1
[ 45.412331] smpboot: CPU 1 is now offline
[ 45.529894] SMP alternatives: lockdep: fixing up alter
Applied.
thanks,
Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tu
On a KVM guest, when a CPU is taken offline and brought back online, we hit
the following NULL pointer dereference:
[ 45.400843] Unregister pv shared memory for cpu 1
[ 45.412331] smpboot: CPU 1 is now offline
[ 45.529894] SMP alternatives: lockdep: fixing up alternatives
[ 45.533472] smpb
=143 C2 exit=35
ACPI: C3 enter=858 C3 exit=71
ACPI: Using ACPI idle
ACPI: If experiencing system slowness, try adding "acpi=no-idle" to cmdline
ACPI: System firmware supports: S0 S1 S5
VFS: Mounted root (ex2 filesystem) readonly.
Freeing unused kernel memory: 184k freed
Warning: unable
Tried 2.4.1-ac10 (this includes 2.4.2-pre3 so the latest ACPI updates ar
in). Acpi-idle slowdown is still there, acpi=no-idle helps. Via KT133
chipset, Soltek 75KV motherboard, Duron 600.
ACPI info from dmesg:
ACPI: Core Subsystem version [20010208]
ACPI: Subsystem enabled
ACPI: System firmware
45 matches
Mail list logo
