Re: [Xenomai-core] x86_64 - Initial results.

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Paul wrote:
> On Sunday 25 February 2007 16:03, Jan Kiszka wrote:
>>>  The attached trace logs provide little information - Also included dmesg
>> One more try please: we also need CONFIG_IPIPE_TRACE_MCOUNT.
> 
> With both CONFIG_IPIPE_TRACE_MCOUNT and CONFIG_IPIPE_TRACE_VMALLOC enabled, 
> the system auto-reboots as soon as the kernel starts to uncompress. Disabling 
> the latter restores normal service.

Are we still tracing too early during boot? Probably worth a qemu/gdb
session.

> 
> On Sunday 25 February 2007 16:09, Gilles Chanteperdrix wrote:
>> Option "NoAccel"
> 
> Results are still the same - Latency goes to pot and hangs as soon as X starts 
> up. Quite likely the offending trace isn't getting logged..
> 
> 

...

> ------------------------------------------------------------------------
> 
> I-pipe frozen back-tracing service on 2.6.19.3-xenomai/ipipe-1.0-04
> ------------------------------------------------------------
> Freeze: 434598593698 cycles, Trace Points: 30 (+100)
> Calibrated minimum trace-point overhead: 0.037 us
> 
>  +----- Hard IRQs ('|': locked)
>  |+---- <unused>
>  ||+--- <unused>
>  |||+-- Xenomai
>  ||||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
>  |||||                        +---------- Delay flag ('+': > 1 us, '!': > 10 us)
>  |||||                        |        +- NMI noise ('N')
>  |||||                        |        |
>       Type    User Val.   Time    Delay  Function (Parent)
> :|  +*func                -244+   6.981  __ipipe_handle_irq+0x21 (common_interrupt+0x78)
> :|  +*func                -238+   6.956  __ipipe_ack_apic+0x9 (__ipipe_handle_irq+0x87)
> :|  +*func                -231+   7.615  __ipipe_dispatch_wired+0xc (__ipipe_handle_irq+0x91)
> :|  #*func                -223+   6.951  xnintr_clock_handler+0x9 (__ipipe_dispatch_wired+0x94)
> :|  #*func                -216+   7.210  xnintr_irq_handler+0x21 (xnintr_clock_handler+0x1b)

Given these *huge* latencies for that simple functions, we are may face
some CPU frequency screw (though scaling is switched off?). Something
must disturb the tsc->ns conversion. Maybe this is actually no latency
real issue...

Jan


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