Re: [UPDATE] Linux Kernel Event Trace tool(LKET)

[Li Guanglei <guanglei at cn dot ibm dot com>]

William Cohen ??:
> I read through the LKET manpage this morning and tried out LKET with 
> providing ASCII output on a 32-bit i686 FC5 machine and a 64-bit x86_64 
> FC5 machine. 
> [...]
> It looks like there are some portability issues that need to be worked 
> out in the code. Things seemed to work better on the 64-bit platform 
> than on the 32-bit platform.
Today I used my thinkpad install with FC5/2.6.16.13, and found the 
same problems as you mentioned.

This is because that _stp_vsnprintf use va_arg() to get arguments and 
some arguments have wrong type in 32-bit applications. I fixed this in 
all current LKET tapsets and checked them into CVS.

I did a testing for all event hooks in ppc64/2.6.16.5 & i386/2.6.16.13 
for both ascii tracing(-D ASCII_TRACE) and binary tracing(with -bM and 
later use runtime/lket/b2a/lket-b2a to convert into ascii format), and 
most of the problems have gone, except the _switch_to & idle_balance 
which will be explained below.

> The tskdispatch didn't work on either machine. Couldn't find 
> kernel.function("__switch_to") on 64-bit and couldn't find 
> kernel.inline("idle_balance") on 32-bit

I don't have a x86_64 at hand. I tried __switch_to(scheduler.ctxswitch 
in src/tapset/schedule.stp) and it will cause kernel panic. I will 
take a further look at this and will open a bug for this if needed.

idle_balance is only available on SMP boxes. On single-cpu box, it 
will be commented out. I will try to find other replacements of 
idle_balance.

> Neither machine has scsi interface. When trying out the flagged errors 
> because no scsi modules.

I tested on my thinkpad since it has scsi device(SATA) and it works well.

> $ stap -D ASCII_TRACE -e "probe addevent.pagefault {}" -I 
> /usr/local/share/systemtap/tapset/LKET/
>
>
> The data on the 32-bit machine looked bogus (see below). lots of 
> negative references. Also would it make more sens to have the address 
> printed in hexidecimal for the ascii trace?
>
> 6|1|0|1148483972|626999|1848|1|1848|35705849838043136|1
> 6|1|0|1148483972|627050|1848|1|1848|-4615772671219597312|1
> 6|1|0|1148483974|465231|1324|1|1324|-5191788353242005504|1

For ascii tracing, I printed the pointer in %d, so this is why you see 
negtive values.

> $ stap -D ASCII_TRACE  -e "probe addevent.netdev.* {}" -I 
> /usr/local/share/systemtap/tapset/LKET/
>
> The netdev worked on 64-bit, but it failed compilation on 32-bit:
>
> cc1: warnings being treated as errors
> /tmp/stapBs84Hc/stap_15261.c: In function 'function_log_netdev_extra':
> /tmp/stapBs84Hc/stap_15261.c:434: warning: cast to pointer from integer 
> of different size

I've fixed this in CVS

> -Will