[Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Jan Kiszka]

Hi,

just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
head, but I only ran light tests so far. Anyone interested in upgrading
the host kernel (I think I read some request recently) is welcome to
give it a try and report results back (specifically on 32 bit as that is
a bit out of focus for me ATM). You can download the full git tree from

	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
	(alternatively also via http://)

Looking forward to feedback,
Jan

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

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Philippe Gerum]

On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> Hi,
> 
> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> head, but I only ran light tests so far. Anyone interested in upgrading
> the host kernel (I think I read some request recently) is welcome to
> give it a try and report results back (specifically on 32 bit as that is
> a bit out of focus for me ATM). You can download the full git tree from
> 
> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> 	(alternatively also via http://)
> 
> Looking forward to feedback,

The comment and the relevant code for 82a7dd3df needs fixing: all
pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3].
powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in
2.6.35. The upcoming arm/SMP port conforms to this requirement as well.
Those are merely pipelined IPI channels, the way the arch-dep section
manages to multiplex them (or not) over the available hw channel(s) is
of course unspecified. The virtual IPI numbers are also unspecified.

Nitpicking: if you intend to push this material to me at some point,
please make sure to prefix commit subject lines with 'ipipe:' for the
-noarch section, and 'x86/ipipe:' for the rest. I'm a grep fanboy, and
this 'tends' to conform to linux mainline as well.

> Jan
> 

-- 
Philippe.

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Jan Kiszka]

Philippe Gerum wrote:
> On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
>> Hi,
>>
>> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
>> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
>> head, but I only ran light tests so far. Anyone interested in upgrading
>> the host kernel (I think I read some request recently) is welcome to
>> give it a try and report results back (specifically on 32 bit as that is
>> a bit out of focus for me ATM). You can download the full git tree from
>>
>> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
>> 	(alternatively also via http://)
>>
>> Looking forward to feedback,
> 
> The comment and the relevant code for 82a7dd3df needs fixing: all
> pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3].
> powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in
> 2.6.35. The upcoming arm/SMP port conforms to this requirement as well.
> Those are merely pipelined IPI channels, the way the arch-dep section
> manages to multiplex them (or not) over the available hw channel(s) is
> of course unspecified. The virtual IPI numbers are also unspecified.

Ah, so you mean a generic parameter check in ipipe_send_ipi for those 4
IPIs is possible? Then I will add a corresponding patch to the generic
queue.

> 
> Nitpicking: if you intend to push this material to me at some point,
> please make sure to prefix commit subject lines with 'ipipe:' for the
> -noarch section, and 'x86/ipipe:' for the rest. I'm a grep fanboy, and
> this 'tends' to conform to linux mainline as well.

OK, will fix.

And if I had a wish for the maintainer: Please ensure that the -noarch
branch in kept in proper sync with the latest arch. Took me a while (and
two temp branches) to extract a proper x86-only patch for the port.

Jan

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

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Philippe Gerum]

On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote:
> On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> > Hi,
> > 
> > just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> > stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> > head, but I only ran light tests so far. Anyone interested in upgrading
> > the host kernel (I think I read some request recently) is welcome to
> > give it a try and report results back (specifically on 32 bit as that is
> > a bit out of focus for me ATM). You can download the full git tree from
> > 
> > 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> > 	(alternatively also via http://)
> > 
> > Looking forward to feedback,
> 
> The comment and the relevant code for 82a7dd3df needs fixing: all
> pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3].
> powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in
> 2.6.35. The upcoming arm/SMP port conforms to this requirement as well.
> Those are merely pipelined IPI channels, the way the arch-dep section
> manages to multiplex them (or not) over the available hw channel(s) is
> of course unspecified. The virtual IPI numbers are also unspecified.

Actually, the more I think of it, the less I see the value of checking
the parameter passed to such an internal call like __ipipe_send_ipi().
There is no user interaction with this code. So removing the test is
indeed better.

> 
> Nitpicking: if you intend to push this material to me at some point,
> please make sure to prefix commit subject lines with 'ipipe:' for the
> -noarch section, and 'x86/ipipe:' for the rest. I'm a grep fanboy, and
> this 'tends' to conform to linux mainline as well.
> 
> > Jan
> > 
> 

-- 
Philippe.

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Jan Kiszka]

