* Systemtap results on power64 box against kernel version 2.6.35-rc4-git5
@ 2010-07-13 13:40 divya
2010-07-13 14:53 ` David Smith
0 siblings, 1 reply; 5+ messages in thread
From: divya @ 2010-07-13 13:40 UTC (permalink / raw)
To: systemtap, dejazilla; +Cc: sachinp
Hi Everyone,
Here is the result of systemtap snap test on kernel 2.6.35-rc4-git5
Arch - ppc64
elfutils version - 0.148
FAIL: systemtap.base/add.stp shutdown (eof)
FAIL: systemtap.base/alias-condition.stp shutdown (eof)
FAIL: backtrace (0 0)
FAIL: debugpath-good (eof)
FAIL: gtod (0)
FAIL: prologues -P
FAIL: warnings (0)
FAIL: backtrace of yyy_func2 (0)
FAIL: print_stack of yyy_func2 (0)
FAIL: backtrace of yyy_func3 (0)
FAIL: print_stack of yyy_func3 (0)
FAIL: backtrace of yyy_func4 (0)
FAIL: print_stack of yyy_func4 (0)
FAIL: print_stack didn't find systemtap_test_module1 (0)
FAIL: print_stack didn't find [kernel] (0)
FAIL: function arguments: unexpected timeout
FAIL: all pid tests - unexpected EOF
FAIL: function arguments -- numeric: unexpected timeout
FAIL: systemtap.examples/general/badname build
FAIL: systemtap.examples/general/badname run
FAIL: systemtap.examples/io/iostat-scsi run
FAIL: systemtap.examples/network/netdev build
FAIL: systemtap.examples/network/netdev run
FAIL: systemtap.examples/network/socktop run
FAIL: buildok/nfsd-detailed.stp
FAIL: buildok/pr10678.stp
FAIL: buildok/scsi-detailed.stp
FAIL: semok/thirtynine.stp
FAIL: systemtap.printf/ptr.stp
FAIL: RING_BUFFER startup (eof)
FAIL: shared buffer guest
FAIL: shared buffer guest2
FAIL: buffer sharing (0, 0)
FAIL: Valid Server Client Arguments: --client-options
FAIL: Valid Server Client Arguments: --client-options -a i386
FAIL: Valid Server Client Arguments: --client-options -D X=Y
FAIL: Valid Server Client Arguments: --client-options -I /tmp
FAIL: Valid Server Client Arguments: --client-options -m test
FAIL: Valid Server Client Arguments: --client-options -r 2.6.35-rc4-git5
FAIL: Valid Server Client Arguments: --client-options -a i386 -D X=Y -I /tmp -m test -r 2.6.35-rc4-git5
FAIL: Valid Server Client Arguments: --unprivileged --client-options
FAIL: Valid Server Client Arguments: --client-options --unprivileged
FAIL: Valid Server Client Arguments: --unprivileged -a i386 --client-options
FAIL: Valid Server Client Arguments: --unprivileged -B X=Y --client-options
FAIL: Valid Server Client Arguments: --unprivileged -D X=Y --client-options
FAIL: Valid Server Client Arguments: --unprivileged -I /tmp --client-options
FAIL: Valid Server Client Arguments: --unprivileged -m test --client-options
FAIL: Valid Server Client Arguments: --unprivileged -R /tmp --client-options
FAIL: Valid Server Client Arguments: --unprivileged -r 2.6.35-rc4-git5 --client-options
FAIL: Valid Server Client Arguments: --unprivileged -a i386 -B X=Y -D X=Y -I /tmp -m test -R /tmp -r 2.6.35-rc4-git5 --client-options
FAIL: Valid Server Client Arguments: -a i386 --unprivileged --client-options
FAIL: Valid Server Client Arguments: -B X=Y --unprivileged --client-options
FAIL: Valid Server Client Arguments: -D X=Y --unprivileged --client-options
FAIL: Valid Server Client Arguments: -I /tmp --unprivileged --client-options
FAIL: Valid Server Client Arguments: -m test --unprivileged --client-options
FAIL: Valid Server Client Arguments: -R /tmp --unprivileged --client-options
FAIL: Valid Server Client Arguments: -r 2.6.35-rc4-git5 --unprivileged --client-options
FAIL: Valid Server Client Arguments: -a i386 -B X=Y -D X=Y -I /tmp -m test -R /tmp -r 2.6.35-rc4-git5 --unprivileged --client-options
FAIL: Valid Server Client Arguments: -a i386 --client-options --unprivileged
FAIL: Valid Server Client Arguments: -B X=Y --client-options --unprivileged
FAIL: Valid Server Client Arguments: -D X=Y --client-options --unprivileged
FAIL: Valid Server Client Arguments: -I /tmp --client-options --unprivileged
FAIL: Valid Server Client Arguments: -m test --client-options --unprivileged
FAIL: Valid Server Client Arguments: -R /tmp --client-options --unprivileged
FAIL: Valid Server Client Arguments: -r 2.6.35-rc4-git5 --client-options --unprivileged
FAIL: Valid Server Client Arguments: -a i386 -B X=Y -D X=Y -I /tmp -m test -R /tmp -r 2.6.35-rc4-git5 --client-options --unprivileged
FAIL: systemtap.stress/current.stp startup (eof)
FAIL: 64-bit dup nd_syscall
FAIL: 64-bit eventfd nd_syscall
FAIL: 64-bit inotify nd_syscall
FAIL: 64-bit net1 nd_syscall
FAIL: 64-bit pipe nd_syscall
FAIL: 64-bit poll nd_syscall
FAIL: 64-bit signal nd_syscall
FAIL: 64-bit signalfd nd_syscall
FAIL: 64-bit signal syscall
=== systemtap Summary ===
# of expected passes 963
# of unexpected failures 77
# of unexpected successes 8
# of expected failures 232
# of known failures 7
# of untested testcases 232
# of unsupported tests 2
Thanks
Divya
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Systemtap results on power64 box against kernel version 2.6.35-rc4-git5
2010-07-13 13:40 Systemtap results on power64 box against kernel version 2.6.35-rc4-git5 divya
@ 2010-07-13 14:53 ` David Smith
2010-07-19 17:52 ` David Smith
0 siblings, 1 reply; 5+ messages in thread
From: David Smith @ 2010-07-13 14:53 UTC (permalink / raw)
To: divya; +Cc: systemtap, sachinp
On 07/13/2010 08:40 AM, divya wrote:
> Hi Everyone,
> Here is the result of systemtap snap test on kernel 2.6.35-rc4-git5
>
> Arch - ppc64
> elfutils version - 0.148
>
...
> FAIL: systemtap.examples/general/badname build
> FAIL: systemtap.examples/general/badname run
> FAIL: systemtap.examples/io/iostat-scsi run
> FAIL: systemtap.examples/network/netdev build
> FAIL: systemtap.examples/network/netdev run
> FAIL: systemtap.examples/network/socktop run
Hmm, I'm surprised the examples failed. Can you privately email me the
systemtap.log output for systemtap.examples/check.exp?
> FAIL: buildok/nfsd-detailed.stp
> FAIL: buildok/pr10678.stp
> FAIL: buildok/scsi-detailed.stp
I'd also like to see the systemtap.log portion for these failures.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Systemtap results on power64 box against kernel version 2.6.35-rc4-git5
2010-07-13 14:53 ` David Smith
@ 2010-07-19 17:52 ` David Smith
2010-07-20 10:02 ` divya
0 siblings, 1 reply; 5+ messages in thread
From: David Smith @ 2010-07-19 17:52 UTC (permalink / raw)
To: divya; +Cc: systemtap, sachinp
On 07/13/2010 09:53 AM, David Smith wrote:
> On 07/13/2010 08:40 AM, divya wrote:
>> Hi Everyone,
>> Here is the result of systemtap snap test on kernel 2.6.35-rc4-git5
>>
>> Arch - ppc64
>> elfutils version - 0.148
Divya was kind enough to send me the full log file, so I've had a look
at some of these errors. Most of the errors look to be debuginfo
problems with 1 build-id problem.
>> FAIL: systemtap.examples/general/badname build
>> FAIL: systemtap.examples/general/badname run
Hmm, it looks like the test should be a bit smarter and not try to run a
script if it fails to build. Anyway, this one fails with errors like:
semantic error: failed to retrieve location attribute for local 'child'
(dieoffset: 0xf3c95c): identifier '$child' at badname.stp:16:7
source: if ($child->d_inode || $dir->i_flags & 16) next
This looks like a debuginfo problem. Can you show me the output of:
# stap -L 'kernel.function("may_create@fs/namei.c")'
>> FAIL: systemtap.examples/io/iostat-scsi run
This one failed with:
ERROR: Build-id mismatch: "sd_mod" vs. "sd_mod.ko" byte 0 (0xc1 vs 0x00)
rc 0 -14
which means that stap doesn't think your debuginfo and the actual module
match. Other stap folk can probably expound more here.
>> FAIL: systemtap.examples/network/netdev build
>> FAIL: systemtap.examples/network/netdev run
This one failed with:
semantic error: failed to retrieve location attribute for local 'dev'
(dieoffset: 0x2daa6f2): identifier '$dev' at
/usr/local/share/systemtap/tapset/networking.stp:159:29
source: dev_name = get_netdev_name($dev)
I'd bet this one is a debuginfo problem. Can you show me the output of:
# stap -L netdev.change_rx_flag
>> FAIL: systemtap.examples/network/socktop run
This one was a testcase problem that I just fixed.
> Hmm, I'm surprised the examples failed. Can you privately email me the
> systemtap.log output for systemtap.examples/check.exp?
>
>> FAIL: buildok/nfsd-detailed.stp
This one dies with:
semantic error: not accessible at this address (0x1703c): identifier
'$filp' at /usr/local/share/systemtap/tapset/nfsd.stp:1046:29^M
source: filename = __file_filename($filp)^M
This looks like a debuginfo problem. Can you show me the output of:
# stap -L nfsd.close
>> FAIL: buildok/pr10678.stp
This one dies with:
semantic error: no match while resolving probe point
module("ne2k_pci").function("ne2k_pci_open")
This is a test problem, not a real problem.
>> FAIL: buildok/scsi-detailed.stp
This one dies errors like:
semantic error: not accessible at this address (0x10e34): identifier
'$cmd' at /usr/local/share/systemtap/tapset/scsi.stp:133:12^M
source: host_no = $cmd->device->host->host_no^M
This looks like another debuginfo problem. Can you show me the output of:
# stap -L scsi.iodone
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Systemtap results on power64 box against kernel version 2.6.35-rc4-git5
2010-07-19 17:52 ` David Smith
@ 2010-07-20 10:02 ` divya
2010-07-20 13:31 ` David Smith
0 siblings, 1 reply; 5+ messages in thread
From: divya @ 2010-07-20 10:02 UTC (permalink / raw)
To: David Smith; +Cc: systemtap, sachinp
On Monday 19 July 2010 11:22 PM, David Smith wrote:
> On 07/13/2010 09:53 AM, David Smith wrote:
>
>> On 07/13/2010 08:40 AM, divya wrote:
>>
>>> Hi Everyone,
>>> Here is the result of systemtap snap test on kernel 2.6.35-rc4-git5
>>>
>>> Arch - ppc64
>>> elfutils version - 0.148
>>>
> Divya was kind enough to send me the full log file, so I've had a look
> at some of these errors. Most of the errors look to be debuginfo
> problems with 1 build-id problem.
>
>
>>> FAIL: systemtap.examples/general/badname build
>>> FAIL: systemtap.examples/general/badname run
>>>
> Hmm, it looks like the test should be a bit smarter and not try to run a
> script if it fails to build. Anyway, this one fails with errors like:
>
> semantic error: failed to retrieve location attribute for local 'child'
> (dieoffset: 0xf3c95c): identifier '$child' at badname.stp:16:7
> source: if ($child->d_inode || $dir->i_flags& 16) next
>
> This looks like a debuginfo problem. Can you show me the output of:
>
> # stap -L 'kernel.function("may_create@fs/namei.c")'
>
p55alp7:~ # stap -L 'kernel.function("may_create@fs/namei.c")'
kernel.function("may_create@fs/namei.c:1354")
>
>>> FAIL: systemtap.examples/io/iostat-scsi run
>>>
> This one failed with:
>
> ERROR: Build-id mismatch: "sd_mod" vs. "sd_mod.ko" byte 0 (0xc1 vs 0x00)
> rc 0 -14
>
> which means that stap doesn't think your debuginfo and the actual module
> match. Other stap folk can probably expound more here.
>
>
>>> FAIL: systemtap.examples/network/netdev build
>>> FAIL: systemtap.examples/network/netdev run
>>>
> This one failed with:
>
> semantic error: failed to retrieve location attribute for local 'dev'
> (dieoffset: 0x2daa6f2): identifier '$dev' at
> /usr/local/share/systemtap/tapset/networking.stp:159:29
> source: dev_name = get_netdev_name($dev)
>
> I'd bet this one is a debuginfo problem. Can you show me the output of:
>
> # stap -L netdev.change_rx_flag
>
>
p55alp7:~ # stap -L netdev.change_rx_flag
semantic error: failed to retrieve location attribute for local 'dev' (dieoffset: 0x2daa6f2): identifier '$dev' at /usr/local/share/systemtap/tapset/networking.stp:159:29
source: dev_name = get_netdev_name($dev)
^
semantic error: failed to retrieve location attribute for local 'flags' (dieoffset: 0x2daa6ed): identifier '$flags' at :160:10
source: flags = $flags
^
semantic error: failed to retrieve location attribute for local 'dev' (dieoffset: 0x2daa899): identifier '$dev' at :159:29
source: dev_name = get_netdev_name($dev)
^
semantic error: failed to retrieve location attribute for local 'flags' (dieoffset: 0x2daa894): identifier '$flags' at :160:10
source: flags = $flags
^
semantic error: failed to retrieve location attribute for local 'dev' (dieoffset: 0x2daa9a1): identifier '$dev' at :159:29
source: dev_name = get_netdev_name($dev)
^
semantic error: failed to retrieve location attribute for local 'flags' (dieoffset: 0x2daa99c): identifier '$flags' at :160:10
source: flags = $flags
^
semantic error: unresolved type : identifier 'flags' at :160:2
source: flags = $flags
^
netdev.change_rx_flag dev_name:string flags:unknown
>>> FAIL: systemtap.examples/network/socktop run
>>>
> This one was a testcase problem that I just fixed.
>
>
>> Hmm, I'm surprised the examples failed. Can you privately email me the
>> systemtap.log output for systemtap.examples/check.exp?
>>
>>
>>> FAIL: buildok/nfsd-detailed.stp
>>>
> This one dies with:
>
> semantic error: not accessible at this address (0x1703c): identifier
> '$filp' at /usr/local/share/systemtap/tapset/nfsd.stp:1046:29^M
> source: filename = __file_filename($filp)^M
>
> This looks like a debuginfo problem. Can you show me the output of:
>
> # stap -L nfsd.close
>
p55alp7:~ # stap -L nfsd.close
semantic error: not accessible at this address (0x1703c): identifier '$filp' at /usr/local/share/systemtap/tapset/nfsd.stp:1046:29
source: filename = __file_filename($filp)
^
semantic error: not accessible at this address (0x1713c): identifier '$filp' at :1046:29
source: filename = __file_filename($filp)
^
semantic error: not accessible at this address (0x17258): identifier '$filp' at :1046:29
source: filename = __file_filename($filp)
^
semantic error: not accessible at this address (0x17364): identifier '$filp' at :1046:29
source: filename = __file_filename($filp)
^
nfsd.close client_ip:string filename:string name:string argstr:string
>
>
>>> FAIL: buildok/pr10678.stp
>>>
> This one dies with:
>
> semantic error: no match while resolving probe point
> module("ne2k_pci").function("ne2k_pci_open")
>
> This is a test problem, not a real problem.
>
>
>>> FAIL: buildok/scsi-detailed.stp
>>>
> This one dies errors like:
>
> semantic error: not accessible at this address (0x10e34): identifier
> '$cmd' at /usr/local/share/systemtap/tapset/scsi.stp:133:12^M
> source: host_no = $cmd->device->host->host_no^M
>
> This looks like another debuginfo problem. Can you show me the output of:
>
> # stap -L scsi.iodone
>
>
p55alp7:~ # stap -L scsi.iodone
semantic error: not accessible at this address (0x10e34): identifier '$cmd' at /usr/local/share/systemtap/tapset/scsi.stp:133:12
source: host_no = $cmd->device->host->host_no
^
semantic error: not accessible at this address (0x10e34): identifier '$cmd' at :134:12
source: channel = $cmd->device->channel
^
semantic error: not accessible at this address (0x10e34): identifier '$cmd' at :135:8
source: lun = $cmd->device->lun
^
semantic error: not accessible at this address (0x10e34): identifier '$cmd' at :136:11
source: dev_id = $cmd->device->id
^
semantic error: not accessible at this address (0x10e34): identifier '$cmd' at :137:17
source: device_state = $cmd->device->sdev_state
^
semantic error: not accessible at this address (0x10e34): identifier '$cmd' at :139:19
source: data_direction = $cmd->sc_data_direction
^
semantic error: not accessible at this address (0x10e34): identifier '$cmd' at :141:13
source: req_addr = $cmd->request
^
semantic error: not accessible at this address (0x10e34): identifier '$cmd' at :142:42
source: scsi_timer_pending = scsi_timer_pending($cmd);
^
semantic error: not accessible at this address (0x10f48): identifier '$cmd' at :133:12
source: host_no = $cmd->device->host->host_no
^
semantic error: not accessible at this address (0x10f48): identifier '$cmd' at :134:12
source: channel = $cmd->device->channel
^
semantic error: not accessible at this address (0x10f48): identifier '$cmd' at :135:8
source: lun = $cmd->device->lun
^
semantic error: not accessible at this address (0x10f48): identifier '$cmd' at :136:11
source: dev_id = $cmd->device->id
^
semantic error: not accessible at this address (0x10f48): identifier '$cmd' at :137:17
source: device_state = $cmd->device->sdev_state
^
semantic error: not accessible at this address (0x10f48): identifier '$cmd' at :139:19
source: data_direction = $cmd->sc_data_direction
^
semantic error: not accessible at this address (0x10f48): identifier '$cmd' at :141:13
source: req_addr = $cmd->request
^
semantic error: not accessible at this address (0x10f48): identifier '$cmd' at :142:42
source: scsi_timer_pending = scsi_timer_pending($cmd);
^
semantic error: not accessible at this address (0x10fac): identifier '$cmd' at :133:12
source: host_no = $cmd->device->host->host_no
^
semantic error: not accessible at this address (0x10fac): identifier '$cmd' at :134:12
source: channel = $cmd->device->channel
^
semantic error: not accessible at this address (0x10fac): identifier '$cmd' at :135:8
source: lun = $cmd->device->lun
^
semantic error: not accessible at this address (0x10fac): identifier '$cmd' at :136:11
source: dev_id = $cmd->device->id
^
semantic error: not accessible at this address (0x10fac): identifier '$cmd' at :137:17
source: device_state = $cmd->device->sdev_state
^
semantic error: not accessible at this address (0x10fac): identifier '$cmd' at :139:19
source: data_direction = $cmd->sc_data_direction
^
semantic error: not accessible at this address (0x10fac): identifier '$cmd' at :141:13
source: req_addr = $cmd->request
^
semantic error: not accessible at this address (0x10fac): identifier '$cmd' at :142:42
source: scsi_timer_pending = scsi_timer_pending($cmd);
^
semantic error: unresolved type : identifier 'host_no' at :133:2
source: host_no = $cmd->device->host->host_no
^
semantic error: unresolved type : identifier 'channel' at :134:2
source: channel = $cmd->device->channel
^
semantic error: unresolved type : identifier 'lun' at :135:2
source: lun = $cmd->device->lun
^
semantic error: unresolved type : identifier 'dev_id' at :136:2
source: dev_id = $cmd->device->id
^
semantic error: unresolved type : identifier 'req_addr' at :141:2
source: req_addr = $cmd->request
^
scsi.iodone device_state:long device_state_str:string data_direction:long data_direction_str:string scsi_timer_pending:long
Hi David,
Pls find the o/p of the commands mentioned above.
Also sending systemtap.examples/check.exp privately to your email.
Thanks
Divya
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Systemtap results on power64 box against kernel version 2.6.35-rc4-git5
2010-07-20 10:02 ` divya
@ 2010-07-20 13:31 ` David Smith
0 siblings, 0 replies; 5+ messages in thread
From: David Smith @ 2010-07-20 13:31 UTC (permalink / raw)
To: divya; +Cc: systemtap, sachinp
On 07/20/2010 05:02 AM, divya wrote:
> On Monday 19 July 2010 11:22 PM, David Smith wrote:
>> On 07/13/2010 09:53 AM, David Smith wrote:
>>
>>> On 07/13/2010 08:40 AM, divya wrote:
>>>
>>>> Hi Everyone,
>>>> Here is the result of systemtap snap test on kernel 2.6.35-rc4-git5
>>>>
>>>> Arch - ppc64
>>>> elfutils version - 0.148
>>>>
>> Divya was kind enough to send me the full log file, so I've had a look
>> at some of these errors. Most of the errors look to be debuginfo
>> problems with 1 build-id problem.
Divya,
Looks like I was right - these errors are debuginfo problems. In all of
the output you supplied, there were no dwarf variables visible. Is it
possible to upgrade your compiler? Looks like currently you have:
GCC: 4.3.2 [gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]]
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-07-20 13:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-13 13:40 Systemtap results on power64 box against kernel version 2.6.35-rc4-git5 divya
2010-07-13 14:53 ` David Smith
2010-07-19 17:52 ` David Smith
2010-07-20 10:02 ` divya
2010-07-20 13:31 ` David Smith
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).