On Tue, 2007-11-20 at 11:21 +0100, Tore Anderson wrote:
> * S. J. van Harmelen
> > Could you specify the steps I have to take to create the backtrace a
> > bit more as I have not done this before.
> > I run a debian etch server with a custom compiled 220.127.116.11 kernel
> > when I get the error.
> Debian strips all their binaries by default, so you need to recompile
> multipath-tools and reinstall it:
> $ export DEB_BUILD_OPTIONS=nostrip
> $ apt-get build-dep multipath-tools
> $ apt-get --compile source multipath-tools
> $ dpkg -i multipath-tools*deb
I guess I don't have to do that as I compiled the multipath-tools
tar jxf multipath-tools-0.4.8.tar.bz2
I did compile them when running the 18.104.22.168 kernel though. Should I
recompile them when running the 22.214.171.124 kernel, or doesn't that matter?
> Then start multipathd from a shell that has core dumps enabled (make
> sure it's not already running):
> $ ulimit -c unlimited
> $ multipathd
> Wait for a segfault to happen, and you should have gotten a file named
> "core" in your current directory (or maybe in the root directory since
> multipathd chdir()s there, I'm not sure) that contains the backtrace.
> We need to extract it with GDB, though, so run:
> $ gdb /sbin/multipathd /path/to/core
> (gdb) bt full
Oke, the segfault happens right at the start (and only at the start), so
that shouldn't be a problem. But I have to stop the running mulipathd
and that seems like a problem. This machine is running in production
So that will have to wait until I get a maintance window I guess...
> ...and post the resulting backtrace here. Hopefully a developer (not
> me, unfortunately) will be able to make sense of it.
> Another thing you might want to try is to use your 126.96.36.199 with the
> same configuration as your 2.6.22.x (ie. don't use hwhandler rdac), and
> see if the segfaults still occur.
dm-devel mailing list