When activating a RAID set, /usr/lib64/libdmraid-events-isw.so is not loaded because pthread_mutex_trylock is undefined symbol. Reproducible: Always Steps to Reproduce: 1. install dmraid (emerge dmraid) 2. activate RAID set (dmraid -a y) Actual Results: RAID set "isw_ddhjaehgdj_HDD_RAID" was activated The dynamic shared library "libdmraid-events-isw.so" could not be loaded: /usr/lib64/libdmraid-events-isw.so: undefined symbol: pthread_mutex_trylock Expected Results: successful load of libdmraid-events-isw.so It seems like the -lpthread was not set. I've tried with previous ebuild versions sys-fs/dmraid-1.0.0_rc16 sys-fs/dmraid-1.0.0_rc15-rc1 sys-fs/dmraid-1.0.0_rc15 and sys-fs/dmraid-1.0.0_rc14. Same behavior. emerge --info Portage 2.1.7.17 (default/linux/amd64/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r6 x86_64) ================================================================= System uname: Linux-2.6.31-gentoo-r6-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E8500_@_3.16GHz-with-gentoo-2.0.1 Timestamp of tree: Sun, 28 Feb 2010 10:15:01 +0000 app-shells/bash: 4.1_p2 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4-r1, 3.1.1-r1 dev-util/cmake: 2.8.0-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20-r1 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.32 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=core2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=core2" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles/ ftp://gentoo.tiscali.nl/pub/mirror/gentoo/ " LDFLAGS="-Wl,-O1" LINGUAS="en en_US fr" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 bash-completion berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr eds emboss encode evo fam firefox flac fontconfig fortran gdbm gif gnome gnutls gpm gstreamer gtk hal iconv ipv6 java jpeg ldap libnotify mad mikmod mmx mng modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre pdf perl png postscript ppds pppd python qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl startup-notification svg sysfs tcpd threads thunar tiff tk truetype unicode usb v4l v4l2 vim-syntax vorbis x264 xcb xinerama xml xorg xulrunner xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US fr" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
enable -pthread ldflags fix the problem ... src_configure() { append-ldflags -pthread econf \ $(use_enable static static_link) \ $(use_enable selinux libselinux) \ $(use_enable selinux libsepol) } ... But now, I've another error: RAID set "isw_ddhjaehgdj_HDD_RAID" was activated ERROR: Unable to register a device mapper event handler for device "isw_ddhjaehgdj_HDD_RAID"
iirc, there is an issue with using pthreads with other hardware or older versions of the kernel or something.. i can't remember the details but there is a reason to not include it for all compiles. That said, it seems that since it is needed it should be USE-flagged. Unfortunately I don't have the hardware to test dmraid anymore. That second issue looks like it's an upstream issue, though.. FYI, intel raid can now be managed entirely via mdadm, you don't need to use dmraid (or device-mapper) anymore.
thanks Ian Stakenvicius for the tips, I'll take a look at mdadm so.
@Ian: I suggest you either try to continue the maintainence of this ebuild or at least tell me, that you dont want to maintain it anymore, so others have a chance of looking at it.
I haven't found anything upstream that would suggest adding -pthread is a good idea (a couple of versions back it seemed to cause more issues than it solved).. As for the lack of detection, upstream seems to have nothing to say -- I'm adding the patch listed in bug 275451 but I do not think this will resolve your issue either. Since support for all intel biosraid is moving to mdadm anyhow, I'm changing this bug to resolved/wontfix. IF ANYONE ELSE HAS THE PTHREAD ISSUE, please re-open this bug and I'll apply the fix and/or sort it out with upstream.
OK, as requested. I tried re-emerging sys-fs/dmraid to make sure I got the "patched" version, but I get this error too. * Applying dmraid-1.0.0_rc16-undo-p-rename.patch ... [ ok ] * Applying dmraid-1.0.0_rc16-return-all-sets.patch ... [ ok ] * Applying dmraid-destdir-fix.patch ... [ ok ] * Applying dmraid-1.0.0_rc16-as-needed.patch ... [ ok ] Also on an intel RAID set. I'm willing to test patches etc, I'll wait with trying mdadm. PS, I don't have rights to reopen the bug, as I'm not the reporter.
OK, reopening bug as a reminder..
Created attachment 240215 [details] updates dmraid to snapshot v1_0_0_rc16-support_ignoremissing_option
Created attachment 240217 [details] ebuild that will apply the rc16 update patch OK, so upstream has been working on dmraid since rc16 through the 'device-mapper' project now instead of through the 'ataraid' project, it seems. Anyhow, there's a new version tagged in their CVS which includes pthread linking. This ebuild, combined with the patch "dmraid-1.0.0_rc16_20100317.patch" (in attachment 240215 [details] - copy it to files/ in your overlay) will provide the updated copy. I've tested the ebuild and it compiles and installs fine, HOWEVER I can't confirm that it works at runtime since I don't have the hardware. If you could test for me and report back I would appreciate it.
Well, the ebuild compiles fine, but unfortunatly, does not work. /dev/mapper is still empty. dmraid -ay hangs for a while, and finally spits out: Medusa mapper # dmraid -ay RAID set "isw_dagchgecca_BootEnBackup" already active RAID set "isw_dagchgecca_Data" already active ERROR: Unable to register a device mapper event handler for device "isw_dagchgecca_BootEnBackup" ERROR: Unable to register a device mapper event handler for device "isw_dagchgecca_Data" ERROR: opening "/dev/mapper/isw_dagchgecca_BootEnBackup" ERROR: opening "/dev/mapper/isw_dagchgecca_Data" Output from "strace -f -s 1500 -t -o /tmp/strace dmraid -ay" is found here: http://sharesend.com/uuu3a (bzip2'ed, 141MB unpacked, bugzilla has a limit of 1MB for uploaded files, this is 2.3MB) line 1002460 shows the error. Just above (1002436) that you can see the child segfaulting after a munmap() call.
Created attachment 240367 [details] strace output dmeventd After debugging some more, I'm pretty sure it's dmeventd which is segfaulting. Testcase; start strace -s 1500 -f -t -o /tmp/dmeventd -- dmeventd -ddd -f in one terminal, start dmraid -ay in another terminal. dmeventd exits with "segfault". strace output is attached (this one is tiny).
Created attachment 240375 [details] CVS HEAD ebuild for dmraid Try using this ebuild -- it's for current CVS; if it still doesn't work, then I'll forward your debugging info upstream so that they can try and fix it before the next release. If it does work, i'll try and back-port the patches. (adjust the KEYWORDS as necessary for your system)
Hmm, CVS HEAD doesn't seem to be working either... Builds, compiles and everything, but dmraid -ay still fails. Same error message, strace output looks similar too...
Ian, did you get around to reporting this upstream?
Not yet -- will be doing so today.
(In reply to comment #3) > thanks Ian Stakenvicius for the tips, I'll take a look at mdadm so. > Is there any documentation on howto use mdadm and Intel raid ? Thanks, Maxime
None that I am aware of... https://bugzilla.redhat.com/show_bug.cgi?id=542022#c2 ...might shed some light, though. Also, Roel, the issue this user was having looks a bit like yours; might be worth checking out...
This is the closest thing to a howto that i've been able to find so far: http://www.linuxquestions.org/questions/linux-kernel-70/imsm-volumes-in-mdadm-raid-setup-776171/#post3796916
I read something at some point in the past couple of weeks (sorry, don't have the reference) that seemed to imply that the md raid kernel modules could 'take over' the raids, even though they aren't being configured, which might block dmraid from being able to do its thing. Could you maybe double-check to ensure that no md-raid modules are enabled in your kernel, and then give dmraid a test?
Hmm, that could be something: Medusa ~ # lsmod | grep md Medusa ~ # zgrep _MD_ /proc/config.gz CONFIG_MD_AUTODETECT=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_RAID6_PQ=m CONFIG_MD_MULTIPATH=y CONFIG_MD_FAULTY=y I apparently have MD support compiled into my kernel. I'll see if I can recompile without this (or with modules) and re-test. Thanks for the how-to :) I do think the RedHat bug is different from my situation (different output), but comment #4 mentions: "because as said already Intel RAID now uses mdraid instead of dmraid.".