[Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Philippe Gerum]

The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
the i386/x86_64 merge which just happened upstream, without having to
fiddle at the same time with the slew of other core changes which will
hit the street before 2.6.24 is released. You need the latest trunk/ to
configure Xenomai for this kernel properly, or at least update those two
files:

- scripts/prepare_kernel.sh
- ksrc/arch/i386/Kconfig.

Please check if this patch runs your x86 hw reasonably well, while I'm
busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
to have a unified x86* tree for Xenomai 2.4 which has to work with all
supported kernel releases, including 2.6.24. Yes, I know we are in -rc
phase, but such merge should mostly reshuffle the directory layout, and
not the implementation per se, otherwise, it will have to wait for 2.5.

At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
usable with a unified ia32/64 Xenomai support, which is basically what
we already have now on the powerpc side of the universe.

http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch

PS: slightly tested here. Looks ok, sun is still shining, birds are
still singing, hardware is not burning - yet.

-- 
Philippe.

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Philippe Gerum]

Philippe Gerum wrote:
> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
> the i386/x86_64 merge which just happened upstream, without having to
> fiddle at the same time with the slew of other core changes which will
> hit the street before 2.6.24 is released. You need the latest trunk/ to
> configure Xenomai for this kernel properly, or at least update those two
> files:
> 
> - scripts/prepare_kernel.sh
> - ksrc/arch/i386/Kconfig.
> 
> Please check if this patch runs your x86 hw reasonably well, while I'm
> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
> to have a unified x86* tree for Xenomai 2.4 which has to work with all
> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
> phase, but such merge should mostly reshuffle the directory layout, and
> not the implementation per se, otherwise, it will have to wait for 2.5.
> 
> At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
> we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
> leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
> usable with a unified ia32/64

i386/x86_64 I mean...

 Xenomai support, which is basically what
> we already have now on the powerpc side of the universe.
> 
> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
> 
> PS: slightly tested here. Looks ok, sun is still shining, birds are
> still singing, hardware is not burning - yet.
> 


-- 
Philippe.

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Jan Kiszka]

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

Philippe Gerum wrote:
> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
> the i386/x86_64 merge which just happened upstream, without having to
> fiddle at the same time with the slew of other core changes which will
> hit the street before 2.6.24 is released. You need the latest trunk/ to
> configure Xenomai for this kernel properly, or at least update those two
> files:
> 
> - scripts/prepare_kernel.sh
> - ksrc/arch/i386/Kconfig.
> 
> Please check if this patch runs your x86 hw reasonably well, while I'm
> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
> to have a unified x86* tree for Xenomai 2.4 which has to work with all
> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
> phase, but such merge should mostly reshuffle the directory layout, and
> not the implementation per se, otherwise, it will have to wait for 2.5.

[While building the new toy...] Hmm, I'm not a big fan of this schedule.
Unless we want to delay Xenomai 2.4 for even more months, we will not be
able to develop the unification against any stable kernel (the
unification is not yet done with 2.6.24-rc1!).

*IF* such an internal refactoring of Xenomai is actually that
straightforward, why not postpone it until some later 2.4 release? I
would rather prefer to role out something matured, also
build-system-wise, now instead of risking to generate new regressions.
But to make concreter: Do you plan to just create hal_32.c and hal_64.c,
or do you then also want to merge both into hal.c?

> 
> At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
> we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
> leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
> usable with a unified ia32/64 Xenomai support, which is basically what
> we already have now on the powerpc side of the universe.
> 
> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
> 
> PS: slightly tested here. Looks ok, sun is still shining, birds are
> still singing, hardware is not burning - yet.
> 

Will let you know the result from my box soon.

