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

2010-09-17 Thread 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.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2010-09-16 Thread 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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2010-09-16 Thread 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.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2010-09-16 Thread Jan Kiszka
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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2010-09-16 Thread 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.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core