[Xenomai-core] (Not yet) Xenomai 2.5.5.

[Xenomai-core] (Not yet) Xenomai 2.5.5.

[Gilles Chanteperdrix]

Hi,

I would like to make that next release of Xenomai, especially since the
fix for the I-pipe on x86_32 with grub2 has been available for some time
now, and has not yet been in a stable release.

So, I have a few minor questions:
- Wolfgang, Alexis, it seems we have a few warnings when compiling
rtcan/analogy tools with recent versions of gcc (4.4.1 from
codesourcery). You will find the logs here:
http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
we are not in a hurry to fix this, so simply tell me if the fix is easy
or not.
- Alexis, from the mailing list discussions, you probably have some
commits ready in the analoty branch, would it be possible to have a pull
request for these?
- Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
changed following the discussions with Philippe?

Thanks in advance.

-- 
					    Gilles.

Re: [Xenomai-core] (Not yet) Xenomai 2.5.5.

[Jan Kiszka]

Am 16.09.2010 10:17, Gilles Chanteperdrix wrote:
> 
> Hi,
> 
> I would like to make that next release of Xenomai, especially since the
> fix for the I-pipe on x86_32 with grub2 has been available for some time
> now, and has not yet been in a stable release.
> 
> So, I have a few minor questions:
> - Wolfgang, Alexis, it seems we have a few warnings when compiling
> rtcan/analogy tools with recent versions of gcc (4.4.1 from
> codesourcery). You will find the logs here:
> http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
> we are not in a hurry to fix this, so simply tell me if the fix is easy
> or not.
> - Alexis, from the mailing list discussions, you probably have some
> commits ready in the analoty branch, would it be possible to have a pull
> request for these?
> - Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
> Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
> changed following the discussions with Philippe?

I've a ready-to-use version that should address all of Philippe's
remarks in my 2.6.35 queue [1]. The plan was to push it along this line,
but then things got stuck due to the 32-bit boot hang report by Ed
Hoffman (still waiting for further information from him). Also my KVM
patches in that queue do not work yet, but they will likely be postponed.

Besides that, I've longer queue of fixes and enhancement to Xenomai [2]
that partially depends on [1]. I already sent pull requests, but then
did not refresh it due to the dependency.

Unfortunately, I'm "a bit" short on time the next weeks, so we need to
find the cheapest way of getting the most important stuff merged for
2.5.5 I guess. I already started backporting the critical sync fixes for
I-pipe to 2.6.34 [3], just sent no pull request yet.

Jan

[1]
http://git.kiszka.org/?p=ipipe-2.6.git;a=shortlog;h=refs/heads/queues/2.6.35-x86
[2]
http://git.xenomai.org/?p=xenomai-jki.git;a=shortlog;h=refs/heads/for-upstream
[3]
http://git.kiszka.org/?p=ipipe-2.6.git;a=shortlog;h=refs/heads/queues/2.6.34-x86

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] (Not yet) Xenomai 2.5.5.

[Edward Hoffman]

Jan,

Sorry, I got distracted with the rtnet testing and development I'll be
back on the 32-bit version early next week.

Ed