Jan


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

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Jan Kiszka]

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

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
>> the i386/x86_64 merge which just happened upstream, without having to
>> fiddle at the same time with the slew of other core changes which will
>> hit the street before 2.6.24 is released. You need the latest trunk/ to
>> configure Xenomai for this kernel properly, or at least update those two
>> files:
>>
>> - scripts/prepare_kernel.sh
>> - ksrc/arch/i386/Kconfig.
>>
>> Please check if this patch runs your x86 hw reasonably well, while I'm
>> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
>> to have a unified x86* tree for Xenomai 2.4 which has to work with all
>> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
>> phase, but such merge should mostly reshuffle the directory layout, and
>> not the implementation per se, otherwise, it will have to wait for 2.5.
> 
> [While building the new toy...] Hmm, I'm not a big fan of this schedule.
> Unless we want to delay Xenomai 2.4 for even more months, we will not be
> able to develop the unification against any stable kernel (the
> unification is not yet done with 2.6.24-rc1!).
> 
> *IF* such an internal refactoring of Xenomai is actually that
> straightforward, why not postpone it until some later 2.4 release? I
> would rather prefer to role out something matured, also
> build-system-wise, now instead of risking to generate new regressions.
> But to make concreter: Do you plan to just create hal_32.c and hal_64.c,
> or do you then also want to merge both into hal.c?
> 
>> At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
>> we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
>> leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
>> usable with a unified ia32/64 Xenomai support, which is basically what
>> we already have now on the powerpc side of the universe.
>>
>> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
>>
>> PS: slightly tested here. Looks ok, sun is still shining, birds are
>> still singing, hardware is not burning - yet.
>>
> 
> Will let you know the result from my box soon.

Appears to work fine here as well, including SMP. Just one oddity so
far: /sys/module/xeno_nucleus is missing, thus a way to tune module
parameters of the built-in nucleus. xeno_hal or xeno_native, e.g., are
there. Strange.

But beyond this, I really like 2.6.24 - my new notebook finally
generates sound with its built-in speakers! 8)

Jan


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

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Jan Kiszka]

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

Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
>>>
>>> PS: slightly tested here. Looks ok, sun is still shining, birds are
>>> still singing, hardware is not burning - yet.
>>>
>> Will let you know the result from my box soon.
> 
> Appears to work fine here as well, including SMP. Just one oddity so
> far: /sys/module/xeno_nucleus is missing, thus a way to tune module
> parameters of the built-in nucleus. xeno_hal or xeno_native, e.g., are
> there. Strange.

Mainline bug, fix is on the way:

http://lkml.org/lkml/2007/10/28/27

Jan


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

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
>> the i386/x86_64 merge which just happened upstream, without having to
>> fiddle at the same time with the slew of other core changes which will
>> hit the street before 2.6.24 is released. You need the latest trunk/ to
>> configure Xenomai for this kernel properly, or at least update those two
>> files:
>>
>> - scripts/prepare_kernel.sh
>> - ksrc/arch/i386/Kconfig.
>>
>> Please check if this patch runs your x86 hw reasonably well, while I'm
>> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
>> to have a unified x86* tree for Xenomai 2.4 which has to work with all
>> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
>> phase, but such merge should mostly reshuffle the directory layout, and
>> not the implementation per se, otherwise, it will have to wait for 2.5.
> 
> [While building the new toy...] Hmm, I'm not a big fan of this schedule.
> Unless we want to delay Xenomai 2.4 for even more months,

It usually takes about 2-4 weeks to port Xenomai to a new architecture,
so merging two existing ones on a per-file basis can't delay 2.4 for
months, really.

 we will not be
> able to develop the unification against any stable kernel (the
> unification is not yet done with 2.6.24-rc1!).
>

The unification on the Xenomai side does not depend at all on the one
ongoing upstream. The same way, we had the powerpc side unified for
32/64bit support long before the first I-pipe against the powerpc/ tree
was available, and this process is even still ongoing upstream right
now, long after its came to an end on our side. Conversely, a unified
Xenomai tree for x86 would still work with older kernels, so the fact
that 2.6.24 is being under development has no impact for us whatsoever.

> *IF* such an internal refactoring of Xenomai is actually that
> straightforward, why not postpone it until some later 2.4 release?

You don't want to change the build system in any significant way for
stable releases, because downstream projects may rely on the way it
works, or on the directory layout it processes. OTOH, it is still
acceptable during -rc. Since we can't push this change during the stable
cycle, and if we don't do it during the current -rc cycle either, then
we would have to wait for 2.5. Our major release cycle is ~6 months
long, even more in the 2.4 case, this would postpone our own unification
work until mid-2008.

Even if we could keep two separate trees for ages while upstream
provides only one, there is an opportunity to rationalize things right
now. If we can't do this at no significant cost, then we would wait for 2.5.
 I
