All of lore.kernel.org
 help / color / mirror / Atom feed
* [Adeos-main] port 2.6.19 x86_64 to 2.6.20
@ 2007-02-25 23:50 trem
  2007-02-26  5:56 ` Philippe Gerum
  0 siblings, 1 reply; 8+ messages in thread
From: trem @ 2007-02-25 23:50 UTC (permalink / raw)
  To: adeos-main

Hi

I've tried to port the 2.6.19 x86_64 adeos patch to 2.6.20. you can find
it here :
http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-03-trem.patch

I can apply it with with prepare_kernel.sh (from xenomai svn), but I haven't
tested it yet (I mean run kernel).

I hope this patch is good enough to be used. Otherwise, I'd be pleased
to fix it (maybe with a bit of help).

regards,
trem




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Adeos-main] port 2.6.19 x86_64 to 2.6.20
  2007-02-25 23:50 [Adeos-main] port 2.6.19 x86_64 to 2.6.20 trem
@ 2007-02-26  5:56 ` Philippe Gerum
  2007-03-03 22:24   ` trem
  0 siblings, 1 reply; 8+ messages in thread
From: Philippe Gerum @ 2007-02-26  5:56 UTC (permalink / raw)
  To: trem; +Cc: adeos-main

On Mon, 2007-02-26 at 00:50 +0100, trem wrote:
> Hi
> 
> I've tried to port the 2.6.19 x86_64 adeos patch to 2.6.20. you can find
> it here :
> http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-03-trem.patch

The good news is that moving to 2.6.20 does not seem to be too much of a
hell. Right?

> 
> I can apply it with with prepare_kernel.sh (from xenomai svn), but I haven't
> tested it yet (I mean run kernel).
> 
> I hope this patch is good enough to be used. Otherwise, I'd be pleased
> to fix it (maybe with a bit of help).
> 

We are hopefully close to have a reasonably good patch for 2.6.19. Once
we achieve this, porting to 2.6.20 should be the next step. Thanks.

-- 
Philippe.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Adeos-main] port 2.6.19 x86_64 to 2.6.20
  2007-02-26  5:56 ` Philippe Gerum
@ 2007-03-03 22:24   ` trem
  2007-03-03 22:58     ` Philippe Gerum
  0 siblings, 1 reply; 8+ messages in thread
From: trem @ 2007-03-03 22:24 UTC (permalink / raw)
  To: rpm; +Cc: adeos-main

Philippe Gerum wrote:
> On Mon, 2007-02-26 at 00:50 +0100, trem wrote:
>   
>> Hi
>>
>> I've tried to port the 2.6.19 x86_64 adeos patch to 2.6.20. you can find
>> it here :
>> http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-03-trem.patch
>>     
>
> The good news is that moving to 2.6.20 does not seem to be too much of a
> hell. Right?
>
>   
Yes, there are few conflict so it's quite easy to port xenomai to 2.6.20.
>> I can apply it with with prepare_kernel.sh (from xenomai svn), but I haven't
>> tested it yet (I mean run kernel).
>>
>> I hope this patch is good enough to be used. Otherwise, I'd be pleased
>> to fix it (maybe with a bit of help).
>>
>>     
>
> We are hopefully close to have a reasonably good patch for 2.6.19. Once
> we achieve this, porting to 2.6.20 should be the next step. Thanks.
>
>   
I've seen ths in the Changelog : "this closes the implementation phase
of the x86_64 port."
So I suppose that the patch for 2.6.19 is finished. I've tried it and it
works fine.
The result of latency is :

