Ingo Molnar wrote:
> John wrote:
>
>> John Stultz wrote:
>>
>>> Also do check the -rt tree as Ingo suggested. I mis-read your earlier
>>> email and thought you were running it.
>>
>> I've been pulling my hair over a related issue for the past two days.
>>
>> (I think I may be tickling a -hrt bug...)
>>
>> I'm working with 2.6.18.6 + patch-2.6.18-rt7
>
> 2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5 too?
Ingo, Thomas,
As far as I can tell, the -rt patch set is only updated for the latest
kernel version available. Is that correct?
http://people.redhat.com/mingo/realtime-preempt/older/?M=D
In other words, once 2.6.20 is released, and work starts on 2.6.21, if a
bug is discovered in -rt, the fix will not be back-ported to the
2.6.20.x (and 2.6.19.x, and 2.6.18.x, etc) patch set?
On Mon, 2007-02-05 at 17:37 +0100, John wrote:
> Ingo Molnar wrote:
>
> > John wrote:
> >
> >> John Stultz wrote:
> >>
> >>> Also do check the -rt tree as Ingo suggested. I mis-read your earlier
> >>> email and thought you were running it.
> >>
> >> I've been pulling my hair over a related issue for the past two days.
> >>
> >> (I think I may be tickling a -hrt bug...)
> >>
> >> I'm working with 2.6.18.6 + patch-2.6.18-rt7
> >
> > 2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5 too?
>
> Ingo, Thomas,
>
> As far as I can tell, the -rt patch set is only updated for the latest
> kernel version available. Is that correct?
>
> http://people.redhat.com/mingo/realtime-preempt/older/?M=D
>
> In other words, once 2.6.20 is released, and work starts on 2.6.21, if a
> bug is discovered in -rt, the fix will not be back-ported to the
> 2.6.20.x (and 2.6.19.x, and 2.6.18.x, etc) patch set?
Correct, there is only 1 live branch.
Peter Zijlstra wrote:
> John wrote:
>
>> Ingo Molnar wrote:
>>
>>> John wrote:
>>>
>>>> John Stultz wrote:
>>>>
>>>>> Also do check the -rt tree as Ingo suggested. I mis-read your earlier
>>>>> email and thought you were running it.
>>>>
>>>> I've been pulling my hair over a related issue for the past two days.
>>>>
>>>> (I think I may be tickling a -hrt bug...)
>>>>
>>>> I'm working with 2.6.18.6 + patch-2.6.18-rt7
>>>
>>> 2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5 too?
>>
>> Ingo, Thomas,
>>
>> As far as I can tell, the -rt patch set is only updated for the latest
>> kernel version available. Is that correct?
>>
>> http://people.redhat.com/mingo/realtime-preempt/older/?M=D
>>
>> In other words, once 2.6.20 is released, and work starts on 2.6.21, if a
>> bug is discovered in -rt, the fix will not be back-ported to the
>> 2.6.20.x (and 2.6.19.x, and 2.6.18.x, etc) patch set?
>
> Correct, there is only 1 live branch.
Are there people that use the -rt patch set in real industrial applications?
It seems that, if an important bug is found in the -rt part, I will have
to either upgrade to the latest kernel, or back port all the -rt changes
to the kernel I chose for my application?
Regards,
John
On Wed, 2007-02-07 at 11:25 +0100, John wrote:
> Are there people that use the -rt patch set in real industrial applications?
Yes. But we use a stabilized version of 2.6.16-rt29.
http://www.osadl.org/projects/downloads/preempt-rt/linux-2.6.16/
> It seems that, if an important bug is found in the -rt part, I will have
> to either upgrade to the latest kernel, or back port all the -rt changes
> to the kernel I chose for my application?
Yep.
tglx
Thomas Gleixner wrote:
> On Wed, 2007-02-07 at 11:25 +0100, John wrote:
>
>> Are there people that use the -rt patch set in real industrial applications?
>
> Yes. But we use a stabilized version of 2.6.16-rt29.
> http://www.osadl.org/projects/downloads/preempt-rt/linux-2.6.16/
Thanks for the pointer.
I'm confused: patch-2.6.16-rt29-tglx3 is dated 2006-09-07, yet there
have been numerous revisions of the -rt patch set since then. Does that
mean that no serious bugs have been found since September? Do the -rt
patch sets for 2.6.17 - 2.6.20 only bring new features and/or adapt the
-rt infrastructure to the newer kernels?
>> It seems that, if an important bug is found in the -rt part, I will have
>> to either upgrade to the latest kernel, or back port all the -rt changes
>> to the kernel I chose for my application?
>
> Yep.
Ouch :-)
I think I'll try my luck with 2.6.20 (it's been working so far).
By the way, I have a question: when I compile glibc for this system,
should I compile it against the vanilla 2.6.20 includes, or against the
patched 2.6.20-rt includes?
Regards.
On Fri, 09 Feb 2007 16:25:11 +0100
John <[email protected]> wrote:
> By the way, I have a question: when I compile glibc for this system,
> should I compile it against the vanilla 2.6.20 includes, or against
> the patched 2.6.20-rt includes?
That shouldn't make a difference. All of the
kernel/glibc-interface related parts are in vanilla now.
Bene
John,
On Fri, 2007-02-09 at 16:25 +0100, John wrote:
> I'm confused: patch-2.6.16-rt29-tglx3 is dated 2006-09-07, yet there
> have been numerous revisions of the -rt patch set since then. Does that
> mean that no serious bugs have been found since September? Do the -rt
> patch sets for 2.6.17 - 2.6.20 only bring new features and/or adapt the
> -rt infrastructure to the newer kernels?
There were many bugs found, but mostly related to the newer versions of
the code or features, which have been added after 2.6.16-rt29. My -tglx
series has the back ports of fixes which were applicable to 2-6-16-rt29.
tglx