> would rather prefer to role out something matured, also
> build-system-wise, now instead of risking to generate new regressions.
> But to make concreter: Do you plan to just create hal_32.c and hal_64.c,
> or do you then also want to merge both into hal.c?
>

I like the way upstream did this, and I intend to follow this path. The
point is about preparing the directory tree now, so that we may make
both implementations converge code-wise over time when it is sane and
applicable. This means hal_32/64 for now, until we decide whether having
a single HAL makes sense later. OTOH, there is no point in keeping
separate smi.c files. Again, the first step is about _preparation_,
which should pave the way for a deeper unification when it applies.
And this later work would be allowed to take place during the stable 2.4
series, since the framework would be already in place.

>> At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
>> we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
>> leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
>> usable with a unified ia32/64 Xenomai support, which is basically what
>> we already have now on the powerpc side of the universe.
>>
>> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
>>
>> PS: slightly tested here. Looks ok, sun is still shining, birds are
>> still singing, hardware is not burning - yet.
>>
> 
> Will let you know the result from my box soon.
> 
> Jan
> 


-- 
Philippe.

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
>>> the i386/x86_64 merge which just happened upstream, without having to
>>> fiddle at the same time with the slew of other core changes which will
>>> hit the street before 2.6.24 is released. You need the latest trunk/ to
>>> configure Xenomai for this kernel properly, or at least update those two
>>> files:
>>>
>>> - scripts/prepare_kernel.sh
>>> - ksrc/arch/i386/Kconfig.
>>>
>>> Please check if this patch runs your x86 hw reasonably well, while I'm
>>> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
>>> to have a unified x86* tree for Xenomai 2.4 which has to work with all
>>> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
>>> phase, but such merge should mostly reshuffle the directory layout, and
>>> not the implementation per se, otherwise, it will have to wait for 2.5.
>> [While building the new toy...] Hmm, I'm not a big fan of this schedule.
>> Unless we want to delay Xenomai 2.4 for even more months,
> 
> It usually takes about 2-4 weeks to port Xenomai to a new architecture,

(To port, but not to test and mature with the help of third parties.)

> so merging two existing ones on a per-file basis can't delay 2.4 for
> months, really.

Months when we want to sync with a stable unified kernel, likely weeks
if we just want to do the internal merge - again: including a reasonable
test cycle via the community.

> 
>  we will not be
>> able to develop the unification against any stable kernel (the
>> unification is not yet done with 2.6.24-rc1!).
>>
> 
> The unification on the Xenomai side does not depend at all on the one
> ongoing upstream. The same way, we had the powerpc side unified for
> 32/64bit support long before the first I-pipe against the powerpc/ tree
> was available, and this process is even still ongoing upstream right
> now, long after its came to an end on our side. Conversely, a unified
> Xenomai tree for x86 would still work with older kernels, so the fact
> that 2.6.24 is being under development has no impact for us whatsoever.

If it is decoupled from the kernel, then it doesn't matter when we
merge, thus also no need to hurry _now_.

> 
>> *IF* such an internal refactoring of Xenomai is actually that
>> straightforward, why not postpone it until some later 2.4 release?
> 
> You don't want to change the build system in any significant way for
> stable releases, because downstream projects may rely on the way it
> works, or on the directory layout it processes. OTOH, it is still
> acceptable during -rc. Since we can't push this change during the stable
> cycle, and if we don't do it during the current -rc cycle either, then
> we would have to wait for 2.5. Our major release cycle is ~6 months
> long, even more in the 2.4 case, this would postpone our own unification
> work until mid-2008.

Aren't those 6 months the actual problem?

> 
> Even if we could keep two separate trees for ages while upstream
> provides only one, there is an opportunity to rationalize things right
> now. If we can't do this at no significant cost, then we would wait for 2.5.
>  I
>> would rather prefer to role out something matured, also
>> build-system-wise, now instead of risking to generate new regressions.
>> But to make concreter: Do you plan to just create hal_32.c and hal_64.c,
>> or do you then also want to merge both into hal.c?
>>
> 
> I like the way upstream did this, and I intend to follow this path. The
> point is about preparing the directory tree now, so that we may make
> both implementations converge code-wise over time when it is sane and
> applicable. This means hal_32/64 for now, until we decide whether having
> a single HAL makes sense later. OTOH, there is no point in keeping
> separate smi.c files. Again, the first step is about _preparation_,
> which should pave the way for a deeper unification when it applies.
> And this later work would be allowed to take place during the stable 2.4
> series, since the framework would be already in place.

