This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/15663] Failing to remove the stap kernel modules on kernel 3.9.4
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Fri, 21 Jun 2013 23:26:11 +0000
- Subject: [Bug runtime/15663] Failing to remove the stap kernel modules on kernel 3.9.4
- Auto-submitted: auto-generated
- References: <bug-15663-6586 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=15663
Josh Stone <jistone at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jistone at redhat dot com
--- Comment #1 from Josh Stone <jistone at redhat dot com> ---
(In reply to agentzh from comment #0)
> # lsmod | grep stap
> stap_db98a89434ce6c6d11c1e43dd3b758df_11003 242671 0 [permanent]
> stap_41ed56b577691483d1b190b51ee07fe1_12277 241903 0 [permanent]
The [permanent] is somewhat reminiscent of this thread:
http://sourceware.org/ml/systemtap/2012-q1/msg00041.html
... although that case was also indicated by an implausible reference count,
where you have a seemingly correct 0. But to summarize, the issue there was
that the gcc version used for the kernel was different than the gcc available
to stap for compiling kernel modules. That led kbuild to have a difference in
-DCC_HAVE_ASM_GOTO, which then sets HAVE_JUMP_LABEL, which causes the layout of
struct module to change.
So please check the compiler versions first. If these do match, then we'll
continue looking elsewhere. Check dmesg around the time stap was active, and
also consider attaching the output of stap-report here.
PS: As a diagnostic for that particular issue, there might actually be a way to
compare sizeof(struct module) from vmlinux to our own modules. We could
basically compare a @cast "module" between "kernel" (for vmlinux) and
"kernel<linux/module.h>" (thus generated by us) -- although with stap internals
it doesn't have to literally be a @cast, just something that finds those types
and compares the DWARF sizes. This would of course only work when kernel
debuginfo is available, but it may prevent some headaches.
--
You are receiving this mail because:
You are the assignee for the bug.