On Thu, 2010-09-16 at 11:16 +0200, Jan Kiszka wrote:
> Am 16.09.2010 10:17, Gilles Chanteperdrix wrote:
> > 
> > Hi,
> > 
> > I would like to make that next release of Xenomai, especially since the
> > fix for the I-pipe on x86_32 with grub2 has been available for some time
> > now, and has not yet been in a stable release.
> > 
> > So, I have a few minor questions:
> > - Wolfgang, Alexis, it seems we have a few warnings when compiling
> > rtcan/analogy tools with recent versions of gcc (4.4.1 from
> > codesourcery). You will find the logs here:
> > http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
> > we are not in a hurry to fix this, so simply tell me if the fix is easy
> > or not.
> > - Alexis, from the mailing list discussions, you probably have some
> > commits ready in the analoty branch, would it be possible to have a pull
> > request for these?
> > - Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
> > Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
> > changed following the discussions with Philippe?
> 
> I've a ready-to-use version that should address all of Philippe's
> remarks in my 2.6.35 queue [1]. The plan was to push it along this line,
> but then things got stuck due to the 32-bit boot hang report by Ed
> Hoffman (still waiting for further information from him). Also my KVM
> patches in that queue do not work yet, but they will likely be postponed.
> 
> Besides that, I've longer queue of fixes and enhancement to Xenomai [2]
> that partially depends on [1]. I already sent pull requests, but then
> did not refresh it due to the dependency.
> 
> Unfortunately, I'm "a bit" short on time the next weeks, so we need to
> find the cheapest way of getting the most important stuff merged for
> 2.5.5 I guess. I already started backporting the critical sync fixes for
> I-pipe to 2.6.34 [3], just sent no pull request yet.
> 
> Jan
> 
> [1]
> http://git.kiszka.org/?p=ipipe-2.6.git;a=shortlog;h=refs/heads/queues/2.6.35-x86
> [2]
> http://git.xenomai.org/?p=xenomai-jki.git;a=shortlog;h=refs/heads/for-upstream
> [3]
> http://git.kiszka.org/?p=ipipe-2.6.git;a=shortlog;h=refs/heads/queues/2.6.34-x86
> 

Re: [Xenomai-core] (Not yet) Xenomai 2.5.5.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Am 16.09.2010 10:17, Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I would like to make that next release of Xenomai, especially since the
>> fix for the I-pipe on x86_32 with grub2 has been available for some time
>> now, and has not yet been in a stable release.
>>
>> So, I have a few minor questions:
>> - Wolfgang, Alexis, it seems we have a few warnings when compiling
>> rtcan/analogy tools with recent versions of gcc (4.4.1 from
>> codesourcery). You will find the logs here:
>> http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
>> we are not in a hurry to fix this, so simply tell me if the fix is easy
>> or not.
>> - Alexis, from the mailing list discussions, you probably have some
>> commits ready in the analoty branch, would it be possible to have a pull
>> request for these?
>> - Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
>> Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
>> changed following the discussions with Philippe?
> 
> I've a ready-to-use version that should address all of Philippe's
> remarks in my 2.6.35 queue [1]. The plan was to push it along this line,
> but then things got stuck due to the 32-bit boot hang report by Ed
> Hoffman (still waiting for further information from him). Also my KVM
> patches in that queue do not work yet, but they will likely be postponed.
> 
> Besides that, I've longer queue of fixes and enhancement to Xenomai [2]
> that partially depends on [1]. I already sent pull requests, but then
> did not refresh it due to the dependency.
> 
> Unfortunately, I'm "a bit" short on time the next weeks, so we need to
> find the cheapest way of getting the most important stuff merged for
> 2.5.5 I guess. I already started backporting the critical sync fixes for
> I-pipe to 2.6.34 [3], just sent no pull request yet.

Ok. I would like to be able to merge at least before the middle of next
week so as to validate a bit the result before releasing, hopefully,
before the end of next week.

I had a look at the patches you pushed. I find it a bit dangerous to
merge quickly such patches, which fiddle with the nklock, without
extensive testing. The risk is that on SMP machines, the cpus start
dumping stack traces concurrently, resulting in an unreadable mess (we
have seen this in the past actually), whereas, correct me if I am wrong,
if the output takes place on the serial port, which is the current
preferred debug setup with Xenomai, we do not have to schedule klogd to
get an output, so we do not have to release the nklock.

I also do not understand the game with panic. It looks to me there is a
risk of breaking compatibility with older Adeos patches, whose panic was
not as solid as the one of the current releases.

-- 
                                                                Gilles.

Re: [Xenomai-core] (Not yet) Xenomai 2.5.5.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3664 bytes --]