Even when focusing on infrastructure and really trivial merges, this
thing _will_ delay the 2.4 release by at least a 1-2 weeks. On the other
hand, there is still the broken blackfin arch...

Anyway, if you want to go this way, I will try to support the otherwise
very appreciated approach with testing and - when required - patching.

Jan


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

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
>>>> the i386/x86_64 merge which just happened upstream, without having to
>>>> fiddle at the same time with the slew of other core changes which will
>>>> hit the street before 2.6.24 is released. You need the latest trunk/ to
>>>> configure Xenomai for this kernel properly, or at least update those two
>>>> files:
>>>>
>>>> - scripts/prepare_kernel.sh
>>>> - ksrc/arch/i386/Kconfig.
>>>>
>>>> Please check if this patch runs your x86 hw reasonably well, while I'm
>>>> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
>>>> to have a unified x86* tree for Xenomai 2.4 which has to work with all
>>>> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
>>>> phase, but such merge should mostly reshuffle the directory layout, and
>>>> not the implementation per se, otherwise, it will have to wait for 2.5.
>>> [While building the new toy...] Hmm, I'm not a big fan of this schedule.
>>> Unless we want to delay Xenomai 2.4 for even more months,
>> It usually takes about 2-4 weeks to port Xenomai to a new architecture,
> 
> (To port, but not to test and mature with the help of third parties.)
>

It seems that your perception is the one of an ideal world, when asking
people to test -rc releases actually makes people download them and
hammer them badly: that's just not how it works right now for Xenomai,
at least.

Webalizer says this, not me:
http://stats.gna.org/download.gna.org/xenomai/

As a matter of fact, most people tend to start working with stable
releases directly. So the real point is: do we need this merge now? The
answer is yes, because as far as my evaluation is correct, the
cost/benefit ratio would be good for the x86* architectures, and since
we can't put such a change in any maintenance release, the only possible
solution is to push it now, or forget it until 2.5, which is far away.

The answer is a trade-off between the odds of long and painful
regressions and the benefit from making rather close codebases converge
as much as possible over time. My take is that we can do such
preparatory merge without sinking the boat.

>> so merging two existing ones on a per-file basis can't delay 2.4 for
>> months, really.
> 
> Months when we want to sync with a stable unified kernel, likely weeks
> if we just want to do the internal merge - again: including a reasonable
> test cycle via the community.
> 

Well, we must be talking about different merge approaches then, because
this evaluation is clearly off base when it comes to the undergoing
merge plan. If you suspect regressions of this kind, just don't do the
merge. But I don't suspect such long and painful regressions.

>>  we will not be
>>> able to develop the unification against any stable kernel (the
>>> unification is not yet done with 2.6.24-rc1!).
>>>
>> The unification on the Xenomai side does not depend at all on the one
>> ongoing upstream. The same way, we had the powerpc side unified for
>> 32/64bit support long before the first I-pipe against the powerpc/ tree
>> was available, and this process is even still ongoing upstream right
>> now, long after its came to an end on our side. Conversely, a unified
>> Xenomai tree for x86 would still work with older kernels, so the fact
>> that 2.6.24 is being under development has no impact for us whatsoever.
> 
> If it is decoupled from the kernel, then it doesn't matter when we
> merge, thus also no need to hurry _now_.

Taking the opportunity to have the baseline in shape as soon as
possible, so that we are able to build over it later on, at our own
pace, is anything but rushing in a brainless way.

> 
>>> *IF* such an internal refactoring of Xenomai is actually that
>>> straightforward, why not postpone it until some later 2.4 release?
>> You don't want to change the build system in any significant way for
>> stable releases, because downstream projects may rely on the way it
>> works, or on the directory layout it processes. OTOH, it is still
>> acceptable during -rc. Since we can't push this change during the stable
>> cycle, and if we don't do it during the current -rc cycle either, then
>> we would have to wait for 2.5. Our major release cycle is ~6 months
>> long, even more in the 2.4 case, this would postpone our own unification
>> work until mid-2008.
> 
> Aren't those 6 months the actual problem?
> 