[trem@domain.hid bin]$ sudo ./latency -T 10
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|       0.760|       1.073|       3.660|       0|       0.760|      
3.660
RTD|       0.737|       1.063|       3.012|       0|       0.737|      
3.660
RTD|       0.741|       1.083|       3.396|       0|       0.737|      
3.660
RTD|       0.755|       1.088|       2.344|       0|       0.737|      
3.660
RTD|       0.754|       1.093|       3.431|       0|       0.737|      
3.660
RTD|       0.755|       1.089|       5.119|       0|       0.737|      
5.119
RTD|       0.724|       1.091|       3.126|       0|       0.724|      
5.119
RTD|       0.762|       1.089|       3.171|       0|       0.724|      
5.119
RTD|       0.751|       1.097|       5.508|       0|       0.724|      
5.508
---|------------|------------|------------|--------|-------------------------
RTS|       0.724|       1.085|       5.508|       0|    00:00:10/00:00:10

If I don't mistake, I see a max latency of 5us. Is it realistic ?

Now, the port to 2.6.20 is open ? we can work on ?


trem





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Adeos-main] port 2.6.19 x86_64 to 2.6.20
  2007-03-03 22:24   ` trem
@ 2007-03-03 22:58     ` Philippe Gerum
  2007-03-04 17:32       ` trem
  0 siblings, 1 reply; 8+ messages in thread
From: Philippe Gerum @ 2007-03-03 22:58 UTC (permalink / raw)
  To: trem; +Cc: adeos-main

On Sat, 2007-03-03 at 23:24 +0100, trem wrote:
> Philippe Gerum wrote:
> > On Mon, 2007-02-26 at 00:50 +0100, trem wrote:
> >   
> >> Hi
> >>
> >> I've tried to port the 2.6.19 x86_64 adeos patch to 2.6.20. you can find
> >> it here :
> >> http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-03-trem.patch
> >>     
> >
> > The good news is that moving to 2.6.20 does not seem to be too much of a
> > hell. Right?
> >
> >   
> Yes, there are few conflict so it's quite easy to port xenomai to 2.6.20.
> >> I can apply it with with prepare_kernel.sh (from xenomai svn), but I haven't
> >> tested it yet (I mean run kernel).
> >>
> >> I hope this patch is good enough to be used. Otherwise, I'd be pleased
> >> to fix it (maybe with a bit of help).
> >>
> >>     
> >
> > We are hopefully close to have a reasonably good patch for 2.6.19. Once
> > we achieve this, porting to 2.6.20 should be the next step. Thanks.
> >
> >   
> I've seen ths in the Changelog : "this closes the implementation phase
> of the x86_64 port."
> So I suppose that the patch for 2.6.19 is finished. I've tried it and it
> works fine.
> The result of latency is :
> 
> [trem@domain.hid bin]$ sudo ./latency -T 10
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|       0.760|       1.073|       3.660|       0|       0.760|      
> 3.660
> RTD|       0.737|       1.063|       3.012|       0|       0.737|      
> 3.660
> RTD|       0.741|       1.083|       3.396|       0|       0.737|      
> 3.660
> RTD|       0.755|       1.088|       2.344|       0|       0.737|      
> 3.660
> RTD|       0.754|       1.093|       3.431|       0|       0.737|      
> 3.660
> RTD|       0.755|       1.089|       5.119|       0|       0.737|      
> 5.119
> RTD|       0.724|       1.091|       3.126|       0|       0.724|      
> 5.119
> RTD|       0.762|       1.089|       3.171|       0|       0.724|      
> 5.119
> RTD|       0.751|       1.097|       5.508|       0|       0.724|      
> 5.508
> ---|------------|------------|------------|--------|-------------------------
> RTS|       0.724|       1.085|       5.508|       0|    00:00:10/00:00:10
> 
> If I don't mistake, I see a max latency of 5us. Is it realistic ?
> 

Yes. X-related problems Paul told us about being put aside (likely MTRR
issues, still to be chased), I see < 10 us under SMP test load on a 2 x
dual core Opteron 285 here (test load meaning two parallel kernel
compilations (-j5), and some significant network load).

We still have to benchmark this port more exhaustively and aggressively
(e.g. different I/O loads and severe cache trashing, for longer than 8
hours), but the foundations look sane, especially since the
Xenomai/x86_64 port currently runs with a default latency calibration
set to 500 ns over this.

> Now, the port to 2.6.20 is open ? we can work on ?
> 

Yep. Have fun.

> 
> trem
> 
> 
> 
-- 
Philippe.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Adeos-main] port 2.6.19 x86_64 to 2.6.20
  2007-03-03 22:58     ` Philippe Gerum