Am 16.09.2010 20:51, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Am 16.09.2010 10:17, Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> I would like to make that next release of Xenomai, especially since the
>>> fix for the I-pipe on x86_32 with grub2 has been available for some time
>>> now, and has not yet been in a stable release.
>>>
>>> So, I have a few minor questions:
>>> - Wolfgang, Alexis, it seems we have a few warnings when compiling
>>> rtcan/analogy tools with recent versions of gcc (4.4.1 from
>>> codesourcery). You will find the logs here:
>>> http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
>>> we are not in a hurry to fix this, so simply tell me if the fix is easy
>>> or not.
>>> - Alexis, from the mailing list discussions, you probably have some
>>> commits ready in the analoty branch, would it be possible to have a pull
>>> request for these?
>>> - Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
>>> Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
>>> changed following the discussions with Philippe?
>>
>> I've a ready-to-use version that should address all of Philippe's
>> remarks in my 2.6.35 queue [1]. The plan was to push it along this line,
>> but then things got stuck due to the 32-bit boot hang report by Ed
>> Hoffman (still waiting for further information from him). Also my KVM
>> patches in that queue do not work yet, but they will likely be postponed.
>>
>> Besides that, I've longer queue of fixes and enhancement to Xenomai [2]
>> that partially depends on [1]. I already sent pull requests, but then
>> did not refresh it due to the dependency.
>>
>> Unfortunately, I'm "a bit" short on time the next weeks, so we need to
>> find the cheapest way of getting the most important stuff merged for
>> 2.5.5 I guess. I already started backporting the critical sync fixes for
>> I-pipe to 2.6.34 [3], just sent no pull request yet.
> 
> Ok. I would like to be able to merge at least before the middle of next
> week so as to validate a bit the result before releasing, hopefully,
> before the end of next week.
> 
> I had a look at the patches you pushed. I find it a bit dangerous to
> merge quickly such patches, which fiddle with the nklock, without
> extensive testing.

This is first of all xenomai-head stuff, nothing that shall be
unconditionally backported. But even for head, we can perfectly skip the
debugging part. Important are the fixes. I've reordered and shortened my
queue already.

> The risk is that on SMP machines, the cpus start
> dumping stack traces concurrently, resulting in an unreadable mess (we
> have seen this in the past actually), whereas, correct me if I am wrong,
> if the output takes place on the serial port, which is the current
> preferred debug setup with Xenomai, we do not have to schedule klogd to
> get an output, so we do not have to release the nklock.

I will have to check this again, but I bet the need for dropping nklock
came from the fact that more than the serial port was configured (that's
default here). Then some other console driver may have locked things up
while walking the write handlers. Moreover, I would like to get more
data in case the user did not yet prepare for catching a Xenomai panic.
But, of course, dump regressions must be avoided.

> 
> I also do not understand the game with panic. It looks to me there is a
> risk of breaking compatibility with older Adeos patches, whose panic was
> not as solid as the one of the current releases.

Do you have some versions in mind? Something in the early 2.6.20th or
younger?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-core] (Not yet) Xenomai 2.5.5.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Am 16.09.2010 20:51, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Am 16.09.2010 10:17, Gilles Chanteperdrix wrote:
>>>> Hi,
>>>>
>>>> I would like to make that next release of Xenomai, especially since the
>>>> fix for the I-pipe on x86_32 with grub2 has been available for some time
>>>> now, and has not yet been in a stable release.
>>>>
>>>> So, I have a few minor questions:
>>>> - Wolfgang, Alexis, it seems we have a few warnings when compiling
>>>> rtcan/analogy tools with recent versions of gcc (4.4.1 from
>>>> codesourcery). You will find the logs here:
>>>> http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
>>>> we are not in a hurry to fix this, so simply tell me if the fix is easy
>>>> or not.
>>>> - Alexis, from the mailing list discussions, you probably have some
>>>> commits ready in the analoty branch, would it be possible to have a pull
>>>> request for these?
>>>> - Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
>>>> Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
>>>> changed following the discussions with Philippe?
>>> I've a ready-to-use version that should address all of Philippe's
>>> remarks in my 2.6.35 queue [1]. The plan was to push it along this line,
>>> but then things got stuck due to the 32-bit boot hang report by Ed
>>> Hoffman (still waiting for further information from him). Also my KVM
>>> patches in that queue do not work yet, but they will likely be postponed.
>>>
>>> Besides that, I've longer queue of fixes and enhancement to Xenomai [2]
>>> that partially depends on [1]. I already sent pull requests, but then
>>> did not refresh it due to the dependency.
>>>
>>> Unfortunately, I'm "a bit" short on time the next weeks, so we need to
>>> find the cheapest way of getting the most important stuff merged for
>>> 2.5.5 I guess. I already started backporting the critical sync fixes for
>>> I-pipe to 2.6.34 [3], just sent no pull request yet.
>> Ok. I would like to be able to merge at least before the middle of next
>> week so as to validate a bit the result before releasing, hopefully,
>> before the end of next week.
>>
>> I had a look at the patches you pushed. I find it a bit dangerous to
>> merge quickly such patches, which fiddle with the nklock, without
>> extensive testing.
> 
> This is first of all xenomai-head stuff, nothing that shall be
> unconditionally backported. But even for head, we can perfectly skip the
> debugging part. Important are the fixes. I've reordered and shortened my
> queue already.

