linux-stable.git/include/linux/cpu.h, branch linux-2.6.25.y

cpu-hotplug: fix build on !CONFIG_SMP

2008-01-25T20:08:02+00:00

fix build on !CONFIG_SMP.

Signed-off-by: Ingo Molnar

cpu-hotplug: replace lock_cpu_hotplug() with get_online_cpus()

2008-01-25T20:08:02+00:00

Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
get_online_cpus and put_online_cpus instead as it highlights the
refcount semantics in these operations.

The new API guarantees protection against the cpu-hotplug operation, but
it doesn't guarantee serialized access to any of the local data
structures. Hence the changes needs to be reviewed.

In case of pseries_add_processor/pseries_remove_processor, use
cpu_maps_update_begin()/cpu_maps_update_done() as we're modifying the
cpu_present_map there.

Signed-off-by: Gautham R Shenoy 
Signed-off-by: Ingo Molnar

cpu-hotplug: refcount based cpu hotplug

2008-01-25T20:08:01+00:00

This patch implements a Refcount + Waitqueue based model for
cpu-hotplug.

Now, a thread which wants to prevent cpu-hotplug, will bump up a global
refcount and the thread which wants to perform a cpu-hotplug operation
will block till the global refcount goes to zero.

The readers, if any, during an ongoing cpu-hotplug operation are blocked
until the cpu-hotplug operation is over.

Signed-off-by: Gautham R Shenoy 
Signed-off-by: Paul Jackson  [For !CONFIG_HOTPLUG_CPU ]
Signed-off-by: Ingo Molnar

CPU hotplug: fix cpu_is_offline() on !CONFIG_HOTPLUG_CPU

2008-01-06T20:39:42+00:00

make randconfig bootup testing found that the cpufreq code
crashes on bootup, if the powernow-k8 driver is enabled and
if maxcpus=1 passed on the boot line to a !CONFIG_HOTPLUG_CPU
kernel.

First lockdep found out that there's an inconsistent unlock
sequence:

 =====================================
 [ BUG: bad unlock balance detected! ]
 -------------------------------------
 swapper/1 is trying to release lock (&per_cpu(cpu_policy_rwsem, cpu)) at:
 [] unlock_policy_rwsem_write+0x3c/0x42
 but there are no more locks to release!

Call Trace:
 [] unlock_policy_rwsem_write+0x3c/0x42
 [] print_unlock_inbalance_bug+0x104/0x12c
 [] mark_held_locks+0x56/0x94
 [] unlock_policy_rwsem_write+0x3c/0x42
 [] cpufreq_add_dev+0x2a8/0x5c4
 ...

then shortly afterwards the cpufreq code crashed on an assert:

 ------------[ cut here ]------------
 kernel BUG at drivers/cpufreq/cpufreq.c:1068!
 invalid opcode: 0000 [1] SMP
 [...]
 Call Trace:
  [] sysdev_driver_unregister+0x5b/0x91
  [] cpufreq_register_driver+0x15d/0x1a2
  [] powernowk8_init+0x86/0x94
 [...]
 ---[ end trace 1e9219be2b4431de ]---

the bug was caused by maxcpus=1 bootup, which brought up the
secondary core as !cpu_online() but !cpu_is_offline() either,
which on on !CONFIG_HOTPLUG_CPU is always 0 (include/linux/cpu.h):

  /* CPUs don't go offline once they're online w/o CONFIG_HOTPLUG_CPU */
  static inline int cpu_is_offline(int cpu) { return 0; }

but the cpufreq code uses cpu_online() and cpu_is_offline() in
a mixed way - the low-level drivers use cpu_online(), while
the cpufreq core uses cpu_is_offline(). This opened up the
possibility to add the non-initialized sysdev device of the
secondary core:

 cpufreq-core: trying to register driver powernow-k8
 cpufreq-core: adding CPU 0
 powernow-k8: BIOS error - no PSB or ACPI _PSS objects
 cpufreq-core: initialization failed
 cpufreq-core: adding CPU 1
 cpufreq-core: initialization failed

