[ltt-dev] "Kernel/LTTV event size differs for event udpv4_rcv_extended: kernel 32, LTTV 28" error when view trace

[xufeng.zhang@windriver.com (xufeng zhang)]

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>