@ 2007-03-04 17:32       ` trem
  2007-03-07 23:31         ` Philippe Gerum
  2007-03-25 17:19         ` Philippe Gerum
  0 siblings, 2 replies; 8+ messages in thread
From: trem @ 2007-03-04 17:32 UTC (permalink / raw)
  To: rpm; +Cc: adeos-main

Hi

As I've got your start now, I've ported (at least tried) the 2.6.19
x86_64 adeos patch to 2.6.20.
I've tried it and it seems to works fine, here the latency :

[trem@domain.hid ~]$ cat latency_xenomai_2_6_20.txt
[trem@domain.hid bin]$ sudo ./latency -T 10
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|       0.737|       1.067|       3.332|       0|       0.737|      
3.332
RTD|       0.744|       1.067|       3.568|       0|       0.737|      
3.568
RTD|       0.724|       1.080|       3.362|       0|       0.724|      
3.568
RTD|       0.730|       1.070|       2.900|       0|       0.724|      
3.568
RTD|       0.711|       1.071|       3.441|       0|       0.711|      
3.568
RTD|       0.733|       1.066|       3.547|       0|       0.711|      
3.568
RTD|       0.735|       1.079|       4.523|       0|       0.711|      
4.523
RTD|       0.716|       1.072|       3.307|       0|       0.711|      
4.523
RTD|       0.715|       1.066|       3.507|       0|       0.711|      
4.523
---|------------|------------|------------|--------|-------------------------
RTS|       0.711|       1.071|       4.523|       0|    00:00:10/00:00:10


The patch (2.6.20 x86_64) can be found here :
http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-07-trem.patch

I hope it could be used.

regards,
trem


Philippe Gerum wrote:
> On Sat, 2007-03-03 at 23:24 +0100, trem wrote:
>   
>> Philippe Gerum wrote:
>>     
>>> On Mon, 2007-02-26 at 00:50 +0100, trem wrote:
>>>   
>>>       
>>>> Hi
>>>>
>>>> I've tried to port the 2.6.19 x86_64 adeos patch to 2.6.20. you can find
>>>> it here :
>>>> http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-03-trem.patch
>>>>     
>>>>         
>>> The good news is that moving to 2.6.20 does not seem to be too much of a
>>> hell. Right?
>>>
>>>   
>>>       
>> Yes, there are few conflict so it's quite easy to port xenomai to 2.6.20.
>>     
>>>> I can apply it with with prepare_kernel.sh (from xenomai svn), but I haven't
>>>> tested it yet (I mean run kernel).
>>>>
>>>> I hope this patch is good enough to be used. Otherwise, I'd be pleased
>>>> to fix it (maybe with a bit of help).
>>>>
>>>>     
>>>>         
>>> We are hopefully close to have a reasonably good patch for 2.6.19. Once
>>> we achieve this, porting to 2.6.20 should be the next step. Thanks.
>>>
>>>   
>>>       
>> I've seen ths in the Changelog : "this closes the implementation phase
>> of the x86_64 port."
>> So I suppose that the patch for 2.6.19 is finished. I've tried it and it
>> works fine.
>> The result of latency is :
>>
>> [trem@domain.hid bin]$ sudo ./latency -T 10
>> == Sampling period: 100 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
>> worst
>> RTD|       0.760|       1.073|       3.660|       0|       0.760|      
>> 3.660
>> RTD|       0.737|       1.063|       3.012|       0|       0.737|      
>> 3.660
>> RTD|       0.741|       1.083|       3.396|       0|       0.737|      
>> 3.660
>> RTD|       0.755|       1.088|       2.344|       0|       0.737|      
>> 3.660
>> RTD|       0.754|       1.093|       3.431|       0|       0.737|      
>> 3.660
>> RTD|       0.755|       1.089|       5.119|       0|       0.737|      
>> 5.119
>> RTD|       0.724|       1.091|       3.126|       0|       0.724|      
>> 5.119
>> RTD|       0.762|       1.089|       3.171|       0|       0.724|      
>> 5.119
>> RTD|       0.751|       1.097|       5.508|       0|       0.724|      
>> 5.508
>> ---|------------|------------|------------|--------|-------------------------
>> RTS|       0.724|       1.085|       5.508|       0|    00:00:10/00:00:10
>>
>> If I don't mistake, I see a max latency of 5us. Is it realistic ?
>>
>>     
>
> Yes. X-related problems Paul told us about being put aside (likely MTRR
> issues, still to be chased), I see < 10 us under SMP test load on a 2 x
> dual core Opteron 285 here (test load meaning two parallel kernel
> compilations (-j5), and some significant network load).
>
> We still have to benchmark this port more exhaustively and aggressively
> (e.g. different I/O loads and severe cache trashing, for longer than 8
> hours), but the foundations look sane, especially since the
> Xenomai/x86_64 port currently runs with a default latency calibration
> set to 500 ns over this.
>
>   
>> Now, the port to 2.6.20 is open ? we can work on ?
>>
>>     
>
> Yep. Have fun.
>
>   
>> trem
>>
>>
>>
>>     




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Adeos-main] port 2.6.19 x86_64 to 2.6.20
  2007-03-04 17:32       ` trem
@ 2007-03-07 23:31         ` Philippe Gerum
  2007-03-25 17:19         ` Philippe Gerum
  1 sibling, 0 replies; 8+ messages in thread
From: Philippe Gerum @ 2007-03-07 23:31 UTC (permalink / raw)
  To: trem; +Cc: adeos-main

On Sun, 2007-03-04 at 18:32 +0100, trem wrote:
> Hi
> 
> As I've got your start now, I've ported (at least tried) the 2.6.19
> x86_64 adeos patch to 2.6.20.
> I've tried it and it seems to works fine, here the latency :
> 
> [trem@domain.hid ~]$ cat latency_xenomai_2_6_20.txt
> [trem@domain.hid bin]$ sudo ./latency -T 10
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|       0.737|       1.067|       3.332|       0|       0.737|      
> 3.332
> RTD|       0.744|       1.067|       3.568|       0|       0.737|      
> 3.568
> RTD|       0.724|       1.080|       3.362|       0|       0.724|      
> 3.568
> RTD|       0.730|       1.070|       2.900|       0|       0.724|      
> 3.568
> RTD|       0.711|       1.071|       3.441|       0|       0.711|      
> 3.568
> RTD|       0.733|       1.066|       3.547|       0|       0.711|      
> 3.568
> RTD|       0.735|       1.079|       4.523|       0|       0.711|      
> 4.523
> RTD|       0.716|       1.072|       3.307|       0|       0.711|      
> 4.523
> RTD|       0.715|       1.066|       3.507|       0|       0.711|      
> 4.523
> ---|------------|------------|------------|--------|-------------------------
> RTS|       0.711|       1.071|       4.523|       0|    00:00:10/00:00:10
> 
> 
> The patch (2.6.20 x86_64) can be found here :
> http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-07-trem.patch
> 

s,1.7-07,1.0-07,

> I hope it could be used.
> 

Nice. Will use this work as the upcoming 2.6.20/x86_64 baseline in my
git repo. Thanks.

-- 
Philippe.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Adeos-main] port 2.6.19 x86_64 to 2.6.20
  2007-03-04 17:32       ` trem
  2007-03-07 23:31         ` Philippe Gerum
