[oe] mozjs/unhandled signal 11/64k page patch/__powerpc64__ ???

Robert P. J. Day rpjday at crashcourse.ca
Wed Nov 23 21:26:30 UTC 2016


On Wed, 23 Nov 2016, Khem Raj wrote:

> can you reproduce it on version 24 as well ?

  not sure what you mean ... this is running on a qemuppc image. i
haven't tried running this on fedora 24 itself. what exactly do you
want me to try?

> > On Nov 23, 2016, at 10:34 AM, Robert P. J. Day
<rpjday at crashcourse.ca> wrote:
> >
> >
> >  i know nothing about this issue, i'm asking on behalf of a colleague
> > who has allegedly tracked down a bug in wind river linux, and
> > comparing sources, it *appears* the very same thing would happen in
> > OE.
> >
> >  the symptom running "poweroff" in a qemuppc session;
> >
> > ... snip ...
> > polkitd[680]: unhandled signal 11 at 00000000 nip 0fa69198 lr 0fa69174code 30001
> > ... snip ...
> >
> > further investigation shows the very same thing happening with:
> >
> > # systemctl start httpd
> > polkitd[680]: unhandled signal 11 at 00000000 nip 0fa69198 lr 0fa69174code 30001
> > Error getting authority: Error initializing authority: Error calling
> > StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached
> > (g-io-error-quark, 24)
> > Failed to start httpd.service: Connection timed out
> > #
> >
> >  to make a long story short, said colleague followed bug reports and
> > ended up here:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1289432
> >
> > eventually, he got the problem to go away by tweaking the patch
> > "0005-aarch64-64k-page.patch" for mozjs with the following adjustment:
> >
> > @@ -113,7 +113,7 @@ struct Cell
> > #if defined(SOLARIS) && (defined(__sparc) || defined(__sparcv9))
> > const size_t PageShift = 13;
> > const size_t ArenaShift = PageShift;
> > -#elif defined(__powerpc__)
> > +#elif defined(__powerpc__) || defined(__aarch64__)
> >               ^^^^^^^^^^^ change that to __powerpc64__
> > const size_t PageShift = 16;
> > const size_t ArenaShift = 12;
> > #else
> >
> >  as my colleague reads it, the original patch above is necessary for
> > PPC64, but *breaks* PPC32. i haven't followed the logic, but does any
> > of this make sense? by making that change, the error went away and
> > things work fine.
> >
> >  thoughts?




More information about the Openembedded-devel mailing list