* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace
@ 2010-11-05 6:24 xufeng zhang
2010-11-08 1:45 ` Benjamin Poirier
0 siblings, 1 reply; 15+ messages in thread
From: xufeng zhang @ 2010-11-05 6:24 UTC (permalink / raw)
Hi,
I'm using ltt-control-0.86 and lttv-0.12.31 on ARM to trace the kernel,
however,
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
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-05 6:24 [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace xufeng zhang @ 2010-11-08 1:45 ` Benjamin Poirier 2010-11-08 1:58 ` xufeng zhang 2010-11-08 5:20 ` xufeng zhang 0 siblings, 2 replies; 15+ messages in thread From: Benjamin Poirier @ 2010-11-08 1:45 UTC (permalink / raw) 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? -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 > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-08 1:45 ` Benjamin Poirier @ 2010-11-08 1:58 ` xufeng zhang 2010-11-08 5:20 ` xufeng zhang 1 sibling, 0 replies; 15+ messages in thread From: xufeng zhang @ 2010-11-08 1:58 UTC (permalink / raw) 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? > We are using linux-kernel-2.6.34, but I can't figure out which version of LTTpng we are using. 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 >> 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 >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-08 1:45 ` Benjamin Poirier 2010-11-08 1:58 ` xufeng zhang @ 2010-11-08 5:20 ` xufeng zhang 2010-11-08 9:55 ` Mathieu Desnoyers [not found] ` <AANLkTimgLAWUwF2jhH6R=2JUZW8C9PYGN1dzSzZ9Wws7@mail.gmail.com> 1 sibling, 2 replies; 15+ messages in thread From: xufeng zhang @ 2010-11-08 5:20 UTC (permalink / raw) 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 >> 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 >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-08 5:20 ` xufeng zhang @ 2010-11-08 9:55 ` Mathieu Desnoyers 2010-11-09 7:29 ` xufeng zhang [not found] ` <AANLkTimgLAWUwF2jhH6R=2JUZW8C9PYGN1dzSzZ9Wws7@mail.gmail.com> 1 sibling, 1 reply; 15+ messages in thread From: Mathieu Desnoyers @ 2010-11-08 9:55 UTC (permalink / raw) * 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-08 9:55 ` Mathieu Desnoyers @ 2010-11-09 7:29 ` xufeng zhang 2010-11-09 11:45 ` Mathieu Desnoyers 0 siblings, 1 reply; 15+ messages in thread From: xufeng zhang @ 2010-11-09 7:29 UTC (permalink / raw) 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. 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 >> >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-09 7:29 ` xufeng zhang @ 2010-11-09 11:45 ` Mathieu Desnoyers 2010-11-09 11:57 ` Mathieu Desnoyers 0 siblings, 1 reply; 15+ messages in thread From: Mathieu Desnoyers @ 2010-11-09 11:45 UTC (permalink / raw) * 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-09 11:45 ` Mathieu Desnoyers @ 2010-11-09 11:57 ` Mathieu Desnoyers 2010-11-10 7:14 ` xufeng zhang 2010-11-10 7:19 ` xufeng zhang 0 siblings, 2 replies; 15+ messages in thread From: Mathieu Desnoyers @ 2010-11-09 11:57 UTC (permalink / raw) * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote: > * 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. 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. Check the diff of your include/linux/ltt-core.h ltt_align() function between a recent lttng and yours. 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 > >>>>> 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 > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-09 11:57 ` Mathieu Desnoyers @ 2010-11-10 7:14 ` xufeng zhang 2010-11-10 7:19 ` xufeng zhang 1 sibling, 0 replies; 15+ messages in thread From: xufeng zhang @ 2010-11-10 7:14 UTC (permalink / raw) On 11/09/2010 07:57 PM, Mathieu Desnoyers wrote: > * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote: > >> * 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. >> > 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 (mathieu.desnoyers at polymtl.ca) + * Copyright (C) 2005-2010 Mathieu Desnoyers (mathieu.desnoyers at efficios.com) * * 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 >>>>>>> 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 >> >> _______________________________________________ >> ltt-dev mailing list >> ltt-dev at lists.casi.polymtl.ca >> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev >> >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-09 11:57 ` Mathieu Desnoyers 2010-11-10 7:14 ` xufeng zhang @ 2010-11-10 7:19 ` xufeng zhang 2010-11-10 14:08 ` Mathieu Desnoyers 1 sibling, 1 reply; 15+ messages in thread From: xufeng zhang @ 2010-11-10 7:19 UTC (permalink / raw) On 11/09/2010 07:57 PM, Mathieu Desnoyers wrote: > * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote: > >> * 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. >> > 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. > > Check the diff of your include/linux/ltt-core.h ltt_align() function > between a recent lttng and yours. > Could you provide the content of this patch, I think my problem is almost the same. Thank you very much. Thanks, Xufeng Zhang > 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 >>>>>>> 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 >> >> _______________________________________________ >> ltt-dev mailing list >> ltt-dev at lists.casi.polymtl.ca >> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev >> >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-10 7:19 ` xufeng zhang @ 2010-11-10 14:08 ` Mathieu Desnoyers 2010-11-10 15:14 ` Mathieu Desnoyers 0 siblings, 1 reply; 15+ messages in thread From: Mathieu Desnoyers @ 2010-11-10 14:08 UTC (permalink / raw) * xufeng zhang (xufeng.zhang at windriver.com) wrote: > On 11/09/2010 07:57 PM, Mathieu Desnoyers wrote: >> * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote: >> >>> * 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. >>> >> 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. >> >> Check the diff of your include/linux/ltt-core.h ltt_align() function >> between a recent lttng and yours. >> > Could you provide the content of this patch, I think my problem > is almost the same. Thank you very much. Then you may be facing the following problem: your kernel LTTng version is too recent for your LTTV version. I had to change both LTTV and LTTng at the same time to support this different alignment style. So your LTTV is very probably incompatible with the LTTng version you are using. Mathieu > > Thanks, > Xufeng Zhang >> 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 >>>>>>>> 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 >>> >>> _______________________________________________ >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-10 14:08 ` Mathieu Desnoyers @ 2010-11-10 15:14 ` Mathieu Desnoyers 0 siblings, 0 replies; 15+ messages in thread From: Mathieu Desnoyers @ 2010-11-10 15:14 UTC (permalink / raw) * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote: > * xufeng zhang (xufeng.zhang at windriver.com) wrote: > > On 11/09/2010 07:57 PM, Mathieu Desnoyers wrote: > >> * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote: > >> > >>> * 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. > >>> > >> 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. > >> > >> Check the diff of your include/linux/ltt-core.h ltt_align() function > >> between a recent lttng and yours. > >> > > Could you provide the content of this patch, I think my problem > > is almost the same. Thank you very much. > > Then you may be facing the following problem: your kernel LTTng version > is too recent for your LTTV version. I had to change both LTTV and LTTng > at the same time to support this different alignment style. > > So your LTTV is very probably incompatible with the LTTng version you > are using. Please compare yout "ltt_align" macro in lttv : ltt/ltt-private.h between a more recent (and also older) lttv and yours. Thanks, Mathieu > > Mathieu > > > > > Thanks, > > Xufeng Zhang > >> 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 > >>>>>>>> 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 > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <AANLkTimgLAWUwF2jhH6R=2JUZW8C9PYGN1dzSzZ9Wws7@mail.gmail.com>]
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace [not found] ` <AANLkTimgLAWUwF2jhH6R=2JUZW8C9PYGN1dzSzZ9Wws7@mail.gmail.com> @ 2010-11-09 7:03 ` xufeng zhang 2010-11-09 7:03 ` xufeng zhang 2010-11-09 7:03 ` xufeng zhang 0 siblings, 2 replies; 15+ messages in thread From: xufeng zhang @ 2010-11-09 7:03 UTC (permalink / raw) On 11/08/2010 08:51 PM, Rob Woolley wrote: > Hi Xufeng, > > Are you using our kernel? No, I'm using the mainline kernel. Thanks, Xufeng Zhang > > If so, you may wish to contact the Linux Production Division kernel > team for help before going to LKML. > > Best regards, > Rob > > On Mon, Nov 8, 2010 at 12:20 AM, xufeng zhang > <xufeng.zhang at windriver.com <mailto: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 > 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 > <mailto: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 <mailto:ltt-dev at lists.casi.polymtl.ca> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20101109/9ec01beb/attachment.htm> ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-09 7:03 ` xufeng zhang @ 2010-11-09 7:03 ` xufeng zhang 2010-11-09 7:03 ` xufeng zhang 1 sibling, 0 replies; 15+ messages in thread From: xufeng zhang @ 2010-11-09 7:03 UTC (permalink / raw) On 11/08/2010 08:51 PM, Rob Woolley wrote: > Hi Xufeng, > > Are you using our kernel? No, I'm using the mainline kernel. Thanks, Xufeng Zhang > > If so, you may wish to contact the Linux Production Division kernel > team for help before going to LKML. > > Best regards, > Rob > > On Mon, Nov 8, 2010 at 12:20 AM, xufeng zhang > <xufeng.zhang at windriver.com <mailto: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 > 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 > <mailto: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 <mailto:ltt-dev at lists.casi.polymtl.ca> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20101109/9ec01beb/attachment-0002.htm> ^ permalink raw reply [flat|nested] 15+ messages in thread
* [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace 2010-11-09 7:03 ` xufeng zhang 2010-11-09 7:03 ` xufeng zhang @ 2010-11-09 7:03 ` xufeng zhang 1 sibling, 0 replies; 15+ messages in thread From: xufeng zhang @ 2010-11-09 7:03 UTC (permalink / raw) On 11/08/2010 08:51 PM, Rob Woolley wrote: > Hi Xufeng, > > Are you using our kernel? No, I'm using the mainline kernel. Thanks, Xufeng Zhang > > If so, you may wish to contact the Linux Production Division kernel > team for help before going to LKML. > > Best regards, > Rob > > On Mon, Nov 8, 2010 at 12:20 AM, xufeng zhang > <xufeng.zhang at windriver.com <mailto: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 > 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 > <mailto: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 <mailto:ltt-dev at lists.casi.polymtl.ca> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20101109/9ec01beb/attachment-0003.htm> ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-11-10 15:14 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-05 6:24 [ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace xufeng zhang
2010-11-08 1:45 ` Benjamin Poirier
2010-11-08 1:58 ` xufeng zhang
2010-11-08 5:20 ` xufeng zhang
2010-11-08 9:55 ` Mathieu Desnoyers
2010-11-09 7:29 ` xufeng zhang
2010-11-09 11:45 ` Mathieu Desnoyers
2010-11-09 11:57 ` Mathieu Desnoyers
2010-11-10 7:14 ` xufeng zhang
2010-11-10 7:19 ` xufeng zhang
2010-11-10 14:08 ` Mathieu Desnoyers
2010-11-10 15:14 ` Mathieu Desnoyers
[not found] ` <AANLkTimgLAWUwF2jhH6R=2JUZW8C9PYGN1dzSzZ9Wws7@mail.gmail.com>
2010-11-09 7:03 ` xufeng zhang
2010-11-09 7:03 ` xufeng zhang
2010-11-09 7:03 ` xufeng zhang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox