[ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace

[compudj@krystal.dyndns.org (Mathieu Desnoyers)]

* xufeng zhang (xufeng.zhang at windriver.com) wrote:
> On 11/08/2010 09:45 AM, Benjamin Poirier wrote:
>> On 05/11/10 02:24 AM, xufeng zhang wrote:
>>    
>>> Hi,
>>> I'm using ltt-control-0.86 and lttv-0.12.31 on ARM to trace the kernel,
>>> however,
>>>      
>> Hello,
>>
>> Which version of the kernel tracer patches are you using?
>>    
> I have query the developers who merged LTTng into kernel, they said  
> there is no incompatibility
> between LTTV and LTTng, so does there any other reasons which lead to  
> this error?
>
> Thanks,
> Xufeng Zhang
>> -Ben
>>
>>    
>>> I cannot view the trace after I have successfully generated, here is the
>>> error
>>> when I run 'lttv-gui -t trace1' command:
>>> ** Message: statistics viewer : background computation data ready.
>>>
>>> ** (lttv.real:6559): WARNING **: Cannot find pin_in in schedchange 671
>>>
>>> ** ERROR **: Kernel/LTTV event size differs for event
>>> udpv4_rcv_extended: kernel 32, LTTV 28

Please compare the /ltt/probes/net-extended-trace.c file from your
distro kernel tree to the:

lttng-modules package, file: /probes/net-extended-trace.c

Also compare the /ltt/ltt-type-serializer.h (or was it
include/linux/ltt-type-serializer.h ?) from your distro kernel with the
lttng-modules package:

/ltt-type-serializer.h

I remember having fixed this problem in the past months. Look closely at
the structure layout for "struct serialize_l214421224411111", "struct
serialize_l4412228" and "struct serialize_l4421224411111" vs the types
passed to the DEFINE_MARKER_TP() in net-extended-trace.c.

Thanks,

Mathieu


>>> aborting...
>>> /usr/local/bin/lttv-gui: line 10:  6559 Aborted
>>> $LTTV_CMD.real -m lttvwindow -m guievents -m guifilter -m guicontrolflow
>>> -m resourceview -m guistat
>>>
>>>
>>> And I found another people met the same problem on MIPS32, a patch have
>>> also been provided for MIPS32.
>>> Here is the similar code in ARM trace-clock.c:
>>> linux/arch/arm/mach-omap2/trace-clock.c line 537
>>> void get_trace_clock(void)
>>> {
>>>          spin_lock(&trace_clock_lock);
>>>          if (trace_clock_refcount++)
>>>                  goto end;
>>>          _start_trace_clock();
>>> end:
>>>          spin_unlock(&trace_clock_lock);
>>> }
>>> EXPORT_SYMBOL_GPL(get_trace_clock);
>>>
>>> void put_trace_clock(void)
>>> {
>>>          spin_lock(&trace_clock_lock);
>>>          WARN_ON(trace_clock_refcount<= 0);
>>>          if (trace_clock_refcount != 1)
>>>                  goto end;
>>>          _stop_trace_clock();
>>> end:
>>>          trace_clock_refcount--;
>>>          spin_unlock(&trace_clock_lock);
>>> }
>>> EXPORT_SYMBOL_GPL(put_trace_clock);
>>>
>>> Could anybody figure out what's wrong with the kernel code? Any
>>> suggestion would be appreciated.
>>>
>>>
>>> Thanks,
>>> Xufeng Zhang
>>>
>>>
>>> _______________________________________________
>>> ltt-dev mailing list
>>> ltt-dev at lists.casi.polymtl.ca
>>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>>      
>>    
>
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com