From: Mark Wielaard <mjw@redhat.com>
To: dmitry.krivenok@emc.com
Cc: systemtap@sourceware.org
Subject: Re: Kernel panics during execution of timeouts.stp example when booted with kgdboc=kms,kbd
Date: Wed, 07 Dec 2011 12:16:00 -0000 [thread overview]
Message-ID: <1323256821.8528.3.camel@springer.wildebeest.org> (raw)
In-Reply-To: <9C7BACB01B839A499792154E76C9ADE5563DC350EF@MX19A.corp.emc.com>
Hi,
On Tue, 2011-12-06 at 03:39 -0500, dmitry.krivenok@emc.com wrote:
> The problem is that kernel panics if you run it with "kgdboc=kms,kbd"
> parameter and then run standard timeout.stp example as follows:
>
> $ sudo stap -v `locate timeout.stp`
> Pass 1: parsed user script and 77 library script(s) using 78192virt/22076res/2376shr kb, in 190usr/60sys/689real ms.
> Pass 2: analyzed script: 12 probe(s), 7 function(s), 5 embed(s), 10 global(s) using 202032virt/44892res/3256shr kb, in 790usr/4810sys/10056real ms.
> Pass 3: using cached /root/.systemtap/cache/dd/stap_ddd8c5ac8daf0d8644742908043722b3_12685.c
> Pass 4: using cached /root/.systemtap/cache/dd/stap_ddd8c5ac8daf0d8644742908043722b3_12685.ko
> Pass 5: starting run.
>
> I also tried to run stap with -vvv options and the last lines I saw were:
> ...
> ...
> execing: /usr/local/libexec/systemtap/stapio -v -v -R stap_ddd8c5ac8daf0d8644742908043722b3_1_777
> stapio:parse_modpath:368 modpath="/lib/modules/3.1.1/systemtap/stap_ddd8c5ac8daf0d8644742908043722b3_1_777.ko"
> stapio:main:41 modpath="/lib/modules/3.1.1/systemtap/stap_ddd8c5ac8daf0d8644742908043722b3_1_777.ko", modname="stap_ddd8c5ac8daf0d8644742908043722b3_1_777"
> stapio:init_stapio:338 init_stapio
> stapio:init_ctl_channel:31 Opened /sys/kernel/debug/systemtap/stap_ddd8c5ac8daf0d8644742908043722b3_1_777/.cmd (3)
> stapio:stp_main_loop:529 in main loop
> stapio:init_relayfs:239 initializing relayfs
> stapio:init_relayfs:263 attempting to open /sys/kernel/debug/systemtap/stap_ddd8c5ac8daf0d8644742908043722b3_1_777/trace0
> stapio:init_relayfs:263 attempting to open /sys/kernel/debug/systemtap/stap_ddd8c5ac8daf0d8644742908043722b3_1_777/trace1
> stapio:init_relayfs:269 ncpus=1, bulkmode = 0
> stapio:init_relayfs:352 starting threads
>
> The problem is 100% reproducible on both systems.
> I'm not sure if it's a bug in Systemtap or kernel, because I could misconfigure something.
>
> Could someone please try to reproduce the problem and post results here?
I don't have the above setup here handy atm. But it would be helpful if
you could post the results of 'stap-report' somewhere. And even better
if you could try and get a serial console dump of the kernel panic you
are getting, see http://sourceware.org/systemtap/wiki/HowToReportBugs
and here http://sourceware.org/systemtap/wiki/DeveloperSetupTips for
some guides on setting that up.
Thanks,
Mark
next prev parent reply other threads:[~2011-12-07 11:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-06 19:46 dmitry.krivenok
2011-12-07 12:16 ` Mark Wielaard [this message]
2011-12-07 15:15 ` dmitry.krivenok
2011-12-07 20:11 ` Frank Ch. Eigler
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=1323256821.8528.3.camel@springer.wildebeest.org \
--to=mjw@redhat.com \
--cc=dmitry.krivenok@emc.com \
--cc=systemtap@sourceware.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 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).