Ah, ok, it was hard to tell since it came in the for-upstream branch...

> 
>> The risk is that on SMP machines, the cpus start
>> dumping stack traces concurrently, resulting in an unreadable mess (we
>> have seen this in the past actually), whereas, correct me if I am wrong,
>> if the output takes place on the serial port, which is the current
>> preferred debug setup with Xenomai, we do not have to schedule klogd to
>> get an output, so we do not have to release the nklock.
> 
> I will have to check this again, but I bet the need for dropping nklock
> came from the fact that more than the serial port was configured (that's
> default here). Then some other console driver may have locked things up
> while walking the write handlers. Moreover, I would like to get more
> data in case the user did not yet prepare for catching a Xenomai panic.
> But, of course, dump regressions must be avoided.
> 
>> I also do not understand the game with panic. It looks to me there is a
>> risk of breaking compatibility with older Adeos patches, whose panic was
>> not as solid as the one of the current releases.
> 
> Do you have some versions in mind? Something in the early 2.6.20th or
> younger?

Your patch assumes that anything later than 2.6.0 has a correct,
Adeos-aware panic. I just wonder whether this is true.

-- 
                                                                Gilles.

Re: [Xenomai-core] (Not yet) Xenomai 2.5.5.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Am 16.09.2010 20:51, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Am 16.09.2010 10:17, Gilles Chanteperdrix wrote:
>>>> Hi,
>>>>
>>>> I would like to make that next release of Xenomai, especially since the
>>>> fix for the I-pipe on x86_32 with grub2 has been available for some time
>>>> now, and has not yet been in a stable release.
>>>>
>>>> So, I have a few minor questions:
>>>> - Wolfgang, Alexis, it seems we have a few warnings when compiling
>>>> rtcan/analogy tools with recent versions of gcc (4.4.1 from
>>>> codesourcery). You will find the logs here:
>>>> http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
>>>> we are not in a hurry to fix this, so simply tell me if the fix is easy
>>>> or not.
>>>> - Alexis, from the mailing list discussions, you probably have some
>>>> commits ready in the analoty branch, would it be possible to have a pull
>>>> request for these?
>>>> - Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
>>>> Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
>>>> changed following the discussions with Philippe?
>>> I've a ready-to-use version that should address all of Philippe's
>>> remarks in my 2.6.35 queue [1]. The plan was to push it along this line,
>>> but then things got stuck due to the 32-bit boot hang report by Ed
>>> Hoffman (still waiting for further information from him). Also my KVM
>>> patches in that queue do not work yet, but they will likely be postponed.
>>>
>>> Besides that, I've longer queue of fixes and enhancement to Xenomai [2]
>>> that partially depends on [1]. I already sent pull requests, but then
>>> did not refresh it due to the dependency.
>>>
>>> Unfortunately, I'm "a bit" short on time the next weeks, so we need to
>>> find the cheapest way of getting the most important stuff merged for
>>> 2.5.5 I guess. I already started backporting the critical sync fixes for
>>> I-pipe to 2.6.34 [3], just sent no pull request yet.
>> Ok. I would like to be able to merge at least before the middle of next
>> week so as to validate a bit the result before releasing, hopefully,
>> before the end of next week.
>>
>> I had a look at the patches you pushed. I find it a bit dangerous to
>> merge quickly such patches, which fiddle with the nklock, without
>> extensive testing.
> 
> This is first of all xenomai-head stuff, nothing that shall be
> unconditionally backported. But even for head, we can perfectly skip the
> debugging part. Important are the fixes. I've reordered and shortened my
> queue already.
> 
>> The risk is that on SMP machines, the cpus start
>> dumping stack traces concurrently, resulting in an unreadable mess (we
>> have seen this in the past actually), whereas, correct me if I am wrong,
>> if the output takes place on the serial port, which is the current
>> preferred debug setup with Xenomai, we do not have to schedule klogd to
>> get an output, so we do not have to release the nklock.
> 
> I will have to check this again, but I bet the need for dropping nklock
> came from the fact that more than the serial port was configured (that's
> default here). Then some other console driver may have locked things up
> while walking the write handlers. Moreover, I would like to get more
> data in case the user did not yet prepare for catching a Xenomai panic.
> But, of course, dump regressions must be avoided.

