This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: freezes stap
- From: Lukas Berk <lberk at redhat dot com>
- To: systemtap <systemtap at sourceware dot org>
- Cc: swood at fotofor dot biz
- Date: Mon, 23 Jul 2018 10:22:43 -0400
- Subject: Re: freezes stap
- References: <CAM_jxg3-3Uh6i6W9=csqs+OsVs+9dPNfVwTcoi017rquV3e7Tw@mail.gmail.com> <CAKFOr-awuzc0i1B95K6+cJs5cJpJwZOnguwYpKNTpQDAgs8pAQ@mail.gmail.com> <CAM_jxg3x9-0RmqqmTAZh+6OQ-+A9s7Uk5zN=J6h31eRtyS7hqg@mail.gmail.com> <CAKFOr-bD1JP1e4qbC+vRroeUicn5q9gAqcCqiCejWRSpN8_r=A@mail.gmail.com>
Hi,
A somewhat tangential thought,
David Smith <dsmith@redhat.com> writes:
>>> 2) WARNING: probe kernel.function("vfs_read@../fs/read_write.c:418")
>>> (address 0xffffffff95232f70) registration error (rc -84)
>>>
>>> That one is fairly fatal. Your probe couldn't be registered, and
>>> returned -84. Since your probe couldn't be registered, the module
>>> won't really do anything.
>From a usability standpoint, could we possibly keep track of the number
of targeted probe points vs successfully registered probe points? In
the event none exist, perhaps it'd be worthwhile to exit on our own
volition. It might spare users the extra time trying to debug the issue
with a message elaborating on why (ie, no probe points actually
registered, nothing for us to do).
Cheers,
Lukas