@ 2007-03-25 17:19         ` Philippe Gerum
  2007-03-30 10:16           ` Paul
  1 sibling, 1 reply; 8+ messages in thread
From: Philippe Gerum @ 2007-03-25 17:19 UTC (permalink / raw)
  To: trem; +Cc: adeos-main

On Sun, 2007-03-04 at 18:32 +0100, trem wrote:
> Hi
> 
> As I've got your start now, I've ported (at least tried) the 2.6.19
> x86_64 adeos patch to 2.6.20.
> I've tried it and it seems to works fine, here the latency :
> 
> [trem@domain.hid ~]$ cat latency_xenomai_2_6_20.txt
> [trem@domain.hid bin]$ sudo ./latency -T 10
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|       0.737|       1.067|       3.332|       0|       0.737|      
> 3.332
> RTD|       0.744|       1.067|       3.568|       0|       0.737|      
> 3.568
> RTD|       0.724|       1.080|       3.362|       0|       0.724|      
> 3.568
> RTD|       0.730|       1.070|       2.900|       0|       0.724|      
> 3.568
> RTD|       0.711|       1.071|       3.441|       0|       0.711|      
> 3.568
> RTD|       0.733|       1.066|       3.547|       0|       0.711|      
> 3.568
> RTD|       0.735|       1.079|       4.523|       0|       0.711|      
> 4.523
> RTD|       0.716|       1.072|       3.307|       0|       0.711|      
> 4.523
> RTD|       0.715|       1.066|       3.507|       0|       0.711|      
> 4.523
> ---|------------|------------|------------|--------|-------------------------
> RTS|       0.711|       1.071|       4.523|       0|    00:00:10/00:00:10
> 
> 
> The patch (2.6.20 x86_64) can be found here :
> http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-07-trem.patch
> 
> I hope it could be used.
> 

Merged, thanks. This upgrade is now available from the Adeos GIT repo
and Xenomai's SVN trunk.

