This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: SYSTEMTAP TEST RESULTS : Kernel version 2.6.35-rc3 on POWER ppc64 architecture.
On 06/24/2010 02:10 AM, Divya Vikas wrote:
> Please find the o/p of the commands below
>> FAIL: buildok/nfsd-detailed.stp
>
> nfsd-detailed.stp fails because we can't find the $filp argument of used
> by nfsd.close (which ends up as either kernel.function("nfsd_close") or
> module("nfsd").function("nfsd_close")).
>
> Could you run the following command and show me the output: stap -L
> nfsd.close
>
> semantic error: not accessible at this address (0x95a84): identifier
> '$filp' at /usr/local/share/systemtap/tapset/nfsd.stp:1046:29
> source: filename = __file_filename($filp)
> ^
> semantic error: not accessible at this address (0x95b84): identifier
> '$filp' at :1046:29
> source: filename = __file_filename($filp)
> ^
> semantic error: not accessible at this address (0x95ca0): identifier
> '$filp' at :1046:29
> source: filename = __file_filename($filp)
> ^
> semantic error: not accessible at this address (0x95dac): identifier
> '$filp' at :1046:29
> source: filename = __file_filename($filp)
> ^
> nfsd.close client_ip:string filename:string name:string argstr:string
Yep, filp is definitely gone there. I've checked, and Linus' latest
kernel tree still has the definition of nfsd_close() taking a $filp
argument.
Your compiler isn't generating great quality debuginfo.
>> FAIL: buildok/process_test.stp
>
> process_test.stp fails because we can't find
> 'kernel.function("handle_signal")', which is odd. Can you run the
> following command and show me the output:
>
> stap -L 'kernel.function("handle_signal").*'
>
> p55alp2:/home/linux-2.6.35-rc3 # stap -L 'kernel.function
> ("handle_signal").*'
> p55alp2:/home/linux-2.6.35-rc3 #
OK, after some poking around in Linus' latest tree, I see there has been
some rearrangement in the powerpc code. Specifically, handle_signal()
is gone, and instead there is this code in
arch/powerpc/kernel/signal.c(do_signal_pending):
if (is32) {
if (ka.sa.sa_flags & SA_SIGINFO)
ret = handle_rt_signal32(signr, &ka, &info, oldset,
regs);
else
ret = handle_signal32(signr, &ka, &info, oldset,
regs);
} else {
ret = handle_rt_signal64(signr, &ka, &info, oldset, regs);
}
So, for ppc, it looks like we'll need to handle all 3 of the above
functions.
I just filed PR11752 against this issue.
>> FAIL: buildok/scsi.stp
>
> scsi.stp fails because we can't find the $cmd arg of scsi.iodone (which
> is really either
> module("scsi_mod").function("scsi_done@drivers/scsi/scsi.c") or
> kernel.function("scsi_done@drivers/scsi/scsi.c")).
>
> Could you run the following command and show me the output: stap -L
> scsi.iodone
... errors deleted ...
> scsi.iodone device_state:long device_state_str:string data_direction:long
> data_direction_str:string scsi_timer_pending:long
This one looks like another debuginfo problem.
>> FAIL: buildok/signal-all-probes.stp
>
> process_test.stp fails because we can't find
> 'kernel.function("handle_signal")'
That's PR11752 again.
>> FAIL: buildok/syscall.stp
>
> This one is failing in syscall.pipe.
>
> Could you run the following command and show me the output: stap -L
> syscall.pipe
>
> semantic error: invalid access '[0]' vs. long int: operator '['
> at /usr/local/share/systemtap/tapset/syscalls2.stp:312:29
> source: pipe0 = user_int(&$fildes[0]);
> ^
> semantic error: invalid access '[1]' vs. long int: operator '[' at :313:29
> source: pipe1 = user_int(&$fildes[1]);
> ^
> syscall.pipe flags:long flag_str:string name:string fildes_uaddr:long
> pipe0:long pipe1:long argstr:string $fildes:long int $flags:long int
That one is weird. Systemtap thinks that '$fildes' is a 'long int', not
a 'long int *'. From looking at the current kernel source it appears
that $fildes is still a pointer. I got access to a f12 ppc64 machine
(running 2.6.32.12-115.fc12.ppc64) and it shows the same problems:
# stap -L 'kernel.function("sys_pipe").call'
kernel.function("SyS_pipe@fs/pipe.c:1117").call $fildes:long int
# stap -L 'kernel.function("sys_pipe2").call'
kernel.function("SyS_pipe2@fs/pipe.c:1101").call $fildes:long int
$flags:long int
Mark, do you have any ideas here?
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)