headers
Steven Rostedt | 1 Dec 2011 02:25
Gravatar

[ANNOUNCE] 3.0.12-rt29


Dear RT Folks,

I'm pleased to announce the 3.0.12-rt29 stable release.

This release is just an update to the new stable 3.0.12 version
and no RT specific changes have been made.

Note, I did make and upload 3.0.11-rt28 that only merged in 3.0.11, but
then saw that 3.0.12 was released, so I went back and merged in 3.0.12
and started the testing scripts again.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  Head SHA1: 69a3235fcfb900e8c40a2044757903de7c15b1ef

Or to build 3.0.12-rt29 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.12.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.12-rt29.patch.xz

The broken out patches are available at:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patches-3.0.12-rt29.tar.xz
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Rostedt | 1 Dec 2011 02:39
Gravatar

Re: [ANNOUNCE] 3.0.12-rt29

I for got to sign this email, so I'm replying to it with a signed reply.

-- Steve

On Wed, 2011-11-30 at 20:25 -0500, Steven Rostedt wrote:
> Dear RT Folks,
> 
> I'm pleased to announce the 3.0.12-rt29 stable release.
> 
> 
> This release is just an update to the new stable 3.0.12 version
> and no RT specific changes have been made.
> 
> Note, I did make and upload 3.0.11-rt28 that only merged in 3.0.11, but
> then saw that 3.0.12 was released, so I went back and merged in 3.0.12
> and started the testing scripts again.
> 
> 
> You can get this release via the git tree at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
> 
>   Head SHA1: 69a3235fcfb900e8c40a2044757903de7c15b1ef
> 
> 
> Or to build 3.0.12-rt29 directly, the following patches should be applied:
> 
>   http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
> 
>   http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.12.xz
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Galbraith | 1 Dec 2011 10:12
Picon
Picon

PATCH RT] resurrect softirq threads for RT_FULL

Un-hijack thread.

On Wed, 2011-11-30 at 11:24 +0100, Thomas Gleixner wrote:
> On Wed, 30 Nov 2011, Mike Galbraith wrote:

