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
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
* Daniel Walker <[email protected]> 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
On Wed, 2007-05-16 at 23:01 +0200, Ingo Molnar wrote:
> * Daniel Walker <[email protected]> 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
* Daniel Walker <[email protected]> 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);
}
On Wed, 2007-05-16 at 23:32 +0200, Ingo Molnar wrote:
> * Daniel Walker <[email protected]> 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
* Daniel Walker <[email protected]> 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
On Thu, 2007-05-17 at 00:04 +0200, Ingo Molnar wrote:
> * Daniel Walker <[email protected]> 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
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/[email protected]/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