On 11/09/2010 07:57 PM, Mathieu Desnoyers wrote:
* Mathieu Desnoyers ([email protected]) wrote:
* xufeng zhang ([email protected]) wrote:
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.
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.
Ah, I remember it now. It had something to do with alignment of 64-bit
fields on 32-bit machines. Older LTTng versions did align these fields
on the next 64-bit multiple. New LTTng versions do the same as gcc and
align these on the next 32-bit boundary.
It make good sense, if align to 4-bytes, then the size of struct
serialize_l4412228
will be 28, same as LTTV.
Check the diff of your include/linux/ltt-core.h ltt_align() function
between a recent lttng and yours.
I diff my kernel ltt-core.h with patch-2.6.36-lttng-0.239, and found no
different in
ltt_align() function.
--- ltt-core.h.kernel 2010-11-10 15:08:20.000000000 +0800
+++ ltt-core.h 2010-11-10 15:07:19.000000000 +0800
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2005,2006 Mathieu Desnoyers ([email protected])
+ * Copyright (C) 2005-2010 Mathieu Desnoyers
([email protected])
*
* This contains the core definitions for the Linux Trace Toolkit.
*
@@ -9,44 +9,10 @@
#ifndef LTT_CORE_H
#define LTT_CORE_H
-#include <linux/list.h>
-#include <linux/percpu.h>
-
-/* ltt's root dir in debugfs */
-#define LTT_ROOT "ltt"
-
-/*
- * All modifications of ltt_traces must be done by ltt-tracer.c, while
holding
- * the semaphore. Only reading of this information can be done
elsewhere, with
- * the RCU mechanism : the preemption must be disabled while reading the
- * list.
- */
-struct ltt_traces {
- struct list_head setup_head; /* Pre-allocated traces list */
- struct list_head head; /* Allocated Traces list */
- unsigned int num_active_traces; /* Number of active traces */
-} ____cacheline_aligned;
-
-extern struct ltt_traces ltt_traces;
-
-/*
- * get dentry of ltt's root dir
- */
-struct dentry *get_ltt_root(void);
-
-void put_ltt_root(void);
-
/* Keep track of trap nesting inside LTT */
DECLARE_PER_CPU(unsigned int, ltt_nesting);
-typedef int (*ltt_run_filter_functor)(void *trace, uint16_t eID);
-
-extern ltt_run_filter_functor ltt_run_filter;
-
-extern void ltt_filter_register(ltt_run_filter_functor func);
-extern void ltt_filter_unregister(void);
-
-#if defined(CONFIG_LTT) && defined(CONFIG_LTT_ALIGNMENT)
+#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
/*
* Calculate the offset needed to align the type.
@@ -87,6 +53,6 @@
return 0;
}
-#endif /* defined(CONFIG_LTT) && defined(CONFIG_LTT_ALIGNMENT) */
+#endif /* HAVE_EFFICIENT_UNALIGNED_ACCESS */
#endif /* LTT_CORE_H *
Thanks,
Mathieu
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
[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
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
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
