v2.6.21-rt2

v2.6.21-rt2

[Ingo Molnar]

i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded 
from the usual place:

    http://redhat.com/~mingo/realtime-preempt/
 
more info about the -rt patchset can be found in the RT wiki:
 
    http://rt.wiki.kernel.org

This is a fixes-mostly release and has been assembled by Thomas 
Gleixner. Thanks Thomas! Here are the various changes:

  - ppc fixes from Tsutomu OWA

  - new sh -rt port from Paul Mundt & Co

  - fixes for various problems by Steven Rostedt and Clark Williams

  - x86/64 high-res timers and dynticks update (Thomas Gleixner)

  - various fixes from Sergie Shtylyov

  - latency fixes from John Stultz

  - misc fixes

to build a 2.6.21-rt2 tree, the following patches should be applied:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2
  http://redhat.com/~mingo/realtime-preempt/patch-2.6.21-rt2

	Ingo

Re: v2.6.21-rt2

[Daniel Walker]

On Wed, 2007-05-16 at 20:04 +0200, Ingo Molnar wrote:
> i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded 
> from the usual place:

2.6.21-rt2 ?

>     http://redhat.com/~mingo/realtime-preempt/
>                                    
> more info about the -rt patchset can be found in the RT wiki:
>  
>     http://rt.wiki.kernel.org
> 
> This is a fixes-mostly release and has been assembled by Thomas 
> Gleixner. Thanks Thomas! Here are the various changes:
> 
>   - ppc fixes from Tsutomu OWA
> 
>   - new sh -rt port from Paul Mundt & Co
> 
>   - fixes for various problems by Steven Rostedt and Clark Williams

I think you missed the fix I submitted for one of Steve's changes.

http://lkml.org/lkml/2007/5/3/368

Daniel

Re: v2.6.21-rt2

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> On Wed, 2007-05-16 at 20:04 +0200, Ingo Molnar wrote:
> > i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded 
> > from the usual place:
> 
> 2.6.21-rt2 ?

oops, right! :-)

> >   - fixes for various problems by Steven Rostedt and Clark Williams
> 
> I think you missed the fix I submitted for one of Steve's changes.
> 
> http://lkml.org/lkml/2007/5/3/368

hm - trace_hardirqs_on() should never be called with irqs on - lockdep 
could break for example. Could you try to fix the call site instead?

	Ingo

Re: v2.6.21-rt2

[Daniel Walker]

On Wed, 2007-05-16 at 23:01 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > On Wed, 2007-05-16 at 20:04 +0200, Ingo Molnar wrote:
> > > i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded 
> > > from the usual place:
> > 
> > 2.6.21-rt2 ?
> 
> oops, right! :-)
> 
> > >   - fixes for various problems by Steven Rostedt and Clark Williams
> > 
> > I think you missed the fix I submitted for one of Steve's changes.
> > 
> > http://lkml.org/lkml/2007/5/3/368
> 
> hm - trace_hardirqs_on() should never be called with irqs on - lockdep 
> could break for example. Could you try to fix the call site instead?

If that's the case why check if they're enabled inside
trace_hardirqs_on() ? If that check fails you still still get the
warning in my original release ..

Daniel

Re: v2.6.21-rt2

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> > > http://lkml.org/lkml/2007/5/3/368
> > 
> > hm - trace_hardirqs_on() should never be called with irqs on - 
> > lockdep could break for example. Could you try to fix the call site 
> > instead?
> 
> If that's the case why check if they're enabled inside 
> trace_hardirqs_on() ? If that check fails you still still get the 
> warning in my original release ..

yeah, indeed you are right - it checks the soft flag. But even then, the 
better fix is to check for hardirqs-off first and not to flip around the 
preempt count check in irqs_off_preempt_count() - i.e. something like 
the patch below. Does this solve the warning you've triggered with 
irqsoff-tracing enabled?

	Ingo

Index: linux-rt.q/kernel/latency_trace.c
===================================================================
--- linux-rt.q.orig/kernel/latency_trace.c
+++ linux-rt.q/kernel/latency_trace.c
@@ -1963,7 +1963,7 @@ void notrace trace_hardirqs_on(void)
 
 	local_save_flags(flags);
 
-	if (!irqs_off_preempt_count() && irqs_disabled_flags(flags))
+	if (irqs_disabled_flags(flags) && !irqs_off_preempt_count())
 		__stop_critical_timing(CALLER_ADDR0, 0 /* CALLER_ADDR1 */);
 }
 
@@ -1975,7 +1975,7 @@ void notrace trace_hardirqs_off(void)
 
 	local_save_flags(flags);
 
