On 11/08/2010 05:55 PM, Mathieu Desnoyers wrote:
* xufeng zhang ([email protected]) 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.
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
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