which then blew up. The fix is to make cpu_is_offline() always
the negation of cpu_online(). With that fix applied the kernel
boots up fine without crashing:

 Calling initcall 0xffffffff80cc0510: powernowk8_init+0x0/0x94()
 powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (1 cpu cores) (version 2.20.00)
 powernow-k8: BIOS error - no PSB or ACPI _PSS objects
 initcall 0xffffffff80cc0510: powernowk8_init+0x0/0x94() returned -19.
 initcall 0xffffffff80cc0510 ran for 19 msecs: powernowk8_init+0x0/0x94()
 Calling initcall 0xffffffff80cc328f: init_lapic_nmi_sysfs+0x0/0x39()

We could fix this by making CPU enumeration aware of max_cpus, but that
would be more fragile IMO, and the cpu_online(cpu) != cpu_is_offline(cpu)
possibility was quite confusing and a continuous source of bugs too.

Most distributions have kernels with CPU hotplug enabled, so this bug
remained hidden for a long time.

Bug forensics:

The broken cpu_is_offline() API variant was introduced via:

 commit a59d2e4e6977e7b94e003c96a41f07e96cddc340
 Author: Rusty Russell 
 Date:   Mon Mar 8 06:06:03 2004 -0800

     [PATCH] minor cleanups for hotplug CPUs

( this predates linux-2.6.git, this commit is available from Thomas's
  historic git tree. )

Then 1.5 years later the cpufreq code made use of it:

 commit c32b6b8e524d2c337767d312814484d9289550cf
 Author: Ashok Raj 
 Date:   Sun Oct 30 14:59:54 2005 -0800

     [PATCH] create and destroy cpufreq sysfs entries based on cpu notifiers

 +       if (cpu_is_offline(cpu))
 +               return 0;

which is a correct use of the subtly broken new API. v2.6.15 then
shipped with this bug included.

then it took two more years for random-kernel qa to hit it.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Linus Torvalds

Redefine {un}register_hotcpu_notifier() !HOTPLUG_CPU stubs

2007-10-18T21:37:28+00:00

The return of the present "do {} while" based stub definition of
register_hotcpu_notifier() cannot be checked.  This makes the stub
asymmetric w.r.t.  the real HOTPLUG_CPU=y implementation that is
int-returning.  So let us redefine this to be consistent with the full
version.  Also do the same for unregister_hotcpu_notifier().

We cannot define these as static inline functions due to an existing GCC
bug (#33172).  So define as macros that return appropriately instead (int
'0' for the register_hotcpu_notifier case and void for
unregister_hotcpu_notifier).

Signed-off-by: Satyam Sharma 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION

2007-08-31T08:42:22+00:00

Dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION introduced by commit
296699de6bdc717189a331ab6bbe90e05c94db06 "Introduce CONFIG_SUSPEND for
suspend-to-Ram and standby" are incorrect, as they don't cover the facts that
(1) not all architectures support suspend and (2) SMP hibernation is only
possible on X86 and PPC64 (if CONFIG_PPC64_SWSUSP is set).

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

sched: make global code static

2007-08-12T16:08:19+00:00

This patch makes the following needlessly global code static:

- arch_reinit_sched_domains()
- struct attr_sched_mc_power_savings
- struct attr_sched_smt_power_savings

Signed-off-by: Adrian Bunk 
Signed-off-by: Andrew Morton 
Signed-off-by: Ingo Molnar

remove unused lock_cpu_hotplug_interruptible definition

2007-07-16T16:05:48+00:00

aa95387774039096c11803c04011f1aa42d85758 removed the implementation of
lock_cpu_hotplug_interruptible and all users of it.  This stub definition
for !CONFIG_HOTPLUG_CPU was left over -- kill it now.

Signed-off-by: Nathan Lynch 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

needs to include

2007-05-08T18:15:05+00:00

sysdev.h uses THIS_MODULE so should include .

[akpm@linux-foundation.org: couple of fixes]
Signed-off-by: Ralf Baechle 
Cc: Andi Kleen 
Cc: Heiko Carstens 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Fix microcode-related suspend problem

2007-04-02T17:06:09+00:00

Fix the regression resulting from the recent change of suspend code
ordering that causes systems based on Intel x86 CPUs using the microcode
driver to hang during the resume.

The problem occurs since the microcode driver uses request_firmware() in
its CPU hotplug notifier, which is called after tasks has been frozen and
hangs.  It can be fixed by telling the microcode driver to use the
microcode stored in memory during the resume instead of trying to load it
from disk.

Signed-off-by: Rafael J. Wysocki 
Adrian Bunk 
Cc: Tigran Aivazian 
Cc: Pavel Machek 
Cc: Maxim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds