From: Peter Chubb <peter@chubb.wattle.id.au>
To: linux-ia64@vger.kernel.org
Subject: q-tools OOPS
Date: Mon, 08 Dec 2003 22:46:18 +0000 [thread overview]
Message-ID: <marc-linux-ia64-107092374429612@msgid-missing> (raw)
Hi David,
Dunno what's going on here. I've built q-tools against libpfm3.0
and libc 2.3.2.ds1-10.0.1 from Debian using gcc 3.2.3.
When run on a vanilla 2.6.0-test11 kernel, I either get no output, or
an OOPS. stracing q-syscollect always shows a SEGV in the child
processes, but I think that may be an strace bug.
I guess that this *could* be a preemption problem; have you run
q-syscollect on a machine with CONFIG_PREEMPT on?
Test1:
sudo q-syscollect -k -t 10
pauses for 10 seconds, creates a ./.q directory, but there's nothing
in it.
Test2:
q-syscollect sleep 1
causes a kernel panic:
Unable to handle kernel paging request at virtual address 2000000000040000
sleep[2308]: Oops 11012296146944 [1]
Pid: 2308, CPU 0, comm: sleep
psr : 00001213087a6010 ifs : 8000000000015428 ip :
[<2000000000023991>] Not tainted
ip is at 0x2000000000023991
unat: 0000000000000000 pfs : c000000000000a99 rsc : 000000000000000f
rnat: 0000000000000000 bsps: 60000fff7fffc5d0 pr : ffffffffffd6a6a9
ldrs: 0000000003100000 ccv : 0000000000000000 fpsr: 0009804c0270033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : 20000000000104f0 b6 : 2000000000015da0 b7 : 0000000000000000
...
I've also caught other panics: For example q-syscollect -v sleep 1
bad: scheduling while atomic!
Call Trace:
[<a000000100014980>] show_stack+0x80/0xa0
spà0000003861fb80 bspà000000386194b0
[<a000000100082910>] schedule+0x12b0/0x12c0
spà0000003861fd50 bspà000000386193d0
[<a0000001001b8d30>] do_get_write_access+0x9f0/0xe80
spà0000003861fd60 bspà00000038619360
[<a0000001001b9200>] journal_get_write_access+0x40/0x80
spà0000003861fd90 bspà00000038619328
[<a0000001001a2f70>] ext3_reserve_inode_write+0xd0/0x160
spà0000003861fd90 bspà000000386192e0
[<a0000001001a3030>] ext3_mark_inode_dirty+0x30/0x80
spà0000003861fd90 bspà000000386192c0
[<a0000001001a31b0>] ext3_dirty_inode+0x130/0x1a0
spà0000003861fdb0 bspà00000038619298
[<a00000010015f970>] __mark_inode_dirty+0x290/0x2a0
spà0000003861fdb0 bspà00000038619268
[<a000000100151f80>] update_atime+0x220/0x240
spà0000003861fdb0 bspà00000038619240
[<a000000100135540>] link_path_walk+0xf00/0x1840
spà0000003861fdd0 bspà000000386191c8
[<a0000001001376d0>] open_namei+0xf0/0xa80
spà0000003861fdf0 bspà00000038619160
[<a000000100110ae0>] filp_open+0x60/0xe0
spà0000003861fe00 bspà00000038619138
[<a000000100111810>] sys_open+0xb0/0x140
spà0000003861fe30 bspà000000386190c0
[<a00000010000db60>] ia64_ret_from_syscall+0x0/0x20
spà0000003861fe30 bspà000000386190c0
bad: scheduling while atomic!
Call Trace:
[<a000000100014980>] show_stack+0x80/0xa0
spà00000037fafc50 bspà00000037fa9170
[<a000000100082910>] schedule+0x12b0/0x12c0
spà00000037fafe20 bspà00000037fa9098
[<a00000010000e0d0>] skip_rbs_switch+0x90/0xe0
spà00000037fafe30 bspà00000037fa9098
Unable to handle kernel paging request at virtual address 20000000000e23dc
sleep[651]: Oops 8804682956800 [1]
Pid: 651, CPU 0, comm: sleep
psr : 00001013087a6010 ifs : 8000000000000183 ip : [<2000000000024020>] Not tainted
ip is at 0x2000000000024020
unat: 0000000000000000 pfs : c000000000001736 rsc : 000000000000000f
rnat: 0000000000000000 bsps: 60000fff7fffc6f0 pr : 0000000000193729
ldrs: 0000000001900000 ccv : 0000000000000000 fpsr: 0009804c0270033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : 200000000000c2c0 b6 : 2000000000024b00 b7 : 0000000000000000
f6 : 000000000000000000000 f7 : 000000000000000000000
f8 : 000000000000000000000 f9 : 000000000000000000000
f10 : 000000000000000000000 f11 : 000000000000000000000
r1 : 200000000003e750 r2 : 0000000000000000 r3 : 0000000000000001
r8 : 20000000000e23dc r9 : 60000fffffffb660 r10 : 0000000000000000
r11 : 0000000000003a3a r12 : 60000fffffffafa0 r13 : 200000000002d580
r14 : 0000000000000002 r15 : 0000000000004000 r16 : ffffffffffffc000
r17 : 0000000000000000 r18 : 0000000000000000 r19 : 0000000000000000
r20 : 0009804c0270033f r21 : 0000000000000004 r22 : 2000000000024b00
r23 : 60000fff7fffc6f0 r24 : 0000000000000000 r25 : 0000000000000000
r26 : c000000000001736 r27 : 20000000000e23dc r28 : 20000000000e23e0
next reply other threads:[~2003-12-08 22:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-08 22:46 Peter Chubb [this message]
2003-12-08 23:28 ` q-tools OOPS Stephane Eranian
2003-12-08 23:33 ` David Mosberger
2003-12-08 23:50 ` Peter Chubb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ia64-107092374429612@msgid-missing \
--to=peter@chubb.wattle.id.au \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.