<html><head></head><body>No Raspberry Pi servers any more? <br><br><div class="gmail_quote">On April 28, 2015 5:07:06 AM PDT, Justin Clift <justin@gluster.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Does this mean we're officially no longer supporting 32 bit architectures?<br /><br />(or is that just on x86?)<br /><br />+ Justin<br /><br /><br />On 28 Apr 2015, at 12:45, Kaushal M <kshlmster@gmail.com> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Found the problem. The NetBSD slaves are running a 32-bit kernel and userspace.<br /> ```<br /> nbslave7a# uname -p<br /> i386<br /> ```<br /> <br /> Because of this CAA_BITS_PER_LONG is set to 32 and the case for size 8<br /> isn't compiled in uatomic_add_return. Even though the underlying<br /> (virtual) hardware has 64-bit support, and supports the required<br /> 8-byte wide instrcution, it cannot be used because we are running on a<br /> 32-bit kernel with a 32-bit userspace.<br /> <br /> Manu, was there any particular reason why you 32-bit NetBSD? If there<br /> are none, can you please replace the VMs with 64-bit
NetBSD. Until<br /> then you can keep mgmt_v3-locks.t disabled.<br /> <br /> ~kaushal<br /> <br /> On Tue, Apr 28, 2015 at 4:56 PM, Kaushal M <kshlmster@gmail.com> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> I seem to have found the issue.<br /> <br /> The uatomic_add_return function is defined in urcu/uatomic.h as<br /> ```<br /> /* uatomic_add_return */<br /> <br /> static inline __attribute__((always_inline))<br /> unsigned long __uatomic_add_return(void *addr, unsigned long val,<br /> int len)<br /> {<br /> switch (len) {<br /> case 1:<br /> {<br /> unsigned char result = val;<br /> <br /> __asm__ __volatile__(<br /> "lock; xaddb %1, %0"<br /> : "+m"(*__hp(addr)), "+q" (result)<br /> :<br /> : "memory");<br /> return
result + (unsigned char)val;<br /> }<br /> case 2:<br /> {<br /> unsigned short result = val;<br /> <br /> __asm__ __volatile__(<br /> "lock; xaddw %1, %0"<br /> : "+m"(*__hp(addr)), "+r" (result)<br /> :<br /> : "memory");<br /> return result + (unsigned short)val;<br /> }<br /> case 4:<br /> {<br /> unsigned int result = val;<br /> <br /> __asm__ __volatile__(<br /> "lock; xaddl %1, %0"<br /> : "+m"(*__hp(addr)), "+r" (result)<br /> :<br /> : "memory");<br /> return result + (unsigned int)val;<br /> }<br /> #if (CAA_BITS_PER_LONG == 64)<br /> case 8:<br /> {<br /> unsigned long result = val;<br /> <br /> __asm__ __volatile__(<br /> "lock; xaddq
%1, %0"<br /> : "+m"(*__hp(addr)), "+r" (result)<br /> :<br /> : "memory");<br /> return result + (unsigned long)val;<br /> }<br /> #endif<br /> }<br /> /*<br /> * generate an illegal instruction. Cannot catch this with<br /> * linker tricks when optimizations are disabled.<br /> */<br /> __asm__ __volatile__("ud2");<br /> return 0;<br /> }<br /> ```<br /> <br /> As we can see, uatomic_add_return uses different assembly instructions<br /> to perform the add based on the size of the datatype of the value. If<br /> the size of the value doesn't exactly match one of the sizes in the<br /> switch case, it deliberately generates a SIGILL.<br /> <br /> The case for size 8, is conditionally compiled as we can see above.<br /> From the backtrace Atin provided earlier, we see that the size of the<br /> value is indeed 8 (we use uint64_t). Because we had a SIGILL,
we can<br /> conclude that the case for size 8 wasn't compiled.<br /> <br /> I don't know why this compilation didn't (or as this is in a header<br /> file, doesn't) happen on the NetBSD slaves and this is something I'd<br /> like to find out.<br /> <br /> ~kaushal<br /> <br /> On Tue, Apr 28, 2015 at 1:50 PM, Anand Nekkunti <anekkunt@redhat.com> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> <br /> On 04/28/2015 01:40 PM, Emmanuel Dreyfus wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> <br /> On Tue, Apr 28, 2015 at 01:37:42PM +0530, Anand Nekkunti wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> <br /> __asm__ is for to write assembly code in c (gcc),<br /> __volatile__(:::)<br /> compiler level barrier to force the
compiler not to do reorder the<br /> instructions(to avoid optimization ) .<br /></blockquote> <br /> Sure, but the gory details should be of no interest to the developer<br /> engaged in debug: if it crashes this is probably because it is called<br /> with wrong arguments, hence the question:<br /> ccing gluster-devel<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"> <br /> new_peer->generation = uatomic_add_return (&conf->generation,<br /> 1);<br /> Are new_peer->generation and conf->generation sane?<br /></blockquote></blockquote></blockquote> <br /> <br /><hr /><br /> Gluster-devel mailing list<br /> Gluster-devel@gluster.org<br /> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br
/></blockquote></blockquote><hr /><br /> Gluster-devel mailing list<br /> Gluster-devel@gluster.org<br /> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br /></blockquote><br />--<br />GlusterFS - <a href="http://www.gluster.org">http://www.gluster.org</a><br /><br />An open source, distributed file system scaling to several<br />petabytes, and handling thousands of clients.<br /><br />My personal twitter: <a href="http://twitter.com/realjustinclift">twitter.com/realjustinclift</a><br /><br /><hr /><br />Gluster-devel mailing list<br />Gluster-devel@gluster.org<br /><a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>