> >  <at>  <at>  -486,12 +495,43  <at>  <at>  extern void softirq_check_pending_idle(v
> >   */
> >  DECLARE_PER_CPU(struct list_head [NR_SOFTIRQS], softirq_work_list);
> >  
> > -DECLARE_PER_CPU(struct task_struct *, ksoftirqd);
> > +struct softirqdata {
> > +	int			mask;
> > +	struct task_struct	*tsk;
> > +};
> > +
> > +DECLARE_PER_CPU(struct softirqdata [NR_SOFTIRQ_THREADS], ksoftirqd);
> > +
> > +static inline bool this_cpu_ksoftirqd(struct task_struct *p)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < NR_SOFTIRQ_THREADS; i++) {
> > +		if (p == __get_cpu_var(ksoftirqd)[i].tsk)
> > +			return true;
> 
> You are not serious about that loop, are you ?

After some dainbramaged removal, it might look a little better.

sched, rt: resurrect softirq threads for RT_FULL
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Kacur | 2 Dec 2011 14:39
Picon
Favicon

[PATCH-RT] Fix for sleeping function called from invalid context when running gdb

While running gdb on cyclictest on v3.2-rc2-rt3 I got the following error

[root <at> starship ~]# [11887.443716] BUG: sleeping function called from invalid con
text at /home/jkacur/linux-rt/kernel/rtmutex.c:645
[11887.443720] in_atomic(): 1, irqs_disabled(): 0, pid: 4859, name: cyclictest
[11887.443723] no locks held by cyclictest/4859.
[11887.443726] Pid: 4859, comm: cyclictest Not tainted 3.2.0-rc2-rt3-debug-expr+
 #1
[11887.443728] Call Trace:
[11887.443737]  [<ffffffff81035543>] __might_sleep+0x185/0x18d
[11887.443743]  [<ffffffff8107c3ed>] rt_spin_lock_fastlock.clone.0+0x24/0x31
[11887.443749]  [<ffffffff813fba9b>] rt_spin_lock+0x16/0x40
[11887.443754]  [<ffffffff81053eee>] force_sig_info+0x3d/0xeb
[11887.443758]  [<ffffffff81053fb2>] force_sig+0x16/0x18
[11887.443761]  [<ffffffff813fd0a1>] do_trap+0xef/0x130
[11887.443766]  [<ffffffff81076525>] ? trace_hardirqs_on_caller+0x12a/0x161
[11887.443771]  [<ffffffff813fd16f>] do_int3+0x8d/0x9a
[11887.443774]  [<ffffffff813fc9e7>] int3+0x27/0x40

I found that there is a patch for this in v2.6.33.9-rt31 that I forward-ported
to v3.2-rc2-rt3

I believe that Thomas Gleixner is the original author, but I'm not sure.
Thomas - can you provide your signed-off-by if you are the author?

Forward-ported from v2.6.33.9-rt31 to v3.2-rc2-rt3
Signed-off-by: John Kacur <jkacur <at> redhat.com>
---
 arch/x86/kernel/traps.c |   24 +++++++++++++-----------
 1 files changed, 13 insertions(+), 11 deletions(-)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thomas Schauss | 2 Dec 2011 18:41
Picon
Favicon

Re: 3.2-rc1 and nvidia drivers

On 11/30/2011 04:20 PM, Steven Rostedt wrote:
> On Wed, 2011-11-30 at 16:07 +0100, Thomas Schauss wrote:
>
>> On 3.0.9-rt25 (which I have been using here) patch 30765b92 is already
>> applied. And it is also present in patch-3.0.10-rt27.patch.
>
> I'm such a fscking idiot!
>
> I've been working on a port of a patch in 2.6.33-rt, and I didn't
> realize that I was still in that kernel, applying these patches. As I
> said, I thought the one Peter had was already applied. It was, I'm the
> idiot that didn't realize I was in the wrong kernel!
>
>>
>> So the original patch from Peter
>> (http://article.gmane.org/gmane.linux.kernel.mm/70863/match=) applies
>> cleanly here.
>
> Yeah, thanks. That's the patch you want.
>
> -- Steve
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Rostedt | 2 Dec 2011 20:37
Gravatar

Re: 3.2-rc1 and nvidia drivers

On Fri, 2011-12-02 at 18:41 +0100, Thomas Schauss wrote:

> this patch does indeed get rid of the lockdep-splat.
> 
> Regarding the original subject of the post:
> 
> Running startx with the nvidia binary driver fails on 3.0.9-rt25 and 
> 3.2-rc2-rt3 when CONFIG_PREEMPT_RT_FULL=y and works fine for 
> CONFIG_PREEMPT_RTB=y. There is no lockdep-warning, kernel oops/bug, 
> etc., neither in any log-files nor on the serial console.
> 
> This happens on several machines which ran fine with 2.6.33-rt29.
> 
> I know many people here are no big fans of the nvidia driver (and 
> rightly so). Unfortunately we really need this.

The biggest problem with nvidia is that it's a black box for us. We have
no idea what's happening behind the scenes. Once the nvidia drive takes
over, we're in the dark and can't do much about it. If you depend on
nvidia so much, perhaps you could contact them. Their engineers may be
able to help you here.

> 
> If anyone has any further ideas on debugging this issue I would be 
> really thankful.

Perhaps kick off nmi_watchdog and hope that it produces something?

-- Steve
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Rostedt | 2 Dec 2011 20:41
Gravatar

Re: [PATCH-RT] Fix for sleeping function called from invalid context when running gdb

On Fri, 2011-12-02 at 19:20 +0100, Andi Kleen wrote:
> > > -static inline void preempt_conditional_sti(struct pt_regs *regs)
> > > +static inline void preempt_conditional_sti(struct pt_regs *regs, int stack)
> > >  {
> > > -	inc_preempt_count();
> > > +	if (stack)
> > > +		inc_preempt_count();
> 
> All callers now pass in true I think, so you could eliminate the stack argument.

Not in RT:

#ifdef CONFIG_PREEMPT_RT_FULL
# define STACKFAULT_STACK 0
# define DOUBLEFAULT_STACK 1
# define NMI_STACK 2
# define DEBUG_STACK 0
# define MCE_STACK 3
# define N_EXCEPTION_STACKS 3  /* hw limit: 7 */
#else
# define STACKFAULT_STACK 1
# define DOUBLEFAULT_STACK 2
# define NMI_STACK 3
# define DEBUG_STACK 4
# define MCE_STACK 5
# define N_EXCEPTION_STACKS 5  /* hw limit: 7 */
#endif

-- Steve
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Gleixner | 2 Dec 2011 23:09
Picon

[ANNOUNCE] 3.2-rc4-rt5

Dear RT Folks,

I'm pleased to announce the 3.2-rc4-rt6 release. 3.2-rc4-rt4 is a not
announced intermediate release, which only updates to 3.2-rc4. No rt
changes except dropping patches which made it into 3.2-rc4.

NOTE: Releases are back to www.kernel.org - the intermediate tglx.de
      release URL is history!

Changes vs. 3.2-rc4-rt4:

  * tasklet fix - port from 2.6.33-rt (Steven)
    	[tasklet-rt-prevent-tasklets-from-going-into-infinite-spin-in-rt.patch] -> stable

  * acpi raw spinlock annotations
    	[acpi-make-gbl-hardware-lock-raw.patch] -> stable

  * pci preemption fix
    	[wait-provide-__wake_up_all_locked.patch] -> stable
	[pci-access-use-__wake_up_all_locked.patch] -> stable

  * a few important fixes which are pending for mainline and should be
    gone with rc5
    	[re-possible-slab-deadlock-while-doing-ifenslave.patch] -> stable
	[re-possible-slab-deadlock-while-doing-ifenslave-1.patch] -> stable

	Yes, I should have renamed them, but now it's too late :)

The incremental patch against 3.2-rc4-rt5 can be found here:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Rowand | 3 Dec 2011 00:08
Picon

[RT] sysrq Z: sleeping function called from invalid context

Hi Steve,

I get a "sleeping function called from invalid context" when I invoke sysrq Z.

I get this both with CONFIG_MAGIC_SYSRQ_FORCE_PRINTK enabled and disabled.

3.0.12-rt29
ARM Pandaboard

I have not tried this on 3.2-rc4-rt5.

[  900.963226] SysRq : Dump ftrace buffer
[  900.967163] Dumping ftrace buffer:
[  900.970733] BUG: sleeping function called from invalid context at kernel/rtmutex.c:645
[  900.985137] in_atomic(): 0, irqs_disabled(): 128, pid: 563, name: irq/106-OMAP UA
[  900.992980] 2 locks held by irq/106-OMAP UA/563:
[  900.997833]  #0:  (&port_lock_key){+.+...}, at: [<c02d8b14>] serial_omap_irq+0x4c/0x7dc
[  901.006286]  #1:  (sysrq_key_table_lock){+.+...}, at: [<c02c13a0>] __handle_sysrq+0x20/0x18c
[  901.015167] irq event stamp: 45345
[  901.018737] hardirqs last  enabled at (45344): [<c0482f68>] _raw_spin_unlock_irq+0x24/0x4c
[  901.027435] hardirqs last disabled at (45345): [<c00fb854>] ftrace_dump+0x14/0x23c
[  901.035400] softirqs last  enabled at (0): [<c009dca8>] copy_process+0x364/0xf84
[  901.043182] softirqs last disabled at (0): [<  (null)>]   (null)
[  901.049499] [<c00681b8>] (unwind_backtrace+0x0/0xf0) from [<c04824d0>] (rt_spin_lock+0x24/0x5c)
[  901.058654] [<c04824d0>] (rt_spin_lock+0x24/0x5c) from [<c00f3b34>] (read_buffer_lock+0x4c/0x6c)
[  901.067871] [<c00f3b34>] (read_buffer_lock+0x4c/0x6c) from [<c00f5908>] (ring_buffer_empty_cpu+0x50/0x7c)
[  901.077911] [<c00f5908>] (ring_buffer_empty_cpu+0x50/0x7c) from [<c00fa3cc>] (trace_empty+0x58/0xd8)
[  901.087524] [<c00fa3cc>] (trace_empty+0x58/0xd8) from [<c00fb9f8>] (ftrace_dump+0x1b8/0x23c)
[  901.096374] [<c00fb9f8>] (ftrace_dump+0x1b8/0x23c) from [<c02c1428>] (__handle_sysrq+0xa8/0x18c)
[  901.105621] [<c02c1428>] (__handle_sysrq+0xa8/0x18c) from [<c02d90cc>] (serial_omap_irq+0x604/0x7dc)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steven Rostedt | 3 Dec 2011 00:49
Gravatar

Re: [RT] sysrq Z: sleeping function called from invalid context

On Fri, 2011-12-02 at 15:08 -0800, Frank Rowand wrote:
> Hi Steve,
> 
> I get a "sleeping function called from invalid context" when I invoke sysrq Z.
> 
> I get this both with CONFIG_MAGIC_SYSRQ_FORCE_PRINTK enabled and disabled.

Patient:  Hey doctor, it hurts when I do this

Doctor:  Don't do that.

> 
> 3.0.12-rt29
> ARM Pandaboard
> 
> I have not tried this on 3.2-rc4-rt5.
> 
> [  900.963226] SysRq : Dump ftrace buffer
> [  900.967163] Dumping ftrace buffer:
> [  900.970733] BUG: sleeping function called from invalid context at kernel/rtmutex.c:645
> [  900.985137] in_atomic(): 0, irqs_disabled(): 128, pid: 563, name: irq/106-OMAP UA
> [  900.992980] 2 locks held by irq/106-OMAP UA/563:
> [  900.997833]  #0:  (&port_lock_key){+.+...}, at: [<c02d8b14>] serial_omap_irq+0x4c/0x7dc
> [  901.006286]  #1:  (sysrq_key_table_lock){+.+...}, at: [<c02c13a0>] __handle_sysrq+0x20/0x18c
> [  901.015167] irq event stamp: 45345
> [  901.018737] hardirqs last  enabled at (45344): [<c0482f68>] _raw_spin_unlock_irq+0x24/0x4c
> [  901.027435] hardirqs last disabled at (45345): [<c00fb854>] ftrace_dump+0x14/0x23c
> [  901.035400] softirqs last  enabled at (0): [<c009dca8>] copy_process+0x364/0xf84
> [  901.043182] softirqs last disabled at (0): [<  (null)>]   (null)
> [  901.049499] [<c00681b8>] (unwind_backtrace+0x0/0xf0) from [<c04824d0>] (rt_spin_lock+0x24/0x5c)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane