public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: fche@redhat.com (Frank Ch. Eigler)
To: Mike Mason <mmlnx@us.ibm.com>
Cc: systemtap@sources.redhat.com
Subject: Re: Script to measure resource usage based on process arguments
Date: Tue, 16 Jan 2007 15:42:00 -0000	[thread overview]
Message-ID: <y0m64b70yip.fsf@ton.toronto.redhat.com> (raw)
In-Reply-To: <45A2EF6B.2010103@us.ibm.com>


mmlnx wrote:

> Forgot to mention one important thing... I've seen this script crash
> the system a few times.  The sequence of events that cause the crash
> are a bit strange.  I start the script, then start a kernel build.
> The script and build both run to completion.  Then I start the script
> again and it crashes. [...]

Interesting.  It's a little reminiscent of an old bug that did not
correctly unregister all kprobes under some failure exit conditions.

> Unable to handle kernel paging request at ffffffff8832e1dd RIP:
> [<ffffffff8832e1dd>]
> PGD 203027 PUD 205027 PMD 396e6067 PTE 0
> Oops: 0010 [1] SMP last sysfs file: /module/scsi_mod/sections/.text
> CPU 0 Modules linked in: ipv6 autofs4 hidp rfcomm l2cap bluetooth
> sunrpc dm_mirror dm_mod video sbs i2c_ec button battery asus_acpi ac
> lp parport_pc parport snd_hda_intel snd_hda_codec snd_seq_dummy
> snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss sg
> e1000 snd_mixer_oss snd_pcm serio_raw snd_timer ehci_hcd snd uhci_hcd
> ide_cd i2c_i801 shpchp soundcore snd_page_alloc cdrom i2c_core pcspkr
> ext3 jbd ahci libata sd_mod scsi_mod

Note that no stap_* module is listed here as loaded.  This could mean
that the problem occurred during initialization of the new copy of the
module. From the "bad RIP value" / fault traceback, it looks as if
there was still some kind of timer task left running in the system by
a prior systemtap run.  That module was then unloaded, which unmapped
the module executable region.  It would help if you followed the steps
in the HowToReportProblems wiki page, specifically to identify
probable stap module loading addresses.

We use timer type tasks in two contexts: probes on timer.ms and like,
and an I/O related widget in the runtime.  We should review both bits
of code to ensure that we always start up and clean up carefully.  It
is probably also helpful to have systemtap emit a few DEBUG-level
printk's during setup to note vital statistics about systemtap
modules: base addresses, number of probes, memory used, that sort of
thing.  Any volunteers?


- FChE

  reply	other threads:[~2007-01-16 15:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-09  0:55 Mike Mason
2007-01-09  1:27 ` Mike Mason
2007-01-16 15:42   ` Frank Ch. Eigler [this message]
2007-04-18 16:07 ` Frank Ch. Eigler
2007-04-18 16:21   ` Mike Mason

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=y0m64b70yip.fsf@ton.toronto.redhat.com \
    --to=fche@redhat.com \
    --cc=mmlnx@us.ibm.com \
    --cc=systemtap@sources.redhat.com \
    /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).