Sean,<br>
<br>
Thanks for the reply.<br>
<br>
I was building with the gcc optimized for the Sun T1 'Niagara' (aka
CoolThreads) chip. I don't have access to that machine any more
though. I do have a couple of other SPARC machines that I might try. <br>
<br>
Regards,<br>
--Doug<br><br><br><div class="gmail_quote">On Sun, Aug 9, 2009 at 4:02 PM, Sean McGovern <span dir="ltr"><<a href="mailto:gseanmcg@gmail.com">gseanmcg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don't have access to a SPARC myself. If that data is actually mis-aligned it is quite possible it needs to be fixed so that it is -- I don't think SPARCs, Itaniums or even PowerPCs are capable fixing up misaligned reads from memory as an x86 would (and my understanding is that the fixup does incur a performance hit).<br>
<br>My error was different though -- something about an assertion about 'qscale' failing, and only if I apply gcc optimizations above -O2.<br><br>Are you building with gcc or the Sun Studio compiler?<br><br>-- Sean<br>
<p></p><hr align="center" width="100%" size="2"><b>From</b>: Doug Jackson <br><b>Date</b>: Sun, 9 Aug 2009 15:19:21 -0400<br><b>To</b>: <<a href="mailto:gseanmcg@gmail.com" target="_blank">gseanmcg@gmail.com</a>><br>
<b>Subject</b>: x264 Solaris<br><div><div></div><div class="h5">Hi Sean,<br><br>Thanks for the posting about the x264 for Solaris 10 (x86).<br><br>I tried compiling on Solaris 10 SPARC awhile back (several months) and remember having core dump issues when running.<br>
<br>Here part of the thread:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">A recent thread posted a fix for Bus Error on Solaris:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<pre>It seems the message was only sent to me and a few others, not to the<br><br>ML. Here it is.<br><br>Dark Shikari<br><br>Hello,<br>the bs_init function has two bugs for non aligned p_data pointer.<br><br>I suggest to replace<br>
s->i_left = offset ? 8*offset : (WORD_SIZE*8);<br> s->cur_bits = endian_fix( *(intptr_t*)s->p );<br><br>by<br> s->i_left = (WORD_SIZE - offset )*8;<br> s->cur_bits = endian_fix( *(intptr_t*)s->p ) >> s->i_left;<br>
<br>Mehdi MOSTAFAVI<br><br>inline void bs_init( bs_t *s, void *p_data, int i_data )<br>{<br><br> int offset = ((intptr_t)p_data & (WORD_SIZE-1));<br> s->p = s->p_start = (uint8_t*)p_data - offset;<br> s->p_end = (uint8_t*)p_data + i_data;<br>
s->i_left = (WORD_SIZE - offset )*8;<br> s->cur_bits = endian_fix( *(intptr_t*)s->p ) >> s->i_left;<br><br>}<br></pre></blockquote><br><br>I've tried the suggested solution, but still have the error.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> t2000-a# ./<span>x264</span> -B1830 -o foo.264 /football_sif.y4m<br>yuv4mpeg: 352x240@30000/1001fps, 4320:4739<br>
<span>x264</span> [info]: using SAR=4320/4739<br><span>x264</span> [info]: using cpu capabilities: none!<br><span>x264</span> [info]: profile Main, level 2.1<br> Bus Error (core dumped)<br></blockquote><br>And if I truss:<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">read(4, " F R A M E\n808080808080".., 8192) = 8192<br> read(4, " g p l N }FDFFFFDC r a t".., 8192) = 8192<br>
read(4, " j i t z q g h q x r q v".., 8192) = 8192<br>read(4, " l j q j j m n j j o k i".., 8192) = 8192<br>read(4, " y w o v x y8FA98D i b t".., 8192) = 8192<br> read(4, " % % & # % & $ ( 6 1 8 i".., 8192) = 8192<br>
read(4, " Z Z Z X X W P S O O I F".., 8192) = 8192<br>read(4, " n j w l c p p j d V T a".., 8192) = 8192<br>read(4, " } z | r w p r81 y t u81".., 8192) = 8192<br> read(4, " X o o i ` X a m j m d f".., 8192) = 8192<br>
read(4, " s p t e j q7F x i c ` i".., 8192) = 8192<br>read(4, " y u } x y } b c d c b a".., 8192) = 8192<br>read(4, " a ` ` ^ ]___ ` a a_".., 8192) = 8192<br> read(4, "8A8C8D898A8D8D8D8D8B8A8A".., 8192) = 8192<br>
read(4, "87858B89888988868A8C8E8D".., 8192) = 8192<br>read(4, "8A8D8D8F8F908C8D8C8E8E8F".., 8192) = 8192<br>brk(0x003DEC40) = 0<br> brk(0x003E0C40) = 0<br>
brk(0x003E0C40) = 0<br>brk(0x003EAC40) = 0<br>brk(0x003EAC40) = 0<br> brk(0x003F2C40) = 0<br>
brk(0x003F2C40) = 0<br>brk(0x0046EC40) = 0<br>brk(0x0046EC40) = 0<br>brk(0x0049AC40) = 0<br>
brk(0x0049AC40) = 0<br> brk(0x004A0C40) = 0<br>brk(0x004A0C40) = 0<br>brk(0x004B0C40) = 0<br>
Incurred fault #5, FLTACCESS %pc = 0x0009991C<br> siginfo: SIGBUS BUS_ADRALN addr=0x002BB62A<br> Received signal #10, SIGBUS [default]<br> siginfo: SIGBUS BUS_ADRALN addr=0x002BB62A<br></blockquote><br>
When looking at bs.h and bs_flush, there is a comment about memory alignment. <br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> /* Write the rest of cur_bits to the bitstream; results in a bitstream no longer<br>
32/64-bit aligned. */<br>static inline void bs_flush( bs_t *s )<br>{<br> *(intptr_t*)s->p = endian_fix( s->cur_bits << s->i_left );<br> s->p += WORD_SIZE - s->i_left / 8;<br> s->i_left = WORD_SIZE*8;<br>
}<br></blockquote>Could this have something to do with the problem?<br>I'm a novice, so I'm afraid I can only report my experiences.<br><br># uname -a<br>SunOS t2000-a 5.10 Generic_137111-05 sun4v sparc SUNW,Sun-Fire-T200<br>
<br>Regards,<br><font color="#888888">--Doug</font></blockquote><div><br> Any thoughts as to whether some of the work you have done addresses this? I know memory mgt is less forgiving in SPARC...<br><br>Regards,<br>--Doug<br>
</div> </div></div></blockquote></div><br>