[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
Tue Nov 9 06:45:00 EST 2010
* xufeng zhang (xufeng.zhang at windriver.com) wrote:
> On 11/08/2010 05:55 PM, Mathieu Desnoyers wrote:
>> * 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.
>>
> I have compare my kernel tree to lttng-modules-0.19.2, there is no
> different
> in ltt-type-serializer.h file, and below is the diff info for
> net-extended-trace.c:
>
> --- net-extended-trace.c.kernel 2010-11-09 15:09:24.000000000 +0800
> +++ net-extended-trace.c 2010-11-09 15:12:47.000000000 +0800
> @@ -20,14 +20,15 @@
>
> #include <linux/in_route.h>
> #include <linux/ip.h>
> -#include <linux/ltt-type-serializer.h>
> #include <linux/module.h>
> #include <linux/tcp.h>
> #include <linux/udp.h>
> #include <net/route.h>
> #include <trace/net.h>
>
> -void probe_net_dev_xmit_extended(struct sk_buff *skb);
> +#include "../ltt-type-serializer.h"
> +
> +void probe_net_dev_xmit_extended(void *_data, struct sk_buff *skb);
>
> DEFINE_MARKER_TP(net, dev_xmit_extended, net_dev_xmit,
> probe_net_dev_xmit_extended, "skb 0x%lX network_protocol #n2u%hu "
> @@ -35,7 +36,7 @@
> "tot_len #n2u%hu ihl #1u%u source #n2u%hu dest #n2u%hu seq
> #n4u%lu "
> "ack_seq #n4u%lu doff #1u%u ack #1u%u rst #1u%u syn #1u%u fin
> #1u%u");
>
> -notrace void probe_net_dev_xmit_extended(struct sk_buff *skb)
> +notrace void probe_net_dev_xmit_extended(void *_data, struct sk_buff *skb)
> {
> struct marker *marker;
> struct serialize_l214421224411111 data;
> @@ -70,14 +71,14 @@
> &data, serialize_sizeof(data), sizeof(long));
> }
>
> -void probe_tcpv4_rcv_extended(struct sk_buff *skb);
> +void probe_tcpv4_rcv_extended(void *_data, struct sk_buff *skb);
>
> DEFINE_MARKER_TP(net, tcpv4_rcv_extended, net_tcpv4_rcv,
> probe_tcpv4_rcv_extended, "skb 0x%lX saddr #n4u%lu daddr #n4u%lu "
> "tot_len #n2u%hu ihl #1u%u source #n2u%hu dest #n2u%hu seq
> #n4u%lu "
> "ack_seq #n4u%lu doff #1u%u ack #1u%u rst #1u%u syn #1u%u fin
> #1u%u");
>
> -notrace void probe_tcpv4_rcv_extended(struct sk_buff *skb)
> +notrace void probe_tcpv4_rcv_extended(void *_data, struct sk_buff *skb)
> {
> struct marker *marker;
> struct serialize_l4421224411111 data;
> @@ -104,14 +105,14 @@
> &data, serialize_sizeof(data), sizeof(long));
> }
>
> -void probe_udpv4_rcv_extended(struct sk_buff *skb);
> +void probe_udpv4_rcv_extended(void *_data, struct sk_buff *skb);
>
> DEFINE_MARKER_TP(net, udpv4_rcv_extended, net_udpv4_rcv,
> probe_udpv4_rcv_extended, "skb 0x%lX saddr #n4u%lu daddr #n4u%lu "
> "unicast #1u%u ulen #n2u%hu source #n2u%hu dest #n2u%hu "
> "data_start #8u%lx");
>
> -notrace void probe_udpv4_rcv_extended(struct sk_buff *skb)
> +notrace void probe_udpv4_rcv_extended(void *_data, struct sk_buff *skb)
> {
> struct marker *marker;
> struct serialize_l4412228 data;
>
>
> I don't think the difference in net-extended-trace.c will make any impact.
> This problem has troubled me for weeks.
Can you try to reproduce with the latest LTTng version ? It's very hard
for us to help you if we don't know the LTTng version you are using,
especially for a bug I am aware to have fixed recently.
Also, you might simply try to unload the net-extended-trace module (or
disable its markers) to see if it helps getting a parseable trace.
Thanks,
Mathieu
>
> Thanks,
> Xufeng Zhang
>> 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