On 04/17/2012 02:16 PM, j wrote:
On 04/17/2012 01:17 PM, j wrote:
On 04/17/2012 12:49 PM, j wrote:
On 04/17/2012 12:34 PM, Mark Hatle wrote:
On 4/17/12 2:09 PM, j wrote:
On 04/17/2012 09:13 AM, J. L. wrote:
<snip>
<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel>
I went for a build on the borrowed machine again but this time I
did not
go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are
no QA
logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on
the
laptop builds and eliminates the issues as well.
Will post back once I have built the kernel on both machines with
no X
running.
There is a known issue w/ nvidia drivers, segfaulting and QEMU. Is
something in perl (or elsewhere) trying to run qemu to finish up a
task?
--Mark
Not that I can tell, but that does not mean it is not (still
learning things), but possible one of threads is working on
something perl related when it happens and I am not seeing it or
realizing it. If you are willing to post the commands I could run to
check, I can post the results. But when I do just a bitbake -c
compile perl on a clean build dir all I would see was the segfault
in dmesg and the results in QA log. Nothing would show up on the
command line that was not in the QA log, after doing each step one
by one.
But it must be related to this known issue with nvidia. Should be a
couple hours before both machines finish building the kernel and
perl, will post the results after. But looks promising for my laptop
so far as no segfaults yet. Borrowed machine is on to building the
kernel now and nothing posted yet.
Thank you for your response very appreciated. I will also read more
about the issue you stated.
From what I am reading about this is its related to libgl. But on the
machine I borrowed I used nouveau driver's which uses the libgl that
is expected not the nvidia's supplied version. So maybe that is not
fully it. But still all seems related to being in an X environment
for me when building. Which is at least easy to work around.
Will post if it segfaults again on either machine once they are done.
My borrowed machine segfaulted while finishing building perl. So I
guess that had nothing to do with the segfault issues. I ended up with
the same qa.log output and same type of output on dmesg relating to
libc and ld again.
Laptop no X on that segfaulted in the normal places
Should I try installing Ubuntu 10.04 on the borrowed machine and
seeing if the OS works on that machine? I am still lost as nothing
seems to really be telling me what is segfaulting. The rest of the
logs basically look the same as the series I posted earlier.
Well finally caught what I think is the package the segfault kicks on
expat. Though not sure what I should look for to be able to sort it out
but will see where I get.
Though I still get the gcc and bash messages in the QA log. If anyone is
willing to share some info on what or how I can figure out how to find
what causes the segfault in the recipe or if I am even catching the
correct one.
Thank you
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