> regards,
> trem
> 
> 
> Philippe Gerum wrote:
> > On Sat, 2007-03-03 at 23:24 +0100, trem wrote:
> >   
> >> Philippe Gerum wrote:
> >>     
> >>> On Mon, 2007-02-26 at 00:50 +0100, trem wrote:
> >>>   
> >>>       
> >>>> Hi
> >>>>
> >>>> I've tried to port the 2.6.19 x86_64 adeos patch to 2.6.20. you can find
> >>>> it here :
> >>>> http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-03-trem.patch
> >>>>     
> >>>>         
> >>> The good news is that moving to 2.6.20 does not seem to be too much of a
> >>> hell. Right?
> >>>
> >>>   
> >>>       
> >> Yes, there are few conflict so it's quite easy to port xenomai to 2.6.20.
> >>     
> >>>> I can apply it with with prepare_kernel.sh (from xenomai svn), but I haven't
> >>>> tested it yet (I mean run kernel).
> >>>>
> >>>> I hope this patch is good enough to be used. Otherwise, I'd be pleased
> >>>> to fix it (maybe with a bit of help).
> >>>>
> >>>>     
> >>>>         
> >>> We are hopefully close to have a reasonably good patch for 2.6.19. Once
> >>> we achieve this, porting to 2.6.20 should be the next step. Thanks.
> >>>
> >>>   
> >>>       
> >> I've seen ths in the Changelog : "this closes the implementation phase
> >> of the x86_64 port."
> >> So I suppose that the patch for 2.6.19 is finished. I've tried it and it
> >> works fine.
> >> The result of latency is :
> >>
> >> [trem@domain.hid bin]$ sudo ./latency -T 10
> >> == Sampling period: 100 us
> >> == Test mode: periodic user-mode task
> >> == All results in microseconds
> >> warming up...
> >> RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
> >> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> >> worst
> >> RTD|       0.760|       1.073|       3.660|       0|       0.760|      
> >> 3.660
> >> RTD|       0.737|       1.063|       3.012|       0|       0.737|      
> >> 3.660
> >> RTD|       0.741|       1.083|       3.396|       0|       0.737|      
> >> 3.660
> >> RTD|       0.755|       1.088|       2.344|       0|       0.737|      
> >> 3.660
> >> RTD|       0.754|       1.093|       3.431|       0|       0.737|      
> >> 3.660
> >> RTD|       0.755|       1.089|       5.119|       0|       0.737|      
> >> 5.119
> >> RTD|       0.724|       1.091|       3.126|       0|       0.724|      
> >> 5.119
> >> RTD|       0.762|       1.089|       3.171|       0|       0.724|      
> >> 5.119
> >> RTD|       0.751|       1.097|       5.508|       0|       0.724|      
> >> 5.508
> >> ---|------------|------------|------------|--------|-------------------------
> >> RTS|       0.724|       1.085|       5.508|       0|    00:00:10/00:00:10
> >>
> >> If I don't mistake, I see a max latency of 5us. Is it realistic ?
> >>
> >>     
> >
> > Yes. X-related problems Paul told us about being put aside (likely MTRR
> > issues, still to be chased), I see < 10 us under SMP test load on a 2 x
> > dual core Opteron 285 here (test load meaning two parallel kernel
> > compilations (-j5), and some significant network load).
> >
> > We still have to benchmark this port more exhaustively and aggressively
> > (e.g. different I/O loads and severe cache trashing, for longer than 8
> > hours), but the foundations look sane, especially since the
> > Xenomai/x86_64 port currently runs with a default latency calibration
> > set to 500 ns over this.
> >
> >   
> >> Now, the port to 2.6.20 is open ? we can work on ?
> >>
> >>     
> >
> > Yep. Have fun.
> >
> >   
> >> trem
> >>
> >>
> >>
> >>     
> 
> 
-- 
Philippe.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Adeos-main] port 2.6.19 x86_64 to 2.6.20
  2007-03-25 17:19         ` Philippe Gerum
@ 2007-03-30 10:16           ` Paul
  0 siblings, 0 replies; 8+ messages in thread
From: Paul @ 2007-03-30 10:16 UTC (permalink / raw)
  To: adeos-main, rpm

On Sunday 25 March 2007 18:19, Philippe Gerum wrote:
> > The patch (2.6.20 x86_64) can be found here :
> > http://zarb.org/~trem/adeos-ipipe-2.6.20-x86_64-1.7-07-trem.patch
> >
> > I hope it could be used.
>
> Merged, thanks. This upgrade is now available from the Adeos GIT repo
> and Xenomai's SVN trunk.

Attempting to compile against 2.6.20.4, hit a couple of minor snags.. Two 
includes in kernel/ipipe/tracer.c. linux/ipipe.h for __ipipe_pipeline and 
linux/sched.h for tasklist_lock - Also needed to insert an extern for cpu_khz 
in asm-x86_64/ipipe.h (no diffs available I'm afraid)..

It looks like the kernel developers are starting to clean up the rats nest of 
includes, so I suspect there are going to be more "undefined variable" errors 
cropping up in the future.


The 2.6.20.4 packages are available on http://zathras.tuxcnc.org/xenomai if 
anyone would like to test - Latest builds use r2340 trunk from SVN.


Regards, Paul.


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-03-30 10:16 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-02-25 23:50 [Adeos-main] port 2.6.19 x86_64 to 2.6.20 trem
2007-02-26  5:56 ` Philippe Gerum
2007-03-03 22:24   ` trem
2007-03-03 22:58     ` Philippe Gerum
2007-03-04 17:32       ` trem
2007-03-07 23:31         ` Philippe Gerum
2007-03-25 17:19         ` Philippe Gerum
2007-03-30 10:16           ` Paul

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.