-	if (!irqs_off_preempt_count() && irqs_disabled_flags(flags))
+	if (irqs_disabled_flags(flags) && !irqs_off_preempt_count())
 		__start_critical_timing(CALLER_ADDR0, 0 /* CALLER_ADDR1 */,
 					INTERRUPT_LATENCY);
 }
@@ -1989,7 +1989,7 @@ void notrace trace_hardirqs_on_caller(un
 
 	local_save_flags(flags);
 
-	if (!irqs_off_preempt_count() && irqs_disabled_flags(flags))
+	if (irqs_disabled_flags(flags) && !irqs_off_preempt_count())
 		__stop_critical_timing(caller_addr, 0 /* CALLER_ADDR1 */);
 }
 
@@ -1999,7 +1999,7 @@ void notrace trace_hardirqs_off_caller(u
 
 	local_save_flags(flags);
 
-	if (!irqs_off_preempt_count() && irqs_disabled_flags(flags))
+	if (irqs_disabled_flags(flags) && !irqs_off_preempt_count())
 		__start_critical_timing(caller_addr, 0 /* CALLER_ADDR1 */,
 					INTERRUPT_LATENCY);
 }

Re: v2.6.21-rt2

[Daniel Walker]

On Wed, 2007-05-16 at 23:32 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > > > http://lkml.org/lkml/2007/5/3/368
> > > 
> > > hm - trace_hardirqs_on() should never be called with irqs on - 
> > > lockdep could break for example. Could you try to fix the call site 
> > > instead?
> > 
> > If that's the case why check if they're enabled inside 
> > trace_hardirqs_on() ? If that check fails you still still get the 
> > warning in my original release ..
> 
> yeah, indeed you are right - it checks the soft flag. But even then, the 
> better fix is to check for hardirqs-off first and not to flip around the 
> preempt count check in irqs_off_preempt_count() - i.e. something like 
> the patch below. Does this solve the warning you've triggered with 
> irqsoff-tracing enabled?

I don't know. irqs_off_preempt_count() could get used someplace else,
where you would want to flip the preempt_count() check .. It seems sane
to combine your patch with mine ..

irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count())

You can't call __get_cpu_var() without the a positive preempt_count(),
so the check seems backwards regardless of the other factors ..

Daniel

Re: v2.6.21-rt2

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> I don't know. irqs_off_preempt_count() could get used someplace else, 
> where you would want to flip the preempt_count() check .. It seems 
> sane to combine your patch with mine ..
> 
> irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && 
> preempt_count())
> 
> You can't call __get_cpu_var() without the a positive preempt_count(), 
> so the check seems backwards regardless of the other factors ..

yeah. The whole trace_preempt_enter_idle() thing looks a bit suspect. 
Why cannot those architectures simply disable/enable preemption and get 
the same effect? It's not like we ever want to allow the preemption of 
the idle task.

and once that is solved, irqs_off_preempt_count() can again include the 
hardirq and preempt count check only and doesnt have to check the 
idle_cpu flag. This would make the whole thing simpler and would avoid 
silly bugs like this.

	Ingo

Re: v2.6.21-rt2

[Daniel Walker]

On Thu, 2007-05-17 at 00:04 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > I don't know. irqs_off_preempt_count() could get used someplace else, 
> > where you would want to flip the preempt_count() check .. It seems 
> > sane to combine your patch with mine ..
> > 
> > irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && 
> > preempt_count())
> > 
> > You can't call __get_cpu_var() without the a positive preempt_count(), 
> > so the check seems backwards regardless of the other factors ..
> 
> yeah. The whole trace_preempt_enter_idle() thing looks a bit suspect. 
> Why cannot those architectures simply disable/enable preemption and get 
> the same effect? It's not like we ever want to allow the preemption of 
> the idle task.

They disable interrupts it looks like (i386, and x86_64), around the
same area where those trace_preempt_enter_idle calls are placed .. I'm
not up on the details of Steve's fix .. There's also a
preempt_disable/preempt_enable ..

I'm not up on the details of Steve's fix , but stuff looks a little
odd ..

Daniel

Re: v2.6.21-rt2

[Free Ekanayaka]

Hi,

|--==> Ingo Molnar writes:

  IM> i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded 
  IM> from the usual place:

  IM>     http://redhat.com/~mingo/realtime-preempt/

This new version of the patch solves the amd64/udev bug I reported
against previous releases:

http://www.mail-archive.com/linux-rt-users@vger.kernel.org/msg00353.html

I'm going to test the patch on other amd64 machines as well, thanks a
lot and keep up goo the work!

Ciao,

Free