ed H_CEDE.
>
> This fixes a hang during boot on pSeries.
>
> Signed-off-by: Anton Blanchard
Acked-by: Paul E. McKenney
> ---
>
> Index: linux-build/arch/powerpc/kernel/idle.c
> ===
> --- linux-build.o
The variable cpus_in_crash gets a defined-but-not-used warning when
CONFIG_SMP=n, so fix by placing the variable under ifdef.
Signed-off-by: Paul E. McKenney
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 28be345..eb3384e 100644
--- a/arch/powerpc/kernel/crash.c
On Wed, Feb 01, 2012 at 03:28:34PM -0500, Paul Gortmaker wrote:
> On 12-02-01 01:55 PM, Paul E. McKenney wrote:
> > The variable cpus_in_crash gets a defined-but-not-used warning when
> > CONFIG_SMP=n, so fix by placing the variable under ifdef.
>
> I think Ben already
g-pong latency test across two CPUs on
> different cores of a POWER7 machine.
>
> The analysis of the reason why processes were not waking up properly
> is due to Milton Miller.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Milton Miller
> Signed-off-by: Paul Mackerra
to zero CPUs. This change
has the beneficial side effect of rendering all kernel bugs harmless.
Furthermore, this commit enables additional beneficial changes, for
example, the removal of those parts of the kernel that are not needed
when there are zero CPUs.
Signed-off-by: Paul E. McKenney
On Sat, Mar 31, 2012 at 06:40:30PM +0200, Geert Uytterhoeven wrote:
> Hi Paul,
>
> On Sat, Mar 31, 2012 at 18:33, Paul E. McKenney
> wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 yea
ed during kernel
builds. I have added your Acked-by. ;-)
Thanx, Paul
> On 31 March 2012 11:33, Paul E. McKenney wrote:
>
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > tr
On Sat, Mar 31, 2012 at 01:25:02PM -0700, Randy Dunlap wrote:
> On 03/31/2012 01:15 PM, Linas Vepstas wrote:
>
> >
> > Hi,
> >
> > I didn't actually try to compile the patch below; it didn't look like
> > C code so I wasn't sure what compiler to run it through. I guess maybe
> > its python? Ho
On Sat, Mar 31, 2012 at 11:00:08PM +0200, Eric Dumazet wrote:
> On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> &
e doing what I suspect
you are, you will end up with a very large patch set. ;-)
Thanx, Paul
> Regards,
>
> Lorenz Kolb
>
> Am 31.03.2012 23:21, schrieb Paul E. McKenney:
> >On Sat, Mar 31, 2012 at 11:00:08PM +0200,
On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the
On Sun, Apr 01, 2012 at 12:04:48PM +0200, Borislav Petkov wrote:
> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
&g
On Sun, Apr 01, 2012 at 07:34:55PM +0200, Thomas Gleixner wrote:
> On Sat, 31 Mar 2012, Russell King - ARM Linux wrote:
>
> > On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > > Although there have been numerous complaints about the complexity of
>
On Mon, Apr 30, 2012 at 03:37:10PM -0700, Hugh Dickins wrote:
> Hi Paul,
>
> On 3.4.0-rc4-next-20120427 and preceding linux-nexts (I've not tried
> rc5-next-20120430 but expect it's the same), on PowerPC G5 quad with
> CONFIG_PREEMPT=y and CONFIG_DEBUG_ATOMIC_SLEEP=y, I'm getting spurious
> "BUG:
On Tue, May 01, 2012 at 10:33:38AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
> >
> > BUG: sleeping function called from invalid context at
> > include/linux/pagemap.h:354
> > in_atomic(): 0, irqs_disabled(): 0, pid: 6886, name: cc1
>
> Hrm ...
90aec3b06194393c909e3e5a47b6ed99bb8caba5
>
> from which I concluded that the patch responsible is
>
> commit ab8fc41a8545d40a4b58d745876c125af72a8a5c
> Author: Paul E. McKenney
> Date: Fri Apr 13 14:32:01 2012 -0700
>
> rcu: Move __rcu_read_lock() and __rcu_read_unlock() to per-
On Tue, May 01, 2012 at 02:42:02PM -0700, Hugh Dickins wrote:
> On Tue, 1 May 2012, Paul E. McKenney wrote:
> > On Mon, Apr 30, 2012 at 10:10:06PM -0700, Hugh Dickins wrote:
> > > On Tue, 1 May 2012, Benjamin Herrenschmidt wrote:
> > > > On Mon, 2012-04-30 at 1
On Wed, May 02, 2012 at 01:25:30PM -0700, Hugh Dickins wrote:
> On Tue, 1 May 2012, Paul E. McKenney wrote:
> > > > > > On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
> > > > > > >
> > > > > > > BUG: sleeping function called
On Wed, May 02, 2012 at 01:49:54PM -0700, Paul E. McKenney wrote:
> On Wed, May 02, 2012 at 01:25:30PM -0700, Hugh Dickins wrote:
> > On Tue, 1 May 2012, Paul E. McKenney wrote:
> > > > > > > On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
> > > &
On Wed, May 02, 2012 at 02:32:38PM -0700, Paul E. McKenney wrote:
> On Wed, May 02, 2012 at 01:49:54PM -0700, Paul E. McKenney wrote:
> > On Wed, May 02, 2012 at 01:25:30PM -0700, Hugh Dickins wrote:
> > > On Tue, 1 May 2012, Paul E. McKenney wrote:
> > > > >
On Thu, May 03, 2012 at 07:20:15AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-05-02 at 13:25 -0700, Hugh Dickins wrote:
> > Got it at last. Embarrassingly obvious. __rcu_read_lock() and
> > __rcu_read_unlock() are not safe to be using __this_cpu operations,
> > the cpu may change in betw
On Wed, May 02, 2012 at 03:54:24PM -0700, Hugh Dickins wrote:
> On Wed, May 2, 2012 at 2:54 PM, Paul E. McKenney
> wrote:
> > On Thu, May 03, 2012 at 07:20:15AM +1000, Benjamin Herrenschmidt wrote:
> >> On Wed, 2012-05-02 at 13:25 -0700, Hugh Dickins wrote:
> >> >
On Mon, May 07, 2012 at 09:21:54AM -0700, Hugh Dickins wrote:
> On Wed, 2 May 2012, Hugh Dickins wrote:
> > On Wed, 2 May 2012, Paul E. McKenney wrote:
> > >
> > > In any case, I must confess that I feel quite silly about my series
> > > of patches. I have re
On Tue, May 29, 2012 at 03:16:04PM +0800, Yong Zhang wrote:
> From: Yong Zhang
>
> 1) call_function.lock used in smp_call_function_many() is just to protect
>call_function.queue and &data->refs, cpu_online_mask is outside of the
>lock. And it's not necessary to protect cpu_online_mask,
>
On Sat, Jun 16, 2012 at 07:30:58PM +0200, Peter Zijlstra wrote:
> On Sat, 2012-06-16 at 09:32 -0700, Paul E. McKenney wrote:
> > However, there is an effort to get rid of stop_machine() from the
> > CPU-down path... So something else will be needed.
>
> Elsewhere in this
On Mon, Jun 18, 2012 at 10:35:46AM +1000, Benjamin Herrenschmidt wrote:
> Hi Paul !
>
> I was about to go debug something else when I hit that with -rc3 (plus
> the patch to fix the current bug.h breakage) on a 32-bit PowerMac G4 SMP
> (2 CPUs): About 1mn pause at boot followed by a bunch of RCU s
On Mon, Jun 18, 2012 at 10:51:59AM +0800, Yong Zhang wrote:
> On Sat, Jun 16, 2012 at 09:32:19AM -0700, Paul E. McKenney wrote:
> > On Tue, May 29, 2012 at 03:16:04PM +0800, Yong Zhang wrote:
> > > From: Yong Zhang
> > >
> > > 1) call_function.lock used in
On Tue, Jun 19, 2012 at 06:45:31AM +1000, Benjamin Herrenschmidt wrote:
> Hi Paul !
>
> On Mon, 2012-06-18 at 10:05 -0700, Paul E. McKenney wrote:
>
> > > sd 0:0:0:0: Attached scsi generic sg0 type 0
> > > sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9
On Mon, Jun 18, 2012 at 02:58:57PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 19, 2012 at 06:45:31AM +1000, Benjamin Herrenschmidt wrote:
> > Hi Paul !
> >
> > On Mon, 2012-06-18 at 10:05 -0700, Paul E. McKenney wrote:
> >
> > > > sd 0:0:0:0: Attached scs
On Sun, Jul 01, 2012 at 11:30:40PM -0700, Christian Kujau wrote:
> On Mon, 2 Jul 2012 at 14:50, Benjamin Herrenschmidt wrote:
> > Interesting... I observed something roughly similar on a dual G4
> > the other day associated with a 30s to 1mn pause during boot. RCU
> > was complaining loudly.
> >
>
Hello!
This series provides fixes for a couple of CONFIG_PREEMPT problems on
Power:
1. The hpte_need_flush() function accesses per-CPU variables without
protection.
2. The rtas_event_scan() function needs to use raw_smp_processor_id()
to get a starting point to avoid deb
The hpte_need_flush() function accesses the ppc64_tlb_batch per-CPU
variable with preemption enabled, a bug that this patch fixes. Perhaps
crudely.
Signed-off-by: Paul E. McKenney
---
arch/powerpc/include/asm/pgtable-ppc64.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff
The rtas_event_scan() function uses smp_processor_id() to select a
starting point in cpu_online_mask, and does so under the protection
of get_online_cpus(). This might not select the current processor
in any case, so switch to raw_smp_processor_id().
Signed-off-by: Paul E. McKenney
---
arch
The function crash_kexec_wait_realmode() is defined only if SMP, but is
called in UP builds. Create an empty function to keep the compiler happy
in UP builds.
Signed-off-by: Paul E. McKenney
Signed-off-by: Paul E. McKenney
diff --git a/arch
On Fri, Apr 15, 2011 at 02:00:51PM -0700, Nishanth Aravamudan wrote:
> Hi Paul,
>
> On 15.04.2011 [13:29:16 -0700], Paul E. McKenney wrote:
> > Hello!
> >
> > The following patch fixes a UP build problem for kexec() on powerpc.
> > When the crash_kexec_wait_real
he rcu lockdep because in 2.6.34 commit
> 2676a58c98 (radix-tree: Disable RCU lockdep checking in radix tree)
> deemed it too hard to pass the condition of the protecting lock
> to the library.
Reviewed-by: Paul E. McKenney
> Signed-off-by: Milton Miller
>
> Index: work.gi
of objects on stack.
Signed-off-by: Mathieu Desnoyers
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Paul E. McKenney
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index ebc2f38..2c7e801 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -
Hello!
I get the following during boot on a 16 CPU Power box. Thoughts?
(/proc/config attached)
Thanx, Paul
UDP hash table entries: 2048 (order: 6, 262144 bytes)
UDP-Lite hash table entries: 2048 (order: 6, 262144 bytes)
NET: Registered pr
On Thu, Jun 10, 2010 at 09:20:08AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > I get the following during boot on a 16 CPU Power box. Thoughts?
> > (/proc/config attached)
>
> Wow... lo
crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
Fix the conditional compilation around the invocation.
Untested, probably does not compile.
Signed-off-by: Paul E. McKenney
---
diff --git a/arch
_MMU_64 even if !CONFIG_SMP.
> > Fix the conditional compilation around the invocation.
> >
> > Untested, probably does not compile.
> >
> > Signed-off-by: Paul E. McKenney
>
> This should be right since we don't need to wait for the other CPUs if
> the
> understand this property it obliges and terminates our partition.
>
> Use DIV_ROUND_UP so we handle not only the CONFIG_SMP=n case but also the
> case where NR_CPUS isn't a multiple of the number of SMT threads.
Thank you, Anton!!!
Acked-by: Paul E. McKenney
(Will test as soo
On Wed, Jun 09, 2010 at 06:08:54PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 10, 2010 at 09:20:08AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > I get the following during b
Thanx, Paul
----
On Thu, Aug 05, 2010 at 01:31:10PM -0400, Ilia Mirkin wrote:
> On Thu, Jul 1, 2010 at 6:18 PM, Paul E. McKenney
> wrote:
> > On Thu, Jul 01, 2010 at
On Thu, Sep 16, 2010 at 05:50:31PM +0200, Peter Zijlstra wrote:
> On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
>
> > > [0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> > > [0.052999] lockdep: fixing up alternatives.
> > > [
On Tue, May 02, 2023 at 11:06:02PM +0800, zhouzho...@gmail.com wrote:
> From: Zhouyi Zhou
>
> Currently, default time between rcu torture forward-progress tests is 60HZ,
> Under this configuration, false positive caused by __stack_chk_fail [1] is
> difficult to reproduce (needs average 5*420 seco
On Wed, Sep 14, 2022 at 10:15:28AM +0800, Zhouyi Zhou wrote:
> During the cpu offlining, the sub functions of xive_teardown_cpu will
> call __lock_acquire when CONFIG_LOCKDEP=y. The latter function will
> travel RCU protected list, so "WARNING: suspicious RCU usage" will be
> triggered.
>
> Try to
On Thu, Jan 19, 2023 at 01:52:14PM +0100, Michal Hocko wrote:
> On Wed 18-01-23 11:01:08, Suren Baghdasaryan wrote:
> > On Wed, Jan 18, 2023 at 10:34 AM Paul E. McKenney
> > wrote:
> [...]
> > > There are a couple of possibilities here.
> > >
> > > F
On Thu, Jan 19, 2023 at 10:52:03AM -0800, Suren Baghdasaryan wrote:
> On Thu, Jan 19, 2023 at 4:59 AM Michal Hocko wrote:
> >
> > On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> > > call_rcu() can take a long time when callback offloading is enabled.
> > > Its use in the vm_area_free can cau
On Thu, Jan 19, 2023 at 11:47:36AM -0800, Suren Baghdasaryan wrote:
> On Thu, Jan 19, 2023 at 11:20 AM Paul E. McKenney wrote:
> >
> > On Thu, Jan 19, 2023 at 10:52:03AM -0800, Suren Baghdasaryan wrote:
> > > On Thu, Jan 19, 2023 at 4:59 AM Michal Hocko wrote:
> >
On Fri, Jan 20, 2023 at 09:57:05AM +0100, Michal Hocko wrote:
> On Thu 19-01-23 11:17:07, Paul E. McKenney wrote:
> > On Thu, Jan 19, 2023 at 01:52:14PM +0100, Michal Hocko wrote:
> > > On Wed 18-01-23 11:01:08, Suren Baghdasaryan wrote:
> > > > On Wed, Jan 18, 202
On Fri, Jan 20, 2023 at 04:49:42PM +, Matthew Wilcox wrote:
> On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote:
> > On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote:
> > > >
> > > > On Thu 19-01-23
On Wed, Jan 25, 2023 at 05:34:49PM -0800, Andrew Morton wrote:
> On Wed, 25 Jan 2023 16:50:01 -0800 Suren Baghdasaryan
> wrote:
>
> > On Wed, Jan 25, 2023 at 4:22 PM Andrew Morton
> > wrote:
> > >
> > > On Wed, 25 Jan 2023 15:35:48 -0800 Suren Baghdasaryan
> > > wrote:
> > >
> > > > Convert
gt; v1.1:
> - add __noreturn to all arch_cpu_idle_dead() implementations (mpe)
With this, rcutorture no longer gets objtool complaints on x86, thank you!
Tested-by: Paul E. McKenney
> Josh Poimboeuf (24):
> alpha/cpu: Expose arch_cpu_idle_dead()'s prototype declaration
> a
On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> A link from ibm.com states:
> "Ensures that all instructions preceding the call to __lwsync
> complete before any subsequent store instructions can be executed
> on the processor that executed the function. Also, it ensures that
>
On Thu, Feb 23, 2023 at 09:31:48AM +0530, Kautuk Consul wrote:
> On 2023-02-22 09:47:19, Paul E. McKenney wrote:
> > On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> > > A link from ibm.com states:
> > > "Ensures that all instructions preceding the
On Thu, Mar 23, 2023 at 04:55:54PM +0530, Sachin Sant wrote:
> While running rcutorture tests from LTP on an IBM Power10 server booted with
> 6.3.0-rc3-next-20230322 following warning is observed:
>
> [ 3629.242831] [ cut here ]
> [ 3629.242835] WARNING: CPU: 8 PID: 614614
On Thu, Mar 23, 2023 at 11:00:59PM +0530, Sachin Sant wrote:
>
> >> [ 3629.243407] NIP [7fff8cd39558] 0x7fff8cd39558
> >> [ 3629.243410] LR [00010d800398] 0x10d800398
> >> [ 3629.243413] --- interrupt: c00
> >> [ 3629.243415] Code: 419dffa4 e93a0078 3941 552907be 2f89 7d20579e
> >
On Fri, Mar 24, 2023 at 08:47:38AM +0530, Sachin Sant wrote:
>
> >>> Hello, Sachin, and it looks like you hit something that Zqiang and I
> >>> have been tracking down. I am guessing that you were using modprobe
> >>> and rmmod to make this happen, and that this happened at rmmod time.
> >>>
> >
On Sun, Mar 26, 2023 at 08:24:34AM +0800, zhouzho...@gmail.com wrote:
> From: Zhouyi Zhou
>
> The argument --enable-kvm is duplicated because qemu_args
> in kvm-test-1-run.sh has already give this.
>
> Signed-off-by: Zhouyi Zhou
Good catch! Applied, thank you!
/\ 1:r7=0)
> Observation SB+atomic_add+fetch Never 0 9
>
> [1] https://www.kernel.org/doc/Documentation/memory-barriers.txt
> [2] https://www.kernel.org/doc/Documentation/atomic_t.txt
>
> Fixes: 65112709115f ("powerpc/bpf/64: add support for BPF_ATOMIC bitwise
> ope
declared the CPU to be watched for readers.
>
> Link:
> https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/
> Signed-off-by: Qian Cai
Acked-by: Paul E. McKenney
> ---
> arch/powerpc/kernel/smp.c | 3 ++-
> 1 file changed, 2 insertions(+)
On Thu, Oct 29, 2020 at 11:09:07AM +1100, Michael Ellerman wrote:
> Qian Cai writes:
> > The call to rcu_cpu_starting() in start_secondary() is not early enough
> > in the CPU-hotplug onlining process, which results in lockdep splats as
> > follows:
>
> Since when?
> What kernel version?
>
> I h
On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote:
> During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to
> offline tick_do_timer_cpu, the operation will fail because in
> function tick_nohz_cpu_down:
> ```
> if (tick_nohz_full_running && tick_do_timer_cpu == cpu)
> return
On Wed, Nov 23, 2022 at 10:23:11AM +0800, Zhouyi Zhou wrote:
> On Tue, Nov 22, 2022 at 9:37 AM Paul E. McKenney wrote:
> >
> > On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote:
> > > During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to
> > &g
On Wed, Nov 23, 2022 at 11:25:43PM +0100, Frederic Weisbecker wrote:
> On Mon, Nov 21, 2022 at 05:37:54PM -0800, Paul E. McKenney wrote:
> > On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote:
> > > @@ -358,7 +359,16 @@ tortu
On Sun, Nov 27, 2022 at 01:40:28PM +0100, Thomas Gleixner wrote:
[ . . . ]
> >> No. We are not exporting this just to make a bogus test case happy.
> >>
> >> Fix the torture code to handle -EBUSY correctly.
> > I am going to do a study on this, for now, I do a grep in the kernel tree:
> > find .
On Mon, Nov 28, 2022 at 09:12:28AM +0100, Thomas Gleixner wrote:
> On Sun, Nov 27 2022 at 09:53, Paul E. McKenney wrote:
> > On Sun, Nov 27, 2022 at 01:40:28PM +0100, Thomas Gleixner wrote:
> >> There are quite some reasons why a CPU-hotplug or a hot-unplug operation
> >&g
Now that the SRCU Kconfig option is unconditionally selected, there is
no longer any point in selecting it. Therefore, remove the "select SRCU"
Kconfig statements.
Signed-off-by: Paul E. McKenney
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc:
---
arch/powerpc/k
On Thu, Jan 12, 2023 at 10:49:04AM +1100, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> > Now that the SRCU Kconfig option is unconditionally selected, there is
> > no longer any point in selecting it. Therefore, remove the "select SRCU"
> >
I know Mark has been prodding that with something sharp.
>
> The last version was tested by a number of people and I'm hoping to not have
> broken anything in the meantime ;-)
>
>
> Changes since v2:
150 rcutorture hours on each of the default scenarios passed. This
i
On Wed, Jan 18, 2023 at 10:04:39AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote:
> >
> > On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote:
> > > On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko wrote:
> > > >
> > > > On Mon 09-01-23 12:53:34, Suren Baghdasar
On Wed, Jan 18, 2023 at 11:01:08AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 10:34 AM Paul E. McKenney wrote:
> >
> > On Wed, Jan 18, 2023 at 10:04:39AM -0800, Suren Baghdasaryan wrote:
> > > On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote:
> >
rns out that it should have been
> synchronize_sched().
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/iseries/lpevents.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
On Wed, May 14, 2008 at 09:04:07PM +0530, Kamalesh Babulal wrote:
> Hi Andrew,
>
> 2.6.26-rc2-mm1 kernel panics on powerpc, while running ltp test over it.
> I have attached the gdb output of the pc and lr registers. The patch
> list_for_each_rcu-must-die-networking.patch points to changes made
>
On Thu, May 15, 2008 at 12:05:46AM +0400, Alexey Dobriyan wrote:
> On Wed, May 14, 2008 at 09:07:05AM -0700, Paul E. McKenney wrote:
> > On Wed, May 14, 2008 at 09:04:07PM +0530, Kamalesh Babulal wrote:
> > > Hi Andrew,
> > >
> > > 2.6.26-rc2-mm1 kernel panic
also to fix my bonehead error detected by Kamalesh Babulal and
Alexey Dobriyan. It now passes LTP on POWER. And also has valid SOB.
Some days it just doesn't pay to get out of bed...
Acked-by: David S. Miller <[EMAIL PROTECTED]> (lkml.org/lkml/2008/4/23/448)
Signed-off-by: Paul E. McKen
On Thu, May 22, 2008 at 02:18:17PM -0400, Steven Rostedt wrote:
>
> In rcupreempt, rcu_batches_completed_bh is defined as a static inline in
> the header file. This does not need to be exported, and not only that,
> this breaks my PPC build.
Good catch!!!
Reviewed-by: Paul E. McKe
Make powerpc refrain from clearing a given to-be-offlined CPU's bit in the
cpu_online_mask until it has processed pending irqs. This change
prevents other CPUs from being blindsided by an apparently offline CPU
nevertheless changing globally visible state.
Signed-off-by: Paul E. McKenney &l
On Mon, Sep 01, 2008 at 10:34:44AM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2008-08-31 at 10:31 -0700, Paul E. McKenney wrote:
> > Make powerpc refrain from clearing a given to-be-offlined CPU's bit in the
> > cpu_online_mask until it has processed pending irqs. This
On Mon, Sep 01, 2008 at 01:14:40PM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2008-08-31 at 19:06 -0700, Paul E. McKenney wrote:
> > On Mon, Sep 01, 2008 at 10:34:44AM +1000, Benjamin Herrenschmidt wrote:
> > > On Sun, 2008-08-31 at 10:31 -0700, Paul E. McKenney wrote:
&g
On Thu, Mar 10, 2022 at 10:37:12AM +0800, Zhouyi Zhou wrote:
> Dear Paul
>
> I try to reproduce the bug in ppc64 VM in Oregon State University
> using the vmlinux extracted from
> https://owww.molgen.mpg.de/~pmenzel/rcutorture-2022.02.01-21.52.37-torture-locktorture-kasan-lock01.tar.xz
>
> the pp
On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> Hi
>
> I can reproduce it in a ppc virtual cloud server provided by Oregon
> State University. Following is what I do:
> 1) curl -l
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.18-rc1.tar.gz
>
On Thu, Apr 07, 2022 at 02:25:59AM +0800, Zhouyi Zhou wrote:
> Hi Paul
>
> On Thu, Apr 7, 2022 at 1:00 AM Paul E. McKenney wrote:
> >
> > On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> > > Hi
> > >
> > > I can reproduce it
On Thu, Apr 07, 2022 at 12:07:34PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 7, 2022 at 4:27 AM Zhouyi Zhou wrote:
> >
> > Yes, this happens within 30 seconds after kernel boot. If we take all
> > into account (qemu preparing, kernel loading), we can do one test
> > within 54 seconds.
>
> When it
On Thu, Apr 07, 2022 at 07:05:58PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 7, 2022 at 5:15 PM Paul E. McKenney wrote:
> >
> > Ah. So you would instead look for boot to have completed within 10
> > seconds? Either way, reliable automation might well more important than
On Fri, Apr 08, 2022 at 07:14:20AM +0800, Zhouyi Zhou wrote:
> Dear Paul and Miguel
>
> On Fri, Apr 8, 2022 at 1:55 AM Paul E. McKenney wrote:
> >
> > On Thu, Apr 07, 2022 at 07:05:58PM +0200, Miguel Ojeda wrote:
> > > On Thu, Apr 7, 2022 at 5:15 PM
On Fri, Apr 08, 2022 at 05:23:32PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> > On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> >> Hi
> >>
> >> I can reproduce it in a ppc virtual cloud server provided by Oregon
On Fri, Apr 08, 2022 at 06:02:19PM +0800, Zhouyi Zhou wrote:
> On Fri, Apr 8, 2022 at 3:23 PM Michael Ellerman wrote:
> >
> > "Paul E. McKenney" writes:
> > > On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> > >> Hi
> > >&g
On Sat, Apr 09, 2022 at 12:42:39AM +1000, Michael Ellerman wrote:
> Michael Ellerman writes:
> > "Paul E. McKenney" writes:
> >> On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> >>> Hi
> >>>
> >>> I can reproduce
On Sun, Apr 10, 2022 at 09:33:43PM +1000, Michael Ellerman wrote:
> Zhouyi Zhou writes:
> > On Fri, Apr 8, 2022 at 10:07 PM Paul E. McKenney wrote:
> >> On Fri, Apr 08, 2022 at 06:02:19PM +0800, Zhouyi Zhou wrote:
> >> > On Fri, Apr 8, 2022 at 3:23 PM M
On Tue, Apr 12, 2022 at 04:53:06PM +1000, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
> > On Sun, Apr 10, 2022 at 09:33:43PM +1000, Michael Ellerman wrote:
> >> Zhouyi Zhou writes:
> >> > On Fri, Apr 8, 2022 at 10:07 PM Paul E. McKenney
> >
gt; Excerpts from Michael Ellerman's message of April 9, 2022 12:42 am:
> >> Michael Ellerman writes:
> >>> "Paul E. McKenney" writes:
> >>>> On Wed, Apr 06, 2022 at 05:31:10PM +0800, Zhouyi Zhou wrote:
> >>>>> Hi
> >&g
rttunen
> Cc: Neeraj Upadhyay
> Cc: Nicholas Piggin
> Cc: Paul Mackerras
> Cc: Suzuki K Poulose
> Cc: Thierry Reding
> Cc: Thomas Bogendoerfer
> Signed-off-by: Guilherme G. Piccoli
>From an RCU perspective:
Acked-by: Paul E. McKenney
> ---
> arch/arm64/kernel/setup
On Tue, May 17, 2022 at 11:22:04AM +0800, Chen Zhongjin wrote:
> On 2022/5/10 17:46, Chen Zhongjin wrote:
> > csdlock_debug uses early_param and static_branch_enable() to enable
> > csd_lock_wait feature, which triggers a panic on arm64 with config:
> > CONFIG_SPARSEMEM=y
> > CONFIG_SPARSEMEM_VMEMM
On Fri, Nov 27, 2020 at 01:02:29PM +1100, Daniel Axtens wrote:
> Hi all,
>
> I'm having some difficulty tracking down a bug.
>
> Some configurations of the powerpc kernel since somewhere in the 5.10
> merge window fail to boot on some ppc64 systems. They hang while trying
> to bring up SMP. It se
Hello, Linus,
This fix is for a regression in the v5.10 merge window, but it was
reported quite late in the v5.10 process, plus generating and testing
the fix took some time.
The regression is due to 36dadef23fcc ("kprobes: Init kprobes in
early_initcall") which on powerpc can use RCU Tasks befor
On Thu, May 21, 2020 at 02:51:24PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 19 May 2020 17:23:16 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the rcu tree got a conflict in:
> >
> > arch/powerpc/kernel/traps.c
> >
> > between commit:
> >
> > 116ac378bb3f
On Sat, May 25, 2019 at 10:19:54AM -0400, Joel Fernandes wrote:
> On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> > On Sat, 25 May 2019 04:14:44 -0400
> > Joel Fernandes wrote:
> >
> > > > I guess the difference between the _raw_notrace and just _raw variants
> > > > is that _no
On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
> On Sat, May 25, 2019 at 08:50:35AM -0700, Paul E. McKenney wrote:
> > On Sat, May 25, 2019 at 10:19:54AM -0400, Joel Fernandes wrote:
> > > On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> >
201 - 300 of 410 matches
Mail list logo
