[ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace
Mathieu Desnoyers
compudj at krystal.dyndns.org
Mon Nov 8 04:55:45 EST 2010
* 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
More information about the lttng-dev
mailing list