Hi David, Sorry , I didn't check that . I am late in submitting it .
Regards, Shaiju. -----Original Message----- From: David Daney [mailto:[email protected]] Sent: Monday, August 11, 2014 3:28 PM To: Sadasivan Shaiju Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [PATCH] delaying interrupts in mips [ 2.6.32] On 08/11/2014 03:13 PM, Sadasivan Shaiju wrote: > Hi , > > I work for Montavista (Cavium Inc) as a Technical Lead . I want > to push some of the kernel patches to rt community (2.6.32 kernel > 2.6.33 rt patch) , so that It will go to the main line These > patches are reviewed and approved by our system Architect. I > request you to include in the main line . It is already in the "main line": commit 1bcfecc028686ea32e49b0f4f6e8a665917cb49a Author: Yong Zhang <[email protected]> Date: Thu Jul 19 09:13:53 2012 +0200 MIPS: Octeon: delay enable irq to ->smp_finish() To prepare for smoothing set_cpu_[active|online]() mess up Signed-off-by: Yong Zhang <[email protected]> Cc: Sergei Shtylyov <[email protected]> Cc: David Daney <[email protected]> Acked-by: David Daney <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/3845/ Signed-off-by: Ralf Baechle <[email protected]> Why are you sending it again? David Daney These issues were reported by our > customer CISCO . > > Problem Description: > When CONFIG_DEBUG_PREEMPT is enabled the following stack trace occurs. > > [ 170.814470] BUG: using smp_processor_id() in preemptible [00000000] > code: sirq-timer/4/62 > [ 170.814482] caller is hrtimer_run_pending+0x10/0x20 [ 170.814488] > Call Trace: > [ 170.814496] [<ffffffff8010d844>] dump_stack+0x8/0x34 [ 170.814507] > [<ffffffff803c2598>] debug_smp_processor_id+0xe0/0xf0 [ 170.814517] > [<ffffffff80254158>] hrtimer_run_pending+0x10/0x20 [ 170.814528] > [<ffffffff80242400>] run_timer_softirq+0x60/0x348 [ 170.814539] > [<ffffffff8023ae80>] run_ksoftirqd+0x1c8/0x348 [ 170.814550] > [<ffffffff802503f8>] kthread+0x88/0x90 [ 170.814561] > [<ffffffff80206c80>] kernel_thread_helper+0x10/0x18 > > Root Cause: > Interrupt was occurring before the processor was completely up, and > the softirq threads were unable to schedule on the processor and then > ran on the wrong CPU. > > How Solved: > Enabling of interrupt has been delayed till smp_finish so that > kthread_bind can safely bind threads to any possible CPU. > > I request you to merge the above patch to the main line . If any > questions please contact me [email protected] > ([email protected]) > > Regards, > Shaiju. > > > 0001-Interrupt-delaying-enabling-of-interrupt.patch > > > From 58512475cba93003c23f2b380b573e64eebcabd5 Mon Sep 17 00:00:00 > 2001 > From: Sadasivan Shaiju<[email protected]> > Date: Mon, 20 Feb 2012 13:25:50 -0800 > Subject: [PATCH] Interrupt : delaying enabling of interrupt > > Source: MontaVista Software, LLC > MR: 47157 > Type: Defect Fix > Disposition: Local > ChangeID: 48c837329556b161f3111e6fded1c9857fa3a149 > Description: > > This patch is to delay the enabling of interrupt till smp_finish . So > that kthread_bind can safely bind threads to any possible cpu. Without > this change interrupt should occur beofre the processor was > completely up, and the softirq threads were unable to schedule on the > processor and then ran on the wrong CPU. > > Signed-off-by: Sadasivan Shaiju<[email protected]> > --- > arch/mips/cavium-octeon/smp.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/mips/cavium-octeon/smp.c > b/arch/mips/cavium-octeon/smp.c index ff21542..c7de7ac 100644 > --- a/arch/mips/cavium-octeon/smp.c > +++ b/arch/mips/cavium-octeon/smp.c > @@ -308,7 +308,6 @@ static void octeon_init_secondary(void) > octeon_init_cvmcount(); > > octeon_irq_setup_secondary(); > - raw_local_irq_enable(); > } > > /** > @@ -365,6 +364,8 @@ static void octeon_smp_finish(void) > > /* to generate the first CPU timer interrupt */ > write_c0_compare(read_c0_count() + mips_hpt_frequency / HZ); > + /* enable local interrupts */ > + raw_local_irq_enable(); > } > > /** > -- 1.7.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
