I found this in the archives: http://gluster.org/pipermail/gluster-users/20081027/000523.html I don't see any follow ups with any sort of solution. I'm running gluster 3.0.2 with patch 2659 with a 64bit client and 64bit server without any issues. I turned up another box running 32 bit client pointing to 2 different 64bit servers and I had the same issues listed above. My kernels on both boxes clients are 2.6.30 neither have any patches applied. Here's my client output pending frames: frame : type(1) op(LOOKUP) frame : type(1) op(STAT) frame : type(1) op(STAT) patchset: v3.0.2 signal received: 11 time of crash: 2010-02-26 16:01:08 configuration details: argp 1 backtrace 1 dlfcn 1 fdatasync 1 libpthread 1 llistxattr 1 setfsid 1 spinlock 1 epoll.h 1 xattr.h 1 st_atim.tv_nsec 1 package-string: glusterfs 3.0.2 [0xffffe400] /usr/lib/libglusterfs.so.0[0xb7ffa8a4] /usr/lib/libglusterfs.so.0(inode_unref+0x39)[0xb7ffb571] /usr/lib/libglusterfs.so.0(loc_wipe+0x25)[0xb7feec52] /usr/lib/libglusterfs.so.0(call_stub_destroy+0x786)[0xb800208e] /usr/lib/libglusterfs.so.0(call_resume+0x73)[0xb80022a8] /usr/lib/glusterfs/3.0.2/xlator/performance/io-threads.so(iot_worker_unordered+0x20)[0xb75e0ae3] /lib/tls/libpthread.so.0[0xb7fcd1ce] /lib/tls/libc.so.6(__clone+0x5e)[0xb7f6290e] --------- Segmentation fault (core dumped) I've turned off io-threads and the process hasn't cored again. Is this a general practice to not mix 32bit client and 64bit servers? Thanks, --mike terzo