Julien Heyman wrote:
> Hi,
> 
> On Thursday 20 July 2006 23:58, Jan Kiszka wrote:
>> Julien Heyman wrote:
>>> Hi,
>>>
>>> I am currently trying to evaluate Xenomai, and my current setup is :
>>> VIA C3 533Mhz processor, Kubuntu 6.06 Linux distribution.
>>> I am using Xenomai-2.1.0 over a 2.6.17.4 kernel.
>> General advice: especially when starting new, try to pick the latest
>> version, at least the latest from the preferred series (here 2.1.2). But
>> 2.2 is even better. :)
>>
> 
> OK. Actually started with Xenomai-2.1.0 then switched to 2.1.1 to fix a kernel 
> build error. But anyway, I will start with a fresh install of 2.2 as soon as 
> I have figured out the other points :)
> 
>>> When I run the latency part of the testsuite (in a console under KDE), I
>>> get
>>> results that I cannot understand, so I probably did something wrong
>>> (execution trace included below).
>>> I get reasonable values during the first seconds, then all of a sudden
>>> latencies begin to rise, continuously, to very large values.
>>> - I did check that DMA transfer is activated on my HD.
>>> - I did select "Enable SMI workaround" + "Globally disable SMI" in the
>>> Xenomai
>>> options while configuring the kernel.
>>> - I have disabled power management at BIOS level and disabled ACPI
>>> support and
>>> CPU frequency scaling during kernel configuration.
>>> - I checked that I don't have anything called "legacy USB" in my BIOS. I
>>> do have an "OnChip USB" option enable in the BIOS though.
>>>
>>> Any advice would be appreciated !
>> Maybe it's related to some other weird on-chip hardware. At work we run
>> Xenomai only on a head-less VIA C3 box, i.e. without X. No problems so
>> far. I would suggest to try stopping X and run the test from the text mode.
> 
> This is interesting : indeed when I switch to console mode (Ctrl+Atl+F1) and 
> run the test, the latency values stay right on track.
> If I let the test run, switch to X, and switch back to the original console, 
> the values have gone wild in the meantime.
> So there seems to be a strong link with X. 
> What does that say about potential causes of my issue ?

Don't know. Might be a weird hardware design (wrt bus latencies) - or do
you use any binary-only driver for X?

> 
>> A further tool to analyse such effects in details is the I-pipe tracer.
>> It's an additional patch you have to apply to your kernel (see
>> http://download.gna.org/adeos/patches/v2.6/i386/tracer). Enable this
>> I-pipe option, rebuild your kernel, and start the latency test with -f.
>> The test will then capture on every new worst-case delay a backtrace to
>> /proc/ipipe/trace/frozen. You may want to play with the number of
>> back-trace points or the verbose mode (see /proc/ipipe/trace/*) even
>> after the capturing.
>>
> 
> I had already used an adeos patch during my initial kernel-patching
> (adeos-ipipe-2.6.17-i386-1.3-07.patch)

The tracer is an additional patch on top of I-pipe, see link above.

> I tried running the latency test using /usr/xenomai/bin/xeno-load latency -f
> but I get this error :
> 
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> latency: failed to open benchmark device, code -19
> (modprobe xeno_timerbench?)
> 
> What am I doing wrong ?

For < 2.2: check if CONFIG_XENO_DRIVERS_TIMERBENCH is y or m. If it's a
module, follow the suggestion latency printed.

In 2.2 the required tracing interface was moved to the nucleus, no need
for these steps then.

Jan