Philippe Gerum wrote:
> On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote:
>> On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
>>> Hi,
>>>
>>> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
>>> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
>>> head, but I only ran light tests so far. Anyone interested in upgrading
>>> the host kernel (I think I read some request recently) is welcome to
>>> give it a try and report results back (specifically on 32 bit as that is
>>> a bit out of focus for me ATM). You can download the full git tree from
>>>
>>> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
>>> 	(alternatively also via http://)
>>>
>>> Looking forward to feedback,
>> The comment and the relevant code for 82a7dd3df needs fixing: all
>> pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3].
>> powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in
>> 2.6.35. The upcoming arm/SMP port conforms to this requirement as well.
>> Those are merely pipelined IPI channels, the way the arch-dep section
>> manages to multiplex them (or not) over the available hw channel(s) is
>> of course unspecified. The virtual IPI numbers are also unspecified.
> 
> Actually, the more I think of it, the less I see the value of checking
> the parameter passed to such an internal call like __ipipe_send_ipi().
> There is no user interaction with this code. So removing the test is
> indeed better.
> 

Isn't ipipe_send_ipi() a public API? That's what I was thinking of: if
at all, then here.

Jan

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

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Philippe Gerum]

On Tue, 2010-08-24 at 18:46 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote:
> >> On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> >>> Hi,
> >>>
> >>> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> >>> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> >>> head, but I only ran light tests so far. Anyone interested in upgrading
> >>> the host kernel (I think I read some request recently) is welcome to
> >>> give it a try and report results back (specifically on 32 bit as that is
> >>> a bit out of focus for me ATM). You can download the full git tree from
> >>>
> >>> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> >>> 	(alternatively also via http://)
> >>>
> >>> Looking forward to feedback,
> >> The comment and the relevant code for 82a7dd3df needs fixing: all
> >> pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3].
> >> powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in
> >> 2.6.35. The upcoming arm/SMP port conforms to this requirement as well.
> >> Those are merely pipelined IPI channels, the way the arch-dep section
> >> manages to multiplex them (or not) over the available hw channel(s) is
> >> of course unspecified. The virtual IPI numbers are also unspecified.
> > 
> > Actually, the more I think of it, the less I see the value of checking
> > the parameter passed to such an internal call like __ipipe_send_ipi().
> > There is no user interaction with this code. So removing the test is
> > indeed better.
> > 
> 
> Isn't ipipe_send_ipi() a public API? That's what I was thinking of: if
> at all, then here.

Yes, ipipe_send_ipi() is the public API, calliong into
__ipipe_send_ipi() for a per-arch implementation; I messed up in my
explanation. My point is that your idea to remove the check from
__ipipe_send_ipi seems correct to me, since nobody should send a silly
value to this internal call. The test should be done in ipipe_send_ipi()
once for all, relying on the generic names of the IPIs.

Regarding those names, and unlike I initially thought, ppc64 is still
preventing me from removing IPI4 in 2.6.35, so I guess that for
implementing a generic test, we would have to resort to #ifdef
pollution.

> 
> Jan
> 

-- 
Philippe.

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Jan Kiszka]

Philippe Gerum wrote:
> On Tue, 2010-08-24 at 18:46 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote:
>>>> On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
>>>>> Hi,
>>>>>
>>>>> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
>>>>> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
>>>>> head, but I only ran light tests so far. Anyone interested in upgrading
>>>>> the host kernel (I think I read some request recently) is welcome to
>>>>> give it a try and report results back (specifically on 32 bit as that is
>>>>> a bit out of focus for me ATM). You can download the full git tree from
>>>>>
>>>>> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
>>>>> 	(alternatively also via http://)
>>>>>
>>>>> Looking forward to feedback,
>>>> The comment and the relevant code for 82a7dd3df needs fixing: all
>>>> pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3].
>>>> powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in
>>>> 2.6.35. The upcoming arm/SMP port conforms to this requirement as well.
>>>> Those are merely pipelined IPI channels, the way the arch-dep section
>>>> manages to multiplex them (or not) over the available hw channel(s) is
>>>> of course unspecified. The virtual IPI numbers are also unspecified.
>>> Actually, the more I think of it, the less I see the value of checking
>>> the parameter passed to such an internal call like __ipipe_send_ipi().
>>> There is no user interaction with this code. So removing the test is
>>> indeed better.
>>>
>> Isn't ipipe_send_ipi() a public API? That's what I was thinking of: if
>> at all, then here.
> 
> Yes, ipipe_send_ipi() is the public API, calliong into
> __ipipe_send_ipi() for a per-arch implementation; I messed up in my
> explanation. My point is that your idea to remove the check from
> __ipipe_send_ipi seems correct to me, since nobody should send a silly
> value to this internal call. The test should be done in ipipe_send_ipi()
> once for all, relying on the generic names of the IPIs.
> 
> Regarding those names, and unlike I initially thought, ppc64 is still
> preventing me from removing IPI4 in 2.6.35, so I guess that for
> implementing a generic test, we would have to resort to #ifdef
> pollution.

