Jim Cromie wrote:
> Philippe Gerum wrote:
>> Hi Jim,
>> On Sun, 2007-07-08 at 01:00 -0600, Jim Cromie wrote:
>>> Philippe Gerum wrote:
>>>> Our development trunk now contains the necessary support for running
>>>> Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
>>>> the generic clock event device abstraction that comes with newest
>>>> kernels. Other archs / kernel versions still work the older way, until
>>>> all archs eventually catch up with clockevents upstream.
>>>> This support won't be backported to 2.3.x, because it has some
>>>> significant impact on the nucleus. Tested as thoroughly as possible here
>>>> on low-end and mid-range x86 boxen, including SMP.
>>>> Please give this hell.
>>>> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
>>> Ive been running 22-rc7 on my Sony VAIO with this patch applied since 
>>> July 3,
>>> the only thing wrong Ive seen is that perl ( both bleed and maint )
>>> is failing its time related regression tests.
>>> ie
>>>     rsync -avz rsync://public.activestate.com/perl-current/ .
>>>     rsync -avz rsync://public.activestate.com/perl-5.8.x .
>>> Failed 3 tests out of 1429, 99.79% okay.
>>>         ../ext/Time/HiRes/t/HiRes.t
>>>         ../lib/Benchmark.t
>>>         op/time.t
>>> the lib/Benchmark.t test is hanging, and must be killed manually
>> Thanks for the feedback.
>> Does this happen with the I-pipe switched off too?
>> Also, is Xenomai patched in your kernel with any of the skins statically
>> enabled, or just the I-pipe?
> Im not sure what 'switched off' means, so heres the 'relevant' parts of 

There are a few stages of Xenomai/I-pipe support we usually test when
weird this come up:

1. Xenomai fully enabled and running (like you probably did)
2. Xenomai enabled, but no skin loaded (=> all skins must be modular)
3. Xenomai disabled in the .config, only I-pipe
4. I-pipe patched in but disabled (under "Processor types and features")
5. Vanilla kernel (but otherwise identical .config)

There is no strict order what to try first. It rather depends on
intuition and the compilation time you want to invest (fiddling with
CONFIG_IPIPE means full kernel rebuild).

> the .config
> Now that I look at it, Ive obviously not attended to the advice in 
> This config worked nicely with ntp, FWIW.
> Given that this is a laptop, Id like to keep ACPI and/or CPU-freq if 
> possible,

ACPI is OK (except ACPI_PROCESSOR), but CPU_FREQ is a no-go for Xenomai
unless you force the frequency governor into the fixed maximum
performance mode (which means at least temporary CPU_FREQ off).
Otherwise, Xenomai timing will by totally screwed up.

> but I'll try some combos to see if any work for both the battery,
> and for the perl tests.  I'll try a conservative/recommended config too.
> Any suggestions or test-requests are welcome.

First of all, it would be good to identify which stage of Xenomai
support (see above) breaks your test case. Then, as it seems to be some
timer issue, you could try to use kernel timer debugging features. E.g.
have a look /proc/timer_list. Is there your perl test stalled on some
timer, maybe with a silly expiry date? What does strace report if you
let your test run over it, ie. which syscall does not return?


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to