I'd like a 4 months cycle actually, but I'm no wizard. 6 months is
currently the time needed to converge with the resources at hand.

>> Even if we could keep two separate trees for ages while upstream
>> provides only one, there is an opportunity to rationalize things right
>> now. If we can't do this at no significant cost, then we would wait for 2.5.
>>  I
>>> would rather prefer to role out something matured, also
>>> build-system-wise, now instead of risking to generate new regressions.
>>> But to make concreter: Do you plan to just create hal_32.c and hal_64.c,
>>> or do you then also want to merge both into hal.c?
>>>
>> I like the way upstream did this, and I intend to follow this path. The
>> point is about preparing the directory tree now, so that we may make
>> both implementations converge code-wise over time when it is sane and
>> applicable. This means hal_32/64 for now, until we decide whether having
>> a single HAL makes sense later. OTOH, there is no point in keeping
>> separate smi.c files. Again, the first step is about _preparation_,
>> which should pave the way for a deeper unification when it applies.
>> And this later work would be allowed to take place during the stable 2.4
>> series, since the framework would be already in place.
> 
> Even when focusing on infrastructure and really trivial merges, this
> thing _will_ delay the 2.4 release by at least a 1-2 weeks.

Again, I think you are off base here. This thing is likely going to
trigger frenetic tests among x86* users reading this list who happen to
rely on 2.4 already, and we should not see any earthquake following
this. Since you are among those users, well, I have no doubt that you'll
make your best to prove me wrong for that move and test even more
frenetically...

 On the other
> hand, there is still the broken blackfin arch...

And the x86_64 too - just enable AUDIT_SYSCALL. And we need the ARM
upgrade too.
label:
And we can't ask people to give more than they have when it comes to
help the project.

Making trade-offs is part of my job, and this time, the (complex,
believe me) Blackfin bug has been postponed after the x86 merge because
the latter should be closed reasonably fast, which does not mean that
the Blackfin issue is not going to be addressed. goto label.

> 
> Anyway, if you want to go this way, I will try to support the otherwise
> very appreciated approach with testing and - when required - patching.
>

Good. Actually, the merge is done. I'm compiling and running in loop
since this morning on all the platforms I have at hand. When I'm sure
than no trivial showstopper remains hidden, I'll commit the merge in one
go, and -rc6 will only consist of that big change, this way, things
would be easy to revert, if need be.

> Jan
> 


-- 
Philippe.

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>  On the other
>> hand, there is still the broken blackfin arch...
> 
> And the x86_64 too - just enable AUDIT_SYSCALL. And we need the ARM
> upgrade too.

Can't follow you regarding CONFIG_AUDIT_SYSCALL. What else is required
beyond simply enabling this .config switch? And is this tracing then
only a x86_64 issue?

Jan


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

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>  On the other
>>> hand, there is still the broken blackfin arch...
>> And the x86_64 too - just enable AUDIT_SYSCALL. And we need the ARM
>> upgrade too.
> 
> Can't follow you regarding CONFIG_AUDIT_SYSCALL. What else is required
> beyond simply enabling this .config switch? And is this tracing then
> only a x86_64 issue?
> 

On at least two x86_64 boxes, arming this switch either causes a lockup
at boot, or generates random segmentation violations when running the
latency test. This is not a tracing issue -- the register set looks like
being randomly trashed on the return path enabled by this option.

-- 
Philippe.

Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come

[Gilles Chanteperdrix]

On 10/29/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> Philippe Gerum wrote:
> > Jan Kiszka wrote:
> >  On the other
> >> hand, there is still the broken blackfin arch...
> >
> > And the x86_64 too - just enable AUDIT_SYSCALL. And we need the ARM
> > upgrade too.
>
> Can't follow you regarding CONFIG_AUDIT_SYSCALL. What else is required
> beyond simply enabling this .config switch? And is this tracing then
> only a x86_64 issue?

You need to install selinux packages. I have the problem with the
following packages installed on a fedora core:

libselinux-1.23.11-1.1
libselinux-1.23.11-1.1
libselinux-devel-1.23.11-1.1
selinux-policy-targeted-1.27.1-2.28

-- 
                                               Gilles Chanteperdrix