Can we require that the IPI numbers are consecutive? Then the arch could
define an upper limit, and we could do a nicer range check in the
generic code.

Jan

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

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Philippe Gerum]

On Tue, 2010-08-24 at 19:14 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Tue, 2010-08-24 at 18:46 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Tue, 2010-08-24 at 18:30 +0200, Philippe Gerum wrote:
> >>>> On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> >>>>> Hi,
> >>>>>
> >>>>> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> >>>>> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> >>>>> head, but I only ran light tests so far. Anyone interested in upgrading
> >>>>> the host kernel (I think I read some request recently) is welcome to
> >>>>> give it a try and report results back (specifically on 32 bit as that is
> >>>>> a bit out of focus for me ATM). You can download the full git tree from
> >>>>>
> >>>>> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> >>>>> 	(alternatively also via http://)
> >>>>>
> >>>>> Looking forward to feedback,
> >>>> The comment and the relevant code for 82a7dd3df needs fixing: all
> >>>> pipeline ports should expose 4 IPIs, named IPIPE_SERVICE_IPI[0-3].
> >>>> powerpc/SMP has one more up to 2.6.34, but IPI4 will disappear in
> >>>> 2.6.35. The upcoming arm/SMP port conforms to this requirement as well.
> >>>> Those are merely pipelined IPI channels, the way the arch-dep section
> >>>> manages to multiplex them (or not) over the available hw channel(s) is
> >>>> of course unspecified. The virtual IPI numbers are also unspecified.
> >>> Actually, the more I think of it, the less I see the value of checking
> >>> the parameter passed to such an internal call like __ipipe_send_ipi().
> >>> There is no user interaction with this code. So removing the test is
> >>> indeed better.
> >>>
> >> Isn't ipipe_send_ipi() a public API? That's what I was thinking of: if
> >> at all, then here.
> > 
> > Yes, ipipe_send_ipi() is the public API, calliong into
> > __ipipe_send_ipi() for a per-arch implementation; I messed up in my
> > explanation. My point is that your idea to remove the check from
> > __ipipe_send_ipi seems correct to me, since nobody should send a silly
> > value to this internal call. The test should be done in ipipe_send_ipi()
> > once for all, relying on the generic names of the IPIs.
> > 
> > Regarding those names, and unlike I initially thought, ppc64 is still
> > preventing me from removing IPI4 in 2.6.35, so I guess that for
> > implementing a generic test, we would have to resort to #ifdef
> > pollution.
> 
> Can we require that the IPI numbers are consecutive? Then the arch could
> define an upper limit, and we could do a nicer range check in the
> generic code.

Sure. In fact, ipipe_ipi_p() testing this would be just as nice.

> 
> Jan
> 

-- 
Philippe.

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Philippe Gerum]

