aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2011-07-22Merge remote-tracking branch 'rmk/fixes' into linaro-3.0HEADlinux-linaro-3.0-2011.07-1masterNicolas Pitre
2011-07-22Merge remote-tracking branch 'rmk/devel-stable' into linaro-3.0Nicolas Pitre
2011-07-22Merge commit 'v3.0' into linaro-3.0Nicolas Pitre
2011-07-21Merge branch 'zImage_DTB_append' of git://git.linaro.org/people/nico/linux ↵linux-linaro-3.0-2011.07-0Nicolas Pitre
into linaro-3.0
2011-07-21Merge branch 'devicetree/linaro-3.0' of git://git.secretlab.ca/git/linux-2.6 ↵Nicolas Pitre
into linaro-3.0
2011-07-21Merge remote-tracking branch 'linus' into linaro-3.0Nicolas Pitre
2011-07-21Linux 3.0v3.0Linus Torvalds
2011-07-21Revert "Merge remote-tracking branch 'arm-soc/for-next' into linaro-3.0"Nicolas Pitre
This reverts commit c7e0c8535d73f8c5bf760926a2bd71c9840cf2ef, reversing changes made to dfee09c8acf18e84fe197bb5d821d1e4e02d020f. John Stultz reports that Panda doesn't boot anymore and 'git bisect' indicated the merge commit itself as the culprit. The resulting kernel log is: [ 1.734802] OMAP DSS rev 4.0 [ 1.740417] omap_hwmod: dss_core: _wait_target_disable failed [ 1.746429] omap_device: omapdss_dss.-1: new worst case deactivate latency 01 [ 1.755035] omapdss DISPC error: can't get dss_clk [ 1.760101] omapdss_dispc: probe of omapdss_dispc failed with error -2 [ 1.767333] omapdss HDMI error: can't get hdmi_clk [ 1.772399] omapdss_hdmi: probe of omapdss_hdmi failed with error -2 [ 1.780273] ------------[ cut here ]------------ [ 1.785125] WARNING: at drivers/video/omap2/dss/dispc.c:553dispc_runtime_ge) [ 1.793640] Modules linked in: [ 1.796905] ---[ end trace 6fcb132ac310d004 ]--- [ 1.801757] Unable to handle kernel NULL pointer dereference at virtualaddr0 [...] Revert it so a later version of the arm-soc merge result can be used instead.
2011-07-21Merge branch 'for_linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb: sparc,kgdbts: fix compile regression with kgdb test suite
2011-07-21sparc,kgdbts: fix compile regression with kgdb test suiteJason Wessel
Commit 63ab25ebbc (kgdbts: unify/generalize gdb breakpoint adjustment) introduced a compile regression on sparc. kgdbts.c: In function 'check_and_rewind_pc': kgdbts.c:307: error: implicit declaration of function 'instruction_pointer_set' Simply add the correct macro definition for instruction pointer on the Sparc architecture. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Acked-by: David S. Miller <davem@davemloft.net>
2011-07-21dt: Linux dt usage model documentationGrant Likely
v2: 2nd draft - Editorial cleanups from Randy Dunlap Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21mmc/tegra: add sdhci device tree handlingGrant Likely
This patch adds support for configuring the NVIDIA tegra250 sdhci device from the device tree. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21i2c: Tegra: Add device tree supportGrant Likely
This patch modifies the tegra i2c driver so that it can be initialized using the device tree along with the devices connected to the i2c bus. Signed-off-by: John Bonesio <bones@secretlab.ca> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21spi/tegra: add devicetree supportGrant Likely
Allow the tegra spi driver to obtain populate the spi bus with devices from the device tree. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21gpio/tegra: add devicetree supportGrant Likely
Add support for decoding gpios from the device tree Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21of/gpio: Add new method for getting gpios under different property namesJohn Bonesio
This patch adds a new routine, of_get_named_gpio_flags(), which takes the property name as a parameter rather than assuming "gpios". of_get_gpio_flags() is modified to call of_get_named_gpio_flags() with "gpios" as the property parameter. Signed-off-by: John Bonesio <bones@secretlab.ca> [grant.likely: Tidied up whitespace and tweaked kerneldoc comments.] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21gpio/dt: Refine GPIO device tree bindingGrant Likely
Allow for multiple named gpio properties Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21i2c: Allow i2c_add_numbered_adapter() to assign a bus id.Grant Likely
Currently, if an i2c bus driver supports both static and dynamic bus ids, it needs to choose between calling i2c_add_numbered_adapter() and i2c_add_adapter(). This patch makes i2c_add_numbered_adapter() redirect to i2c_add_adapter() if the requested bus id is -1. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21arm/dt: vexpress: add basic DT platform matching supportGrant Likely
This patch adds a DT match table to the Versatile Express machine description in order to enable basic device tree support. Tested on a Versatile Express board where the device tree blob is passed to the kernel by u-boot. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> [converted .dts file to use skeleton.dtsi, and added 'dtbs' targets] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21arm/dt: Add basic devicetree support to IGEPv2 and v3Grant Likely
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21arm/dt: Add a make rule to build dtb for enabled boardsShawn Guo
With 'make ARCH=arm dtbs', it builds Device Tree Blobs for those boards enabled by build CONFIG. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21arm/dt: Add basic device tree support for BeagleboardGrant Likely
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21arm/dt: Add basic device tree support for mx51 and mx53 boardsGrant Likely
This patch add support for the Genesi Efika MX Smarttop and Smartbook, the Freescale mx51 babbage board, and the Freescale mx53 loco board Signed-off-by: Jason Liu <jason.hui@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21arm/dt: Add basic device tree support for overoAndy Doan
Enable basic device tree support for Gumstix Overo. tested with Overo Tide COM and Tobi expansion board Signed-off-by: Andy Doan <andy.doan@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21arm/dt: Add basic device tree support for smdkv310 boardThomas Abraham
Enable basic device tree support for Exynos4 smdkv310 board. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-07-21arm/dt: Add Pandaboard devicetree supportGrant Likely
Enable basic device tree support on Pandaboard Signed-off-by: Grant Likely <grant.likely@linaro.org>
2011-07-21Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6Linus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6: CIFS: Fix wrong length in cifs_iovec_read
2011-07-21Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: Make Dell Latitude E6420 use reboot=pci x86: Make Dell Latitude E5420 use reboot=pci
2011-07-21x86: Make Dell Latitude E6420 use reboot=pciH. Peter Anvin
Yet another variant of the Dell Latitude series which requires reboot=pci. From the E5420 bug report by Daniel J Blueman: > The E6420 is affected also (same platform, different casing and > features), which provides an external confirmation of the issue; I can > submit a patch for that later or include it if you prefer: > http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/ Reported-by: Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: <stable@kernel.org>
2011-07-21x86: Make Dell Latitude E5420 use reboot=pciDaniel J Blueman
Rebooting on the Dell E5420 often hangs with the keyboard or ACPI methods, but is reliable via the PCI method. [ hpa: this was deferred because we believed for a long time that the recent reshuffling of the boot priorities in commit 660e34cebf0a11d54f2d5dd8838607452355f321 fixed this platform. Unfortunately that turned out to be incorrect. ] Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> Link: http://lkml.kernel.org/r/1305248699-2347-1-git-send-email-daniel.blueman@gmail.com Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: <stable@kernel.org>
2011-07-21Merge branch 'drm-intel-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6 * 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: drm/i915: Fix unfenced alignment on pre-G33 hardware drm/i915: Add quirk to disable SSC on Lenovo U160 LVDS
2011-07-21vfs: drop conditional inode prefetch in __do_lookup_rcuLinus Torvalds
It seems to hurt performance in real life. Yes, the inode will be used later, but the conditional doesn't seem to predict all that well (negative dentries are not uncommon) and it looks like the cost of prefetching is simply higher than depending on the cache doing the right thing. As usual. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-07-21FS-Cache: Fix __fscache_uncache_all_inode_pages()'s outer loopJan Beulich
The compiler, at least for ix86 and m68k, validly warns that the comparison: next <= (loff_t)-1 is always true (and it's always true also for x86-64 and probably all other arches - as long as pgoff_t isn't wider than loff_t). The intention appears to be to avoid wrapping of "next", so rather than eliminating the pointless comparison, fix the loop to indeed get exited when "next" would otherwise wrap. On m68k the following warning is observed: fs/fscache/page.c: In function '__fscache_uncache_all_inode_pages': fs/fscache/page.c:979: warning: comparison is always false due to limited range of data type Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Reported-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: David Howells <dhowells@redhat.com> Cc: Suresh Jayaraman <sjayaraman@suse.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-07-21ARM: Fix build errors caused by adding generic macrosRussell King
Commit 66a625a (ARM: mm: proc-macros: Add generic proc/cache/tlb struct definition macros) introduced build errors when PM_SLEEP is not enabled. The per-CPU do_suspend/do_resume functions are defined via the preprocessor to constant 0. However, the macros which use these were converted to assembly, resulting in undefined references to these functions. Fix that by moving the ! ifdef section into proc-macros.S and deleting it from all effected proc-*.S files. Acked-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-21ARM: CPU hotplug: ensure we migrate all IRQs off a downed CPURussell King
Our selection of interrupts to consider for IRQ migration is sub- standard. We were potentially including per-CPU interrupts in our migration strategy, but omitting chained interrupts. This caused some interrupts to remain on a downed CPU. We were also trying to migrate interrupts which were not migratable, resulting in an OOPS. Instead, iterate over all interrupts, skipping per-CPU interrupts or interrupts whose affinity does not include the downed CPU, and attempt to set the affinity for every one else if their chip implements irq_set_affinity(). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-21ARM: CPU hotplug: pass in proper affinity mask on IRQ migrationRussell King
Now that the GIC takes care of selecting a target interrupt from the affinity mask, we don't need all this complexity in the core code anymore. Just detect when we need to break affinity. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-21ARM: GIC: avoid routing interrupts to offline CPUsRussell King
The irq_set_affinity() method can be called with masks which include offline CPUs. This allows offline CPUs to have interrupts routed to them by writing to /proc/irq/*/smp_affinity after hotplug has taken a CPU offline. Fix this by ensuring that we select a target CPU present in both the required affinity and the online CPU mask. Ensure that we return IRQ_SET_MASK_OK (which happens to be 0) on success to ensure generic code copies the new mask into the irq_data structure. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-21ARM: CPU hotplug: fix abuse of irqdesc->nodeRussell King
irqdesc's node member is supposed to mark the numa node number for the interrupt. Our use of it is non-standard. Remove this, replacing the functionality with a test of the affinity mask. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-21CIFS: Fix wrong length in cifs_iovec_readPavel Shilovsky
Signed-off-by: Pavel Shilovsky <piastryyy@gmail.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2011-07-20Merge branch 'core-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: signal: align __lock_task_sighand() irq disabling and RCU softirq,rcu: Inform RCU of irq_exit() activity sched: Add irq_{enter,exit}() to scheduler_ipi() rcu: protect __rcu_read_unlock() against scheduler-using irq handlers rcu: Streamline code produced by __rcu_read_unlock() rcu: Fix RCU_BOOST race handling current->rcu_read_unlock_special rcu: decrease rcu_report_exp_rnp coupling with scheduler
2011-07-20Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: sched: Avoid creating superfluous NUMA domains on non-NUMA systems sched: Allow for overlapping sched_domain spans sched: Break out cpu_power from the sched_group structure
2011-07-20Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86. reboot: Make Dell Latitude E6320 use reboot=pci x86, doc only: Correct real-mode kernel header offset for init_size x86: Disable AMD_NUMA for 32bit for now
2011-07-20Merge branch 'rcu/urgent' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu into core/urgent
2011-07-20signal: align __lock_task_sighand() irq disabling and RCUPaul E. McKenney
The __lock_task_sighand() function calls rcu_read_lock() with interrupts and preemption enabled, but later calls rcu_read_unlock() with interrupts disabled. It is therefore possible that this RCU read-side critical section will be preempted and later RCU priority boosted, which means that rcu_read_unlock() will call rt_mutex_unlock() in order to deboost itself, but with interrupts disabled. This results in lockdep splats, so this commit nests the RCU read-side critical section within the interrupt-disabled region of code. This prevents the RCU read-side critical section from being preempted, and thus prevents the attempt to deboost with interrupts disabled. It is quite possible that a better long-term fix is to make rt_mutex_unlock() disable irqs when acquiring the rt_mutex structure's ->wait_lock. Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2011-07-20softirq,rcu: Inform RCU of irq_exit() activityPeter Zijlstra
The rcu_read_unlock_special() function relies on in_irq() to exclude scheduler activity from interrupt level. This fails because exit_irq() can invoke the scheduler after clearing the preempt_count() bits that in_irq() uses to determine that it is at interrupt level. This situation can result in failures as follows: $task IRQ SoftIRQ rcu_read_lock() /* do stuff */ <preempt> |= UNLOCK_BLOCKED rcu_read_unlock() --t->rcu_read_lock_nesting irq_enter(); /* do stuff, don't use RCU */ irq_exit(); sub_preempt_count(IRQ_EXIT_OFFSET); invoke_softirq() ttwu(); spin_lock_irq(&pi->lock) rcu_read_lock(); /* do stuff */ rcu_read_unlock(); rcu_read_unlock_special() rcu_report_exp_rnp() ttwu() spin_lock_irq(&pi->lock) /* deadlock */ rcu_read_unlock_special(t); Ed can simply trigger this 'easy' because invoke_softirq() immediately does a ttwu() of ksoftirqd/# instead of doing the in-place softirq stuff first, but even without that the above happens. Cure this by also excluding softirqs from the rcu_read_unlock_special() handler and ensuring the force_irqthreads ksoftirqd/# wakeup is done from full softirq context. [ Alternatively, delaying the ->rcu_read_lock_nesting decrement until after the special handling would make the thing more robust in the face of interrupts as well. And there is a separate patch for that. ] Cc: Thomas Gleixner <tglx@linutronix.de> Reported-and-tested-by: Ed Tomlinson <edt@aei.ca> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2011-07-20sched: Add irq_{enter,exit}() to scheduler_ipi()Peter Zijlstra
Ensure scheduler_ipi() calls irq_{enter,exit} when it does some actual work. Traditionally we never did any actual work from the resched IPI and all magic happened in the return from interrupt path. Now that we do do some work, we need to ensure irq_{enter,exit} are called so that we don't confuse things. This affects things like timekeeping, NO_HZ and RCU, basically everything with a hook in irq_enter/exit. Explicit examples of things going wrong are: sched_clock_cpu() -- has a callback when leaving NO_HZ state to take a new reading from GTOD and TSC. Without this callback, time is stuck in the past. RCU -- needs in_irq() to work in order to avoid some nasty deadlocks Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2011-07-20rcu: protect __rcu_read_unlock() against scheduler-using irq handlersPaul E. McKenney
The addition of RCU read-side critical sections within runqueue and priority-inheritance lock critical sections introduced some deadlock cycles, for example, involving interrupts from __rcu_read_unlock() where the interrupt handlers call wake_up(). This situation can cause the instance of __rcu_read_unlock() invoked from interrupt to do some of the processing that would otherwise have been carried out by the task-level instance of __rcu_read_unlock(). When the interrupt-level instance of __rcu_read_unlock() is called with a scheduler lock held from interrupt-entry/exit situations where in_irq() returns false, deadlock can result. This commit resolves these deadlocks by using negative values of the per-task ->rcu_read_lock_nesting counter to indicate that an instance of __rcu_read_unlock() is in flight, which in turn prevents instances from interrupt handlers from doing any special processing. This patch is inspired by Steven Rostedt's earlier patch that similarly made __rcu_read_unlock() guard against interrupt-mediated recursion (see https://lkml.org/lkml/2011/7/15/326), but this commit refines Steven's approach to avoid the need for preemption disabling on the __rcu_read_unlock() fastpath and to also avoid the need for manipulating a separate per-CPU variable. This patch avoids need for preempt_disable() by instead using negative values of the per-task ->rcu_read_lock_nesting counter. Note that nested rcu_read_lock()/rcu_read_unlock() pairs are still permitted, but they will never see ->rcu_read_lock_nesting go to zero, and will therefore never invoke rcu_read_unlock_special(), thus preventing them from seeing the RCU_READ_UNLOCK_BLOCKED bit should it be set in ->rcu_read_unlock_special. This patch also adds a check for ->rcu_read_unlock_special being negative in rcu_check_callbacks(), thus preventing the RCU_READ_UNLOCK_NEED_QS bit from being set should a scheduling-clock interrupt occur while __rcu_read_unlock() is exiting from an outermost RCU read-side critical section. Of course, __rcu_read_unlock() can be preempted during the time that ->rcu_read_lock_nesting is negative. This could result in the setting of the RCU_READ_UNLOCK_BLOCKED bit after __rcu_read_unlock() checks it, and would also result it this task being queued on the corresponding rcu_node structure's blkd_tasks list. Therefore, some later RCU read-side critical section would enter rcu_read_unlock_special() to clean up -- which could result in deadlock if that critical section happened to be in the scheduler where the runqueue or priority-inheritance locks were held. This situation is dealt with by making rcu_preempt_note_context_switch() check for negative ->rcu_read_lock_nesting, thus refraining from queuing the task (and from setting RCU_READ_UNLOCK_BLOCKED) if we are already exiting from the outermost RCU read-side critical section (in other words, we really are no longer actually in that RCU read-side critical section). In addition, rcu_preempt_note_context_switch() invokes rcu_read_unlock_special() to carry out the cleanup in this case, which clears out the ->rcu_read_unlock_special bits and dequeues the task (if necessary), in turn avoiding needless delay of the current RCU grace period and needless RCU priority boosting. It is still illegal to call rcu_read_unlock() while holding a scheduler lock if the prior RCU read-side critical section has ever had either preemption or irqs enabled. However, the common use case is legal, namely where then entire RCU read-side critical section executes with irqs disabled, for example, when the scheduler lock is held across the entire lifetime of the RCU read-side critical section. Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2011-07-20sched: Avoid creating superfluous NUMA domains on non-NUMA systemsPeter Zijlstra
When creating sched_domains, stop when we've covered the entire target span instead of continuing to create domains, only to later find they're redundant and throw them away again. This avoids single node systems from touching funny NUMA sched_domain creation code and reduces the risks of the new SD_OVERLAP code. Requested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Anton Blanchard <anton@samba.org> Cc: mahesh@linux.vnet.ibm.com Cc: benh@kernel.crashing.org Cc: linuxppc-dev@lists.ozlabs.org Link: http://lkml.kernel.org/r/1311180177.29152.57.camel@twins Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-07-20Merge remote-tracking branch 'arm-soc/for-next' into linaro-3.0Nicolas Pitre
2011-07-20sched: Allow for overlapping sched_domain spansPeter Zijlstra
Allow for sched_domain spans that overlap by giving such domains their own sched_group list instead of sharing the sched_groups amongst each-other. This is needed for machines with more than 16 nodes, because sched_domain_node_span() will generate a node mask from the 16 nearest nodes without regard if these masks have any overlap. Currently sched_domains have a sched_group that maps to their child sched_domain span, and since there is no overlap we share the sched_group between the sched_domains of the various CPUs. If however there is overlap, we would need to link the sched_group list in different ways for each cpu, and hence sharing isn't possible. In order to solve this, allocate private sched_groups for each CPU's sched_domain but have the sched_groups share a sched_group_power structure such that we can uniquely track the power. Reported-and-tested-by: Anton Blanchard <anton@samba.org> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/n/tip-08bxqw9wis3qti9u5inifh3y@git.kernel.org Signed-off-by: Ingo Molnar <mingo@elte.hu>