Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]

[Andi Kleen]

> In my experience, there are very few kernel versions and hardware for
> which kdump works. 

I think that's mostly because kexec from arbitary context is a 
somewhat unstable concept. It requires all drivers to be able
to reinit the hardware from an arbitary state, and that's just
hard (it's kind of "make suspend/resume work everywhere"
and then a little harder and we know how long that took)

We also don't really have any tools to help making this
easier to implement for driver developers. Like e.g. some self
test that restarted drivers regularly to check this. 

But you often don't need kdump for crash dumps.
In many cases the system is still alive after an oops
or other problem and you can just do a live dump or even 
live crash session to look at data structures.

I used to do this with gdb regularly, but now
usually use crash because it has better tools.

> they aren't enterprise users.  Heck, until July of last year,
> Systemtap wouldn't even ***compile*** out of the box on a
> non-enterprise distribution like Ubuntu or Debian.

At least on opensuse releases it tends to work for me. 

The biggest PITA used to be the elfutils dependency which
seemed to come out of a all-world-is-redhat mindset at
the developers, but that can be worked around now.

Sometimes on has to patch it up when updating kernels 
because some interface by the runtime has changed again, but 
that shouldn't be a demanding task for kernel hackers really.
At least I didn't find it particularly difficult.

I wish they would merge the runtime into mainline though.

-Andi
-- 
ak@xxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/