Project

General

Profile

Actions

Bug #637

closed

"Kernel tracer unavailable" if ftrace, kprobes or kretprobes modules are not present

Added by Anonymous about 11 years ago. Updated about 11 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
09/19/2013
Due date:
% Done:

0%

Estimated time:

Description

In the Ubuntu packages, the compilation/installation of the lttng-ftrace.ko, lttng-kprobe.ko and lttng-kretprobes.ko modules is conditional to the presence of the necessary kernel config options (CONFIG_DYNAMIC_FTRACE, CONFIG_KPROES, etc.) This is because those options are not enabled on all architectures.

When installing such a package without those 3 .ko's, "lttng list -k" reports "Kernel tracer unavailable". Doing "sudo modprobe lttng-tracer" manually doesn't report any error, but then that module doesn't appear in "lsmod". The following is logged in dmesg:

[   96.213296] lttng_tracer: Unknown symbol lttng_kretprobes_destroy_private (err 0)
[   96.213452] lttng_tracer: Unknown symbol lttng_kprobes_register (err 0)
[   96.213508] lttng_tracer: Unknown symbol lttng_ftrace_unregister (err 0)
[   96.213549] lttng_tracer: Unknown symbol lttng_ftrace_register (err 0)
[   96.213583] lttng_tracer: Unknown symbol lttng_ftrace_destroy_private (err 0)
[   96.213656] lttng_tracer: Unknown symbol lttng_kretprobes_register (err 0)
[   96.213753] lttng_tracer: Unknown symbol lttng_kprobes_unregister (err 0)
[   96.213797] lttng_tracer: Unknown symbol lttng_kprobes_destroy_private (err 0)
[   96.213840] lttng_tracer: Unknown symbol lttng_kretprobes_unregister (err 0)
[  102.003639] lttng_tracer: Unknown symbol lttng_kretprobes_destroy_private (err 0)
[  102.003793] lttng_tracer: Unknown symbol lttng_kprobes_register (err 0)
[  102.003850] lttng_tracer: Unknown symbol lttng_ftrace_unregister (err 0)
[  102.003890] lttng_tracer: Unknown symbol lttng_ftrace_register (err 0)
[  102.003924] lttng_tracer: Unknown symbol lttng_ftrace_destroy_private (err 0)
[  102.003997] lttng_tracer: Unknown symbol lttng_kretprobes_register (err 0)
[  102.004094] lttng_tracer: Unknown symbol lttng_kprobes_unregister (err 0)
[  102.004138] lttng_tracer: Unknown symbol lttng_kprobes_destroy_private (err 0)
[  102.004181] lttng_tracer: Unknown symbol lttng_kretprobes_unregister (err 0)
[  237.414486] lttng_tracer: Unknown symbol lttng_kretprobes_destroy_private (err 0)
[  237.414644] lttng_tracer: Unknown symbol lttng_kprobes_register (err 0)
[  237.414701] lttng_tracer: Unknown symbol lttng_ftrace_unregister (err 0)
[  237.414741] lttng_tracer: Unknown symbol lttng_ftrace_register (err 0)
[  237.414776] lttng_tracer: Unknown symbol lttng_ftrace_destroy_private (err 0)
[  237.414849] lttng_tracer: Unknown symbol lttng_kretprobes_register (err 0)
[  237.414946] lttng_tracer: Unknown symbol lttng_kprobes_unregister (err 0)
[  237.414991] lttng_tracer: Unknown symbol lttng_kprobes_destroy_private (err 0)
[  237.415034] lttng_tracer: Unknown symbol lttng_kretprobes_unregister (err 0)

I was under the impression that the -ftrace, -kprobes and -kretprobes are optional, and that the rest of the tracer should work without them. Was I mistaken? If so, how should we handle building on architectures where those kernel options are not enabled or not available?

Actions #1

Updated by Mathieu Desnoyers about 11 years ago

  • Status changed from New to Invalid

In the case that triggered your errors, what happened is this: you compiled lttng-modules against a kernel config that contains those CONFIG_ options. In this case, lttng-tracer expects to find those other modules.

If lttng-modules is compiled against a kernel that does not have those CONFIG_ options enabled, those modules will not be built, and lttng-tracer will not have any dependency on their symbols.

You cannot "just remove" those .ko objects and hope lttng-tracer won't need them: lttng-tracer.ko needs to be recompiled against the right kernel config.

Thanks,

Mathieu

Actions #2

Updated by Anonymous about 11 years ago

Ah, that's probably it. That particular recipe I used was not installing the .ko's, but it was built against my running kernel, so it was expecting to find them.

We will just have to be careful that the detection of config options in the packaging matches the detection lttng-modules does. It would be simpler if you could just tell DKMS "install everything that is built". Unfortunately you can't :/

Thanks for the info!

Actions

Also available in: Atom PDF