On Tue, Jan 22, 2013 at 01:06:34PM +0530, Srivatsa S. Bhat wrote:
> Don't refer to stop_machine() in the CPU hotplug path, since we are going
> to get rid of it. Also, move the comment referring to callback adoption
> to the CPU_DEAD case, because that's where it happens now.
>
> Signed-off-by: Sr
On Tue, Jan 22, 2013 at 01:15:48PM +0530, Srivatsa S. Bhat wrote:
> Since stop_machine() is no longer used in the CPU offline path, we cannot
> disable CPU hotplug using preempt_disable()/local_irq_disable() etc. We
> need to use the newly introduced get/put_online_cpus_atomic() APIs.
> Reflect thi
On Tue, Jan 22, 2013 at 01:15:22PM +0530, Srivatsa S. Bhat wrote:
> ... and also cleanup a comment that refers to CPU hotplug being dependent on
> stop_machine().
>
> Cc: David Howells
> Signed-off-by: Srivatsa S. Bhat
Reviewed-by: Paul E. McKenney
(Hey, I thought I owed myself an easy one!)
On Tue, Jan 22, 2013 at 01:05:10PM +0530, Srivatsa S. Bhat wrote:
> Once stop_machine() is gone from the CPU offline path, we won't be able to
> depend on preempt_disable() to prevent CPUs from going offline from under us.
>
> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going of
On Tue, Jan 22, 2013 at 01:05:02PM +0530, Srivatsa S. Bhat wrote:
> On 12/05/2012 06:10 AM, Andrew Morton wrote:
> "static inline C functions would be preferred if possible. Feel free to
> fix up the wrong crufty surrounding code as well ;-)"
>
> Convert the macros in the CPU hotplug code to stat
On Tue, Jan 22, 2013 at 01:04:54PM +0530, Srivatsa S. Bhat wrote:
> There are places where preempt_disable() or local_irq_disable() are used
> to prevent any CPU from going offline during the critical section. Let us
> call them as "atomic hotplug readers" ("atomic" because they run in atomic,
> no
On Tue, Jan 22, 2013 at 01:04:23PM +0530, Srivatsa S. Bhat wrote:
> CPU hotplug (which will be the first user of per-CPU rwlocks) has a special
> requirement with respect to locking: the writer, after acquiring the per-CPU
> rwlock for write, must be allowed to take the same lock for read, without
On Tue, Jan 22, 2013 at 01:04:11PM +0530, Srivatsa S. Bhat wrote:
> If interrupt handlers can also be readers, then one of the ways to make
> per-CPU rwlocks safe, is to disable interrupts at the reader side before
> trying to acquire the per-CPU rwlock and keep it disabled throughout the
> duratio
Hi,
i'm using OpenWRT petitboot bootloader on my PS3 to boot FreeBSD loader which
is a simple PPC32 ELF file.
I haven't had any issues with it and OpenWRT based on Linux 3.3.8.
Recently i built an OpenWRT image with Linux 3.7, i have no issues at all with
kexec and any Linux kernels starting wi
On Tue, Jan 22, 2013 at 01:03:53PM +0530, Srivatsa S. Bhat wrote:
> Using global rwlocks as the backend for per-CPU rwlocks helps us avoid many
> lock-ordering related problems (unlike per-cpu locks). However, global
> rwlocks lead to unnecessary cache-line bouncing even when there are no
> writers
On Tue, Jan 29, 2013 at 08:12:37PM +0900, Namhyung Kim wrote:
> On Thu, 24 Jan 2013 10:00:04 +0530, Srivatsa S. Bhat wrote:
> > On 01/24/2013 01:27 AM, Tejun Heo wrote:
> >> On Thu, Jan 24, 2013 at 01:03:52AM +0530, Srivatsa S. Bhat wrote:
> >>> CPU 0 CPU 1
> >>>
> >>> read
Hi,
On iMac G5 (the first model, windfarm_pm81 reports "model 3"), enabling
LOCKDEP results in the following warnings when overtemp condition is
encountered.
The kernel is 3.8-rc6+ / 6bacaa9.
[ 7060.058340] windfarm: Clamping CPU frequency to minimum !
[ 7060.229688]
[ 7060.229756]
From: Stuart Yoder
Signed-off-by: Stuart Yoder
---
-removed KVM prefix to patch subject, patch is not KVM specific
arch/powerpc/kernel/epapr_hcalls.S |2 ++
arch/powerpc/kernel/idle_book3e.S | 32 ++--
2 files changed, 32 insertions(+), 2 deletions(-)
diff
On 02/08/2013 10:14 PM, Srivatsa S. Bhat wrote:
> On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
>> On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
>>> On 02/07/2013 09:44 AM, Rusty Russell wrote:
"Srivatsa S. Bhat" writes:
> On 01/22/2013 01:03 PM, Srivatsa S.
Hi Stefan,
On Fri, 8 Feb 2013 17:12:32 +0100
Stefan Roese wrote:
> Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
> (U-Boot) to write the MAC address into the ethernet controller
> registers. The Linux driver should not rely on such a thing. So
> lets read the MAC address
On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
> On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
>> On 02/07/2013 09:44 AM, Rusty Russell wrote:
>>> "Srivatsa S. Bhat" writes:
On 01/22/2013 01:03 PM, Srivatsa S. Bhat wrote:
Avg. latency of 1 CP
Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
(U-Boot) to write the MAC address into the ethernet controller
registers. The Linux driver should not rely on such a thing. So
lets read the MAC address from the DT as it should be done here.
This fixes a problem with a MPC5200
On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
> On 02/07/2013 09:44 AM, Rusty Russell wrote:
> > "Srivatsa S. Bhat" writes:
> >> On 01/22/2013 01:03 PM, Srivatsa S. Bhat wrote:
> >> Avg. latency of 1 CPU offline (ms) [stop-cpu/stop-m/c
> >> latency]
> >>
> >>
Commit-ID: 02fc8d37229d15c654876cf9ce56b5c1cf7945d7
Gitweb: http://git.kernel.org/tip/02fc8d37229d15c654876cf9ce56b5c1cf7945d7
Author: Stephen Rothwell
AuthorDate: Fri, 8 Feb 2013 14:19:38 +1100
Committer: Ingo Molnar
CommitDate: Fri, 8 Feb 2013 15:23:12 +0100
cputime: Restore CPU_ACCO
2013/2/8 Stephen Rothwell :
> Hi Frederic,
>
> On Fri, 8 Feb 2013 14:07:49 +1100 Stephen Rothwell
> wrote:
>>
>> This patch has the side effect of changing the default configurations:
>> (This is PowerPC pseries_defconfig before/after this patch)
>>
>> @@ -119,8 +120,8 @@
>> #
>> # CPU/Task tim
Memory allocated to rtas_firmware_flash_list in rtas_flash_write
is not freed during module exit. We hit below call trace if we
unload rtas_flash module after loading new firmware image and
before rebooting the system.
Call trace:
--
Feb 6 08:42:10 eagle3 kernel: kmem_cache_destroy rtas_f
21 matches
Mail list logo
