> On Nov 23, 2016, at 1:26 PM, Robert P. J. Day <[email protected]> wrote: > > 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? >
I meant version of mozjs >>> On Nov 23, 2016, at 10:34 AM, Robert P. J. Day > <[email protected]> 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? > > -- > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