On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> Hi,
> 
> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> head, but I only ran light tests so far. Anyone interested in upgrading
> the host kernel (I think I read some request recently) is welcome to
> give it a try and report results back (specifically on 32 bit as that is
> a bit out of focus for me ATM). You can download the full git tree from
> 
> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> 	(alternatively also via http://)
> 

Btw, could you pick Wolfgang's host rt clock patch in your queue as
well? I only have a few minor issues with it, which are no showstopper.
The only thing to care of before merging this to mainline, is that no
other arch does support this feature yet, so it is important to make it
fully optional in -noarch, and Xenomai-wise also.

We likely need some __IPIPE_FEATURE_* symbol to be defined in
arch/x86/include/ipipe_base.h for this purpose, so that depending code
could test for presence.

I'll pull the whole thing from your tree when x86_32 is known to rock as
well.

> Looking forward to feedback,
> Jan
> 

-- 
Philippe.

Re: [Xenomai-help] [Adeos-main] [RFT] ipipe patch for 2.6.35.3-x86

[Jan Kiszka]

Philippe Gerum wrote:
> On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
>> Hi,
>>
>> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
>> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
>> head, but I only ran light tests so far. Anyone interested in upgrading
>> the host kernel (I think I read some request recently) is welcome to
>> give it a try and report results back (specifically on 32 bit as that is
>> a bit out of focus for me ATM). You can download the full git tree from
>>
>> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
>> 	(alternatively also via http://)
>>
> 
> Btw, could you pick Wolfgang's host rt clock patch in your queue as
> well? I only have a few minor issues with it, which are no showstopper.
> The only thing to care of before merging this to mainline, is that no
> other arch does support this feature yet, so it is important to make it
> fully optional in -noarch, and Xenomai-wise also.
> 
> We likely need some __IPIPE_FEATURE_* symbol to be defined in
> arch/x86/include/ipipe_base.h for this purpose, so that depending code
> could test for presence.

Will have a look.

There is one further feature on my to-do list anyway: KVM support. Will
also require a feature bit (for a new root preemption notifier).

> 
> I'll pull the whole thing from your tree when x86_32 is known to rock as
> well.

OK, great.

Jan

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

[Adeos-main] hostrt patches (was: [RFT] ipipe patch for 2.6.35.3-x86)

[Jan Kiszka]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Btw, could you pick Wolfgang's host rt clock patch in your queue as
>> well? I only have a few minor issues with it, which are no showstopper.
>> The only thing to care of before merging this to mainline, is that no
>> other arch does support this feature yet, so it is important to make it
>> fully optional in -noarch, and Xenomai-wise also.
>>
>> We likely need some __IPIPE_FEATURE_* symbol to be defined in
>> arch/x86/include/ipipe_base.h for this purpose, so that depending code
>> could test for presence.
> 
> Will have a look.

Checked again: thanks to HAVE_IPIPE_HOSTRT, there should no need for any
feature bit. Will build-check this once more tomorrow.

What issue did you see?

Jan

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

Re: [Adeos-main] hostrt patches

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Btw, could you pick Wolfgang's host rt clock patch in your queue as
>>> well? I only have a few minor issues with it, which are no showstopper.
>>> The only thing to care of before merging this to mainline, is that no
>>> other arch does support this feature yet, so it is important to make it
>>> fully optional in -noarch, and Xenomai-wise also.
>>>
>>> We likely need some __IPIPE_FEATURE_* symbol to be defined in
>>> arch/x86/include/ipipe_base.h for this purpose, so that depending code
>>> could test for presence.
>> Will have a look.
> 
> Checked again: thanks to HAVE_IPIPE_HOSTRT, there should no need for any
> feature bit. Will build-check this once more tomorrow.
> 
> What issue did you see?

Well, I think other features are named IPIPE_FEATURE_BLAH... But I guess
that is a minor issue.

-- 
					    Gilles.

Re: [Adeos-main] hostrt patches (was: [RFT] ipipe patch for 2.6.35.3-x86)

[Philippe Gerum]

On Tue, 2010-08-24 at 19:31 +0200, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Philippe Gerum wrote:
> >> Btw, could you pick Wolfgang's host rt clock patch in your queue as
> >> well? I only have a few minor issues with it, which are no showstopper.
> >> The only thing to care of before merging this to mainline, is that no
> >> other arch does support this feature yet, so it is important to make it
> >> fully optional in -noarch, and Xenomai-wise also.
> >>
> >> We likely need some __IPIPE_FEATURE_* symbol to be defined in
> >> arch/x86/include/ipipe_base.h for this purpose, so that depending code
> >> could test for presence.
> > 
> > Will have a look.
> 
> Checked again: thanks to HAVE_IPIPE_HOSTRT, there should no need for any
> feature bit. Will build-check this once more tomorrow.
> 
> What issue did you see?

Comments will follow on Wolfgang's posts.

> 
> Jan
> 

-- 
Philippe.

Re: [Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Edward Hoffman]

I do not have a git repository setup.  Where can I download a version of
the patch that to put in the xenomai-2.5.4 patches directory?

I will then rebuild the 2.6.35.3 32-bit kernel and provide you with
feedback.

RSVP.

Ed

On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> Hi,
> 
> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> head, but I only ran light tests so far. Anyone interested in upgrading
> the host kernel (I think I read some request recently) is welcome to
> give it a try and report results back (specifically on 32 bit as that is
> a bit out of focus for me ATM). You can download the full git tree from
> 
> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> 	(alternatively also via http://)
> 
> Looking forward to feedback,
> Jan
> 

Re: [Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Jan Kiszka]

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

Edward Hoffman wrote:
> I do not have a git repository setup.  Where can I download a version of
> the patch that to put in the xenomai-2.5.4 patches directory?

Find it attached.

> 
> I will then rebuild the 2.6.35.3 32-bit kernel and provide you with
> feedback.

TIA,
Jan

> 
> RSVP.
> 
> Ed
> 
> On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
>> Hi,
>>
>> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
>> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
>> head, but I only ran light tests so far. Anyone interested in upgrading
>> the host kernel (I think I read some request recently) is welcome to
>> give it a try and report results back (specifically on 32 bit as that is
>> a bit out of focus for me ATM). You can download the full git tree from
>>
>> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
>> 	(alternatively also via http://)
>>
>> Looking forward to feedback,
>> Jan
>>
> 
> 

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

[-- Attachment #2: adeos-ipipe-2.6.35.3-x86-test1.patch.bz2 --]
[-- Type: application/x-bzip, Size: 64674 bytes --]

Re: [Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Edward Hoffman]

Jan,

I tried applying the patch.  It appears to be corrupted:

root@domain.hid# scripts/prepare-kernel.sh
Linux tree
[default /lib/modules/2.6.35.1/source]: /usr/src/linux-2.6.35.3
Target architecture [default i686]: 
Adeos patch
[default /usr/src/xenomai-2.5.4/ksrc/arch/x86/patches/adeos-ipipe-2.6.35.3-x86-test1.patch.bz2]: 
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.
prepare-kernel.sh: Unable to patch kernel 2.6.35.3 with
adeos-ipipe-2.6.35.3-x86-test1.patch.bz2.


Please forward a new patch.

Thanks.

RSVP.


Ed



On Wed, 2010-08-25 at 09:03 +0200, Jan Kiszka wrote:
> Edward Hoffman wrote:
> > I do not have a git repository setup.  Where can I download a version of
> > the patch that to put in the xenomai-2.5.4 patches directory?
> 
> Find it attached.
> 
> > 
> > I will then rebuild the 2.6.35.3 32-bit kernel and provide you with
> > feedback.
> 
> TIA,
> Jan
> 
> > 
> > RSVP.
> > 
> > Ed
> > 
> > On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> >> Hi,
> >>
> >> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> >> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> >> head, but I only ran light tests so far. Anyone interested in upgrading
> >> the host kernel (I think I read some request recently) is welcome to
> >> give it a try and report results back (specifically on 32 bit as that is
> >> a bit out of focus for me ATM). You can download the full git tree from
> >>
> >> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> >> 	(alternatively also via http://)
> >>
> >> Looking forward to feedback,
> >> Jan
> >>
> > 
> > 
> 

Re: [Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Edward Hoffman]

Jan,

Please ignore my e-mal below.

I must have missed that second cup of coffee this morning. I forget to
decompress the patch.  I have applied it to the kernel and I am building
it now.

Ed



On Wed, 2010-08-25 at 10:53 -0400, Edward Hoffman wrote:
> Jan,
> 
> I tried applying the patch.  It appears to be corrupted:
> 
> root@domain.hid# scripts/prepare-kernel.sh
> Linux tree
> [default /lib/modules/2.6.35.1/source]: /usr/src/linux-2.6.35.3
> Target architecture [default i686]: 
> Adeos patch
> [default /usr/src/xenomai-2.5.4/ksrc/arch/x86/patches/adeos-ipipe-2.6.35.3-x86-test1.patch.bz2]: 
> patch unexpectedly ends in middle of line
> patch: **** Only garbage was found in the patch input.
> prepare-kernel.sh: Unable to patch kernel 2.6.35.3 with
> adeos-ipipe-2.6.35.3-x86-test1.patch.bz2.
> 
> 
> Please forward a new patch.
> 
> Thanks.
> 
> RSVP.
> 
> 
> Ed
> 
> 
> 
> On Wed, 2010-08-25 at 09:03 +0200, Jan Kiszka wrote:
> > Edward Hoffman wrote:
> > > I do not have a git repository setup.  Where can I download a version of
> > > the patch that to put in the xenomai-2.5.4 patches directory?
> > 
> > Find it attached.
> > 
> > > 
> > > I will then rebuild the 2.6.35.3 32-bit kernel and provide you with
> > > feedback.
> > 
> > TIA,
> > Jan
> > 
> > > 
> > > RSVP.
> > > 
> > > Ed
> > > 
> > > On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> > >> Hi,
> > >>
> > >> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> > >> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> > >> head, but I only ran light tests so far. Anyone interested in upgrading
> > >> the host kernel (I think I read some request recently) is welcome to
> > >> give it a try and report results back (specifically on 32 bit as that is
> > >> a bit out of focus for me ATM). You can download the full git tree from
> > >>
> > >> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> > >> 	(alternatively also via http://)
> > >>
> > >> Looking forward to feedback,
> > >> Jan
> > >>
> > > 
> > > 
> > 
> 

Re: [Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Edward Hoffman]

Jan,

I reconfigured the linux-2.6.35.3 kernel (32-bit) after applying the
adeos kernel patch.  All I get when I reboot is a black screen with a
blinking cursor.

Any suggestions.

Ed




On Wed, 2010-08-25 at 10:59 -0400, Edward Hoffman wrote:
> Jan,
> 
> Please ignore my e-mal below.
> 
> I must have missed that second cup of coffee this morning. I forget to
> decompress the patch.  I have applied it to the kernel and I am building
> it now.
> 
> Ed
> 
> 
> 
> On Wed, 2010-08-25 at 10:53 -0400, Edward Hoffman wrote:
> > Jan,
> > 
> > I tried applying the patch.  It appears to be corrupted:
> > 
> > root@domain.hid# scripts/prepare-kernel.sh
> > Linux tree
> > [default /lib/modules/2.6.35.1/source]: /usr/src/linux-2.6.35.3
> > Target architecture [default i686]: 
> > Adeos patch
> > [default /usr/src/xenomai-2.5.4/ksrc/arch/x86/patches/adeos-ipipe-2.6.35.3-x86-test1.patch.bz2]: 
> > patch unexpectedly ends in middle of line
> > patch: **** Only garbage was found in the patch input.
> > prepare-kernel.sh: Unable to patch kernel 2.6.35.3 with
> > adeos-ipipe-2.6.35.3-x86-test1.patch.bz2.
> > 
> > 
> > Please forward a new patch.
> > 
> > Thanks.
> > 
> > RSVP.
> > 
> > 
> > Ed
> > 
> > 
> > 
> > On Wed, 2010-08-25 at 09:03 +0200, Jan Kiszka wrote:
> > > Edward Hoffman wrote:
> > > > I do not have a git repository setup.  Where can I download a version of
> > > > the patch that to put in the xenomai-2.5.4 patches directory?
> > > 
> > > Find it attached.
> > > 
> > > > 
> > > > I will then rebuild the 2.6.35.3 32-bit kernel and provide you with
> > > > feedback.
> > > 
> > > TIA,
> > > Jan
> > > 
> > > > 
> > > > RSVP.
> > > > 
> > > > Ed
> > > > 
> > > > On Tue, 2010-08-24 at 17:59 +0200, Jan Kiszka wrote:
> > > >> Hi,
> > > >>
> > > >> just uploaded a forward port of the 2.6.34 ipipe patch for x86 to latest
> > > >> stable 2.6.35.3. It boots and runs fine here in 64-bit mode with Xenomai
> > > >> head, but I only ran light tests so far. Anyone interested in upgrading
> > > >> the host kernel (I think I read some request recently) is welcome to
> > > >> give it a try and report results back (specifically on 32 bit as that is
> > > >> a bit out of focus for me ATM). You can download the full git tree from
> > > >>
> > > >> 	git://git.kiszka.org/ipipe-2.6.git queues/2.6.35-x86
> > > >> 	(alternatively also via http://)
> > > >>
> > > >> Looking forward to feedback,
> > > >> Jan
> > > >>
> > > > 
> > > > 
> > > 
> > 
> 

Re: [Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Jan Kiszka]

Edward Hoffman wrote:
> Jan,
> 
> I reconfigured the linux-2.6.35.3 kernel (32-bit) after applying the
> adeos kernel patch.  All I get when I reboot is a black screen with a
> blinking cursor.
> 
> Any suggestions.
> 

I'm building a 32-bit kernel in the background. I case that one happens
to boot, I will come back and ask for your config.

Jan

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

Re: [Xenomai-help] [RFT] ipipe patch for 2.6.35.3-x86

[Jan Kiszka]

Jan Kiszka wrote:
> Edward Hoffman wrote:
>> Jan,
>>
>> I reconfigured the linux-2.6.35.3 kernel (32-bit) after applying the
>> adeos kernel patch.  All I get when I reboot is a black screen with a
>> blinking cursor.
>>
>> Any suggestions.
>>
> 
> I'm building a 32-bit kernel in the background. I case that one happens
> to boot, I will come back and ask for your config.

Looks like I do need your .config as I'm only getting a false-positive
warning from lockdep, the 32-bit kernel boots and runs fine otherwise,
at least in UP mode.

Jan

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