We could use a separate lock to prevent multiple panics at the same time
from talking at the same time. But now that I think about it, panic
probably alread takes care of this.

> 
>> I also do not understand the game with panic. It looks to me there is a
>> risk of breaking compatibility with older Adeos patches, whose panic was
>> not as solid as the one of the current releases.
> 
> Do you have some versions in mind? Something in the early 2.6.20th or
> younger?

Not much of an issue finally. Except stubborn newcomers, people using
old patches probably have been using them for a long time and do not
have much kernel panics debug to do.

-- 
					    Gilles.

Re: [Xenomai-help] (Not yet) Xenomai 2.5.5.

[Stefan Kisdaroczi]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

On 16.09.2010 10:17, Gilles Chanteperdrix wrote:
> Hi,
>
> I would like to make that next release of Xenomai,

Hi Gilles,

don't forget [1] Peter Soetens rtcan patch [2]:
[1] https://mail.gna.org/public/xenomai-help/2010-08/msg00085.html
[2] https://mail.gna.org/public/xenomai-help/2010-07/msg00112.html

Stefan

>  especially since the
> fix for the I-pipe on x86_32 with grub2 has been available for some time
> now, and has not yet been in a stable release.
>
> So, I have a few minor questions:
> - Wolfgang, Alexis, it seems we have a few warnings when compiling
> rtcan/analogy tools with recent versions of gcc (4.4.1 from
> codesourcery). You will find the logs here:
> http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
> we are not in a hurry to fix this, so simply tell me if the fix is easy
> or not.
> - Alexis, from the mailing list discussions, you probably have some
> commits ready in the analoty branch, would it be possible to have a pull
> request for these?
> - Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
> Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
> changed following the discussions with Philippe?
>
> Thanks in advance.
>
>   



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Xenomai-core] [Xenomai-help] (Not yet) Xenomai 2.5.5.

[Gilles Chanteperdrix]

Stefan Kisdaroczi wrote:
> On 16.09.2010 10:17, Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I would like to make that next release of Xenomai,
> 
> Hi Gilles,
> 
> don't forget [1] Peter Soetens rtcan patch [2]:
> [1] https://mail.gna.org/public/xenomai-help/2010-08/msg00085.html
> [2] https://mail.gna.org/public/xenomai-help/2010-07/msg00112.html

Done, almost forgotten again, thanks!

-- 
                                                                Gilles.

Re: [Xenomai-help] (Not yet) Xenomai 2.5.5

[Edward Hoffman]

Jan,

I rebuilt the 32-bit kernel using linux-2.6.35.4 and xenomai-2.5.4 and
the latest Adeos patch you supplied.  Although with the it appears that
my Megaraid 8888 ELP controller does not load with the required Xenomai
changes.  The basic xenomai tests now appear run OK.

If you want, please forward an alpha copy of the xenomai-2.5.5 release
and I will test on 32-bit and 64-bit.

RSVP.

Regards,

Ed