Re: [ANNOUNCE] 2.6.33.5-rt23

From: Darcy L. Watkins
Date: Thu Jun 10 2010 - 12:19:59 EST




On Thu, 2010-06-10 at 08:56 -0700, Will Schmidt wrote:
> On Thu, 2010-06-10 at 08:07 +0200, Thomas Gleixner wrote:
> > On Wed, 9 Jun 2010, Will Schmidt wrote:
> >
> > > On Wed, 2010-06-09 at 18:44 +0200, Thomas Gleixner wrote:
> > > I'm still on 2.6.33.5-rt22 on powerpc, and have run into a couple
> > > "sleeping function called from invalid context..." BUGs. The
> first was
> > > during system boot, second during a 'make'.
> > >
> > > relevant code paths don't seem to have changed between -rt22 and
> -rt23,
> > > so I think still valid.. :-)
> > >
> > > This is on a POWER7 system, which may have opened up some timing
> > > windows, wrt previous runs on POWER6 systems.
> > >
> > >
> > > BUG: sleeping function called from invalid context at
> > > kernel/rtmutex.c:684
> >
> > > [c000000078cf2cf0] [c000000000131a04] .irq_to_desc_alloc_node
> +0xdc/0x2b8
> >
> > Grr. I thought I had the SPARSE_IRQ stuff disabled on -rt, but seems
> > it came back somehow. Can you disable that, or does you machine
> depend
> > on it ?
>
> I'm not sure whether it is required by the architecture. I do see
> that
> SPARSE_IRQ is disabled in arch/x86/Kconfig with a !PREEMPT_RT, but I
> don't see an equivalent 'disable' in arch/powerpc/Kconfig.
>

I see it as "y" in my .config for a powerpc 405 build. This appears to
run on my system (although I haven't loaded up the rt23 build on the
target yet - last one loaded up was rt22).

What should I expect to see different if SPARSE_IRQ is turned off?

>
> > > BUG: sleeping function called from invalid context at
> kernel/rtmutex.c:684
> > > pcnt: 0 0 in_atomic(): 0, irqs_disabled(): 1, pid: 4760, name:
> make
> > > Call Trace:
> > > [c0000000792978b0] [c000000000015550] .show_stack+0xd8/0x218
> (unreliable)
> > > [c000000079297990] [c0000000006a99c8] .dump_stack+0x28/0x3c
> > > [c000000079297a10] [c00000000006cea8] .__might_sleep+0x134/0x15c
> > > [c000000079297ab0] [c0000000006a2f78] .rt_spin_lock+0x4c/0x9c
> > > [c000000079297b40] [c0000000000a1ff0] .get_signal_to_deliver
> +0xcc/0x4ec
> > > [c000000079297c50] [c000000000018604] .do_signal_pending.clone.0
> +0x6c/0x2e0
> > > [c000000079297d90] [c0000000000188b0] .do_signal+0x38/0x74
> > > [c000000079297e30] [c000000000008b40] user_work+0x24/0x28
> >
> > Does the patch below fix it ?
>
> Probably.. :-) I'm running with the patch now, and no repeats of
> that
> BUG yet.
>
> Thanks,
> -Will
>
>
> >
> > Thanks,
> >
> > tglx
> > -----
> > diff --git a/arch/powerpc/kernel/signal.c
> b/arch/powerpc/kernel/signal.c
> > index 00b5078..fa580f9 100644
> > --- a/arch/powerpc/kernel/signal.c
> > +++ b/arch/powerpc/kernel/signal.c
> > @@ -120,6 +120,14 @@ static int do_signal_pending(sigset_t *oldset,
> struct pt_regs *regs)
> > int ret;
> > int is32 = is_32bit_task();
> >
> > +#ifdef CONFIG_PREEMPT_RT
> > + /*
> > + * Fully-preemptible kernel does not need interrupts disabled:
> > + */
> > + local_irq_enable();
> > + preempt_check_resched();
> > +#endif
> > +
> > if (current_thread_info()->local_flags & _TLF_RESTORE_SIGMASK)
> > oldset = &current->saved_sigmask;
> > else if (!oldset)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-rt-users" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/