9474 2016-04-18 12:34:47 +0000 epiphany doesn't work on ARM 2016-11-14 13:57:39 +0000 1 1 7 Build System, Metadata & Runtime OE-Core graphics unspecified Beagleboard arm RESOLVED NOTABUG Medium+ normal 2.2 M3 1 gary gary alex.kanavin bill.randle clopez jku jose.perez.carranza liezhi.yang meta.mr.watcher meta.watcher randy.macleod ross.burton shiftee yi.zhao yi.zhao --- --- Don't know oldest_to_newest 61331 0 gary 2016-04-18 12:34:47 +0000 Running ephiphany from OE-core (poky 20a0121b558b32179220e394a66cb90dc6ff3879) doesn't work on most any ARM based target. On qemuarm, it will hang displaying most any page, on beagle* (and i.MX6) targets, accessing any page will give a message "problem displaying XXX" in the window title bar with no other information. As is, the only "official" web browser for OE-core based systems does not work on ARM. I tested this on the BeagleBoneBlack, using the default meta-yocto-bsp setup. Add 'epiphany' to the package set, e.g. CORE_IMAGE_EXTRA_INSTALL = 'epiphany' Then run core-image-sato on the board. I also tested using x11vnc (from meta-oe), as well as using 'ssh -X' with similar results. Note: epiphany seems to work fine on x86 targets. 61367 1 bill.randle 2016-04-18 23:34:04 +0000 Have you tried starting ephiphany from the command line (vs. GUI menu or icon) to see if any useful messages are printed? 61369 2 gary 2016-04-19 01:51:54 +0000 (In reply to comment #1) > Have you tried starting ephiphany from the command line (vs. GUI menu or > icon) to see if any useful messages are printed? I've done this - no informational messages are printed. 61393 3 jku 2016-04-19 12:45:55 +0000 "Problem displaying ..." is the "web process crashed" message FWIW. It's been a while since I worked with WebKit but if you're interested in debugging further, info below should still apply. debugging the web process is tricky if it crashes right out of the gate: You can do export WEB_PROCESS_CMD_PREFIX='/usr/bin/gdbserver localhost:8080' to start web processes in gdb but that only works with a debug build (which the oe-core one isn't). Alternatively you could let the web process crash at startup, and check if the UI process has started a new web process "WebKitWebProcess" which might not have crashed yet because it hasn't loaded a page... It should be possible to attach gdb to that one and then try load a new page in Epiphany to reproduce the crash. The backtrace _might_ not be very useful since we don't currently build webkit with symbols -- probably because even the release build is such a beast. more info http://trac.webkit.org/wiki/WebKitGTK/Debugging 61553 4 alex.kanavin 2016-04-22 10:11:53 +0000 A few notes from me: 1) webkit itself includes a 'minibrowser', so you can try that instead of epiphany for testing. 2) upstream tests ARM support only on the very latest versions of the architecture, ARMv5 and 6 in particular are not tested: https://build.webkit.org/builders And even on the ARM versions that are tested, there is a lot of red :( 3) try disabling JIT like is done for older ARM targets? 4) Ultimately, we don't have hardware or expertise to get to the root cause of this, so you have to take it upstream unfortunately. 61554 5 gary 2016-04-22 10:39:06 +0000 (In reply to comment #4) > A few notes from me: > > 1) webkit itself includes a 'minibrowser', so you can try that instead of > epiphany for testing. > MiniBrowser looks like it works, but I can see anything other than the WebKitGTK home page :-( All others just show blank... > 2) upstream tests ARM support only on the very latest versions of the > architecture, ARMv5 and 6 in particular are not tested: > https://build.webkit.org/builders > And even on the ARM versions that are tested, there is a lot of red :( I'm using ARMv7a (cortex-a9), so this should not be an issue. > > 3) try disabling JIT like is done for older ARM targets? Doesn't that only apply to JAVA/JS stuff? > > 4) Ultimately, we don't have hardware or expertise to get to the root cause > of this, so you have to take it upstream unfortunately. This is sad indeed that the only browser "blessed" to be in OE-core doesn't run on a large set of targets that use it :-( [There are a lot of (embedded) ARM boards out in the world!] 61559 6 alex.kanavin 2016-04-22 13:35:28 +0000 > > 4) Ultimately, we don't have hardware or expertise to get to the root cause > > of this, so you have to take it upstream unfortunately. > > This is sad indeed that the only browser "blessed" to be in OE-core doesn't > run on a large set of targets that use it :-( [There are a lot of > (embedded) ARM boards out in the world!] If you can suggest realistic alternatives, I'm all ears. There is simply no other suitable web engine out there than webkitgtk, from what I can see. 61590 7 gary 2016-04-23 05:40:53 +0000 Rebuilding webkitgtk with JIT disabled allows epiphany to work much better. Not sure of the potential performance hit, but working & slower beats broken & fast. Should I send a patch to just disable JIT for all ARM until it is proven to work? 61591 8 bill.randle 2016-04-23 14:22:06 +0000 Thanks, Gary. I just added Robert Yang as a CC on this bug, because I believe he already has a patch to disable JIT for webkitgtk for most arm arches. If not, then yes, please submit a patch. 61593 9 liezhi.yang 2016-04-25 01:08:13 +0000 (In reply to comment #8) > Thanks, Gary. I just added Robert Yang as a CC on this bug, because I > believe he already has a patch to disable JIT for webkitgtk for most arm > arches. If not, then yes, please submit a patch. The patch only disables JIT for armv4, plus with previous v5, and v6, not disable for all arm: EXTRA_OECMAKE_append_armv5 = " -DENABLE_JIT=OFF " EXTRA_OECMAKE_append_armv6 = " -DENABLE_JIT=OFF " EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF " http://cgit.openembedded.org/openembedded-core-contrib/commit/?h=rbt/arm&id=9c4cdf30a34d41ebafad827631d92d7402ee3d1f 61594 10 bill.randle 2016-04-25 02:48:08 +0000 Which, if sufficient, would be better than disabling for all ARM. Gary, what arch are you building for and will Robert's patch work for you? 61596 11 gary 2016-04-25 05:20:25 +0000 (In reply to comment #10) > Which, if sufficient, would be better than disabling for all ARM. Gary, what > arch are you building for and will Robert's patch work for you? I get failures on armv7a (i.MX6 = cortexa7, begalgbone = cortexa8) so it would be EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF " 61672 12 liezhi.yang 2016-04-26 00:45:56 +0000 *** Bug 8521 has been marked as a duplicate of this bug. *** 61673 13 liezhi.yang 2016-04-26 00:48:00 +0000 (In reply to comment #11) > (In reply to comment #10) > > Which, if sufficient, would be better than disabling for all ARM. Gary, what > > arch are you building for and will Robert's patch work for you? > > I get failures on armv7a (i.MX6 = cortexa7, begalgbone = cortexa8) so it > would be > > EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF " Hi, do you mind I take the bug update and my patches, or will you send a new patch to the mailing list, please ? 61680 14 gary 2016-04-26 05:55:23 +0000 (In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > Which, if sufficient, would be better than disabling for all ARM. Gary, what > > > arch are you building for and will Robert's patch work for you? > > > > I get failures on armv7a (i.MX6 = cortexa7, begalgbone = cortexa8) so it > > would be > > > > EXTRA_OECMAKE_append_armv7a = " -DENABLE_JIT=OFF " > > Hi, do you mind I take the bug update and my patches, or will you send a new > patch to the mailing list, please ? Please feel free to take over 61685 15 liezhi.yang 2016-04-26 09:45:44 +0000 Patch sent: http://cgit.openembedded.org/openembedded-core-contrib/commit/?h=rbt/arm&id=f9cac7c5ef750bd87551e0d56531e53afeb7f18d 61693 16 bill.randle 2016-04-26 16:08:49 +0000 Thanks, Robert! Looks good to me, however should it also include armv7ve in the list to turn off JIT? I just read it's basically the same as an armv7a with some virtual extensions, so will likely have the same problem. 61706 17 liezhi.yang 2016-04-27 03:02:11 +0000 (In reply to comment #16) > Thanks, Robert! Looks good to me, however should it also include armv7ve in > the list to turn off JIT? I just read it's basically the same as an armv7a > with some virtual extensions, so will likely have the same problem. Hi, I had planed to test armv7e, but it didnt' work in my build, so I can't confirm that. my local.conf: MACHINE = "qemuarm64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7ve" $ bitbake -p ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Toolchain tunings invalid: Tuning 'armv7ve' has no defined features, and cannot be used. 62296 18 bill.randle 2016-05-18 15:53:43 +0000 Maybe it didn't work because you started off with an arm64 base arch and the arm7ve is still a 32-bit arch. For testing purposes, I was able to get it to build by creating a qemuarm7 machine containing: #@TYPE: Machine #@NAME: generic armv7ve machine #@DESCRIPTION: Machine configuration for running a generic armv7ve require conf/machine/include/arm/arch-armv7ve.inc require conf/machine/include/qemu.inc KERNEL_IMAGETYPE = "zImage" SERIAL_CONSOLES = "115200;ttyAMA0 115200;hvc0" The resulting qemu image didn't run (probably because qemu doesn't know about arm7ve), but at least webkitgtk and epiphany both built cleanly. I still think the JIT=OFF should be included for arm7ve in your patch. 62520 19 clopez 2016-05-30 11:57:08 +0000 Hi, I'm a developer working on WebKitGTK+ upstream and we intend to support JSC JIT on ARMv7. If it is not working it is a bug and should be fixed. That's said, the cause of a blank page is usually caused because the WebKitWebProcess has crashed. This can be sometimes because of a broken JSC JIT. But can also be caused by another problems like broken (or not working as expected) GPU drivers and AC (Accelerated Compositing) mode. Or any other kind of crash on the webprocess) To help testing this there are a number of environment variables that you can play with at runtime without needing to recompile WebKitGTK+. http://trac.webkit.org/wiki/EnvironmentVariables For example, to disable the JSC JIT you can do: $ export JavaScriptCoreUseJIT=0 $ pkill -9 epiphany $ epiphany And to disable the AC (Accelerated Compositing) you can do: $ export WEBKIT_DISABLE_COMPOSITING_MODE=1 $ pkill -9 epiphany $ epiphany Test running epiphany (or MiniBrowser) with both this variables on the environment to check if any of it make a difference. If it continues to crash (you get a blank page), then it will be helpful for us if you can generate a backtrace with symbols and report it in https://bugs.webkit.org/ (CC'ing the user <bugs-noreply@webkitgtk.org>) This is usually achieved as follows: # install the webkit*-dbg packages $ ulimit -c unlimited $ pkill -9 epiphany $ epiphany # make it crash $ gdb -ex "thread apply all bt" --batch /full/path/to/WebKitWebProcess core 63186 20 ross.burton 2016-06-21 11:18:16 +0000 The JIT disabling was merged in oe-core 8d397781665ac71615e9e0a240a76272b6b63216. I'll leave this open for now in case anyone wants to revert that locally and get debugging information for Carlos. 64137 21 clopez 2016-07-18 21:05:04 +0000 I have been checking this issue. The problem is triggered because Yocto/OE is building by default with -marm (ARM traditional) instead of with -mthumb (Thumb2 instructions) for ARMv7. And it seems that the WebKitGTK+ JIT is currently broken with ARM traditional. I have forwarded this issue to upstream https://bugs.webkit.org/show_bug.cgi?id=159880 In any case I think we should to build with -mthumb by default, mainly because is what upstream tests and has a greater chance of working as expected. Its also the default option on Debian armhf. So I'm going to send a patch to the oe-core mailing list that enables -mthumb on ARMv7 for the webkitgtk build and turns back on the JSC JIT on ARMv7. 64496 22 ross.burton 2016-07-26 16:32:37 +0000 Fixed in oe-core bb7bc6061b70648635d969e66c6ed333ca5f427e. 65183 23 yi.zhao 2016-08-15 08:54:43 +0000 Verified with poky master: e274a5167ea2e495355bd1382b1388d047b845d7 Tested on qemuarm and beaglebone. 68107 24 gary 2016-11-08 17:23:18 +0000 Still doesn't work, neither on beaglebone nor my i.MX6 :-( It either shows a totally blank window or gives errors on the console such as: (WebKitWebProcess:1315): Gdk-ERROR **: The program 'WebKitWebProcess' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 154 error_code 2 request_code 0 (core protocol) minor_code 3) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. libEGL warning: DRI2: failed to authenticate Xlib: sequence lost (0x1009a > 0x9b) in reply type 0x0! Built using Poky/Yocto rev 43e652f3d1fee5ce7fad67e6400315eab1b34270 68119 25 clopez 2016-11-08 17:32:03 +0000 (In reply to comment #24) > Still doesn't work, neither on beaglebone nor my i.MX6 :-( > > It either shows a totally blank window or gives errors on the console such > as: > > (WebKitWebProcess:1315): Gdk-ERROR **: The program 'WebKitWebProcess' > received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadValue (integer parameter out of range for operation)'. > (Details: serial 154 error_code 2 request_code 0 (core protocol) > minor_code 3) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the GDK_SYNCHRONIZE environment > variable to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > not be saved or shared with other applications. > libEGL warning: DRI2: failed to authenticate > Xlib: sequence lost (0x1009a > 0x9b) in reply type 0x0! > > > Built using Poky/Yocto rev 43e652f3d1fee5ce7fad67e6400315eab1b34270 That is a different problem. You are getting here an X error, probably related with your OpenGL drivers. Try this: export WEBKIT_DISABLE_COMPOSITING_MODE=1 epiphany With that environment variable, you are telling WebKit to avoid using the accelerated compositing mode at runtime. If you are using EGL with X11, in the last release of WebKitGTK+ (2.14.2) we added some patches that workaround some issues we detected with the Vivante GPU drivers from Freescale on an i.MX6 board. 68123 26 gary 2016-11-08 17:35:55 +0000 (In reply to comment #25) > (In reply to comment #24) > > Still doesn't work, neither on beaglebone nor my i.MX6 :-( > > > > It either shows a totally blank window or gives errors on the console such > > as: > > > > (WebKitWebProcess:1315): Gdk-ERROR **: The program 'WebKitWebProcess' > > received an X Window System error. > > This probably reflects a bug in the program. > > The error was 'BadValue (integer parameter out of range for operation)'. > > (Details: serial 154 error_code 2 request_code 0 (core protocol) > > minor_code 3) > > (Note to programmers: normally, X errors are reported asynchronously; > > that is, you will receive the error a while after causing it. > > To debug your program, run it with the GDK_SYNCHRONIZE environment > > variable to change this behavior. You can then get a meaningful > > backtrace from your debugger if you break on the gdk_x_error() function.) > > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > > not be saved or shared with other applications. > > libEGL warning: DRI2: failed to authenticate > > Xlib: sequence lost (0x1009a > 0x9b) in reply type 0x0! > > > > > > Built using Poky/Yocto rev 43e652f3d1fee5ce7fad67e6400315eab1b34270 > > That is a different problem. > You are getting here an X error, probably related with your OpenGL drivers. > > Try this: > > export WEBKIT_DISABLE_COMPOSITING_MODE=1 > epiphany > > > With that environment variable, you are telling WebKit to avoid using the > accelerated compositing mode at runtime. > > If you are using EGL with X11, in the last release of WebKitGTK+ (2.14.2) we > added some patches that workaround some issues we detected with the Vivante > GPU drivers from Freescale on an i.MX6 board. Note: with the latest version, even the minibrowser (/usr/libexec/webkit2gtk-4.0/MiniBrowser) doesn't work on this hardware. 68125 27 clopez 2016-11-08 17:40:29 +0000 (In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > Still doesn't work, neither on beaglebone nor my i.MX6 :-( > > > > > > It either shows a totally blank window or gives errors on the console such > > > as: > > > > > > (WebKitWebProcess:1315): Gdk-ERROR **: The program 'WebKitWebProcess' > > > received an X Window System error. > > > This probably reflects a bug in the program. > > > The error was 'BadValue (integer parameter out of range for operation)'. > > > (Details: serial 154 error_code 2 request_code 0 (core protocol) > > > minor_code 3) > > > (Note to programmers: normally, X errors are reported asynchronously; > > > that is, you will receive the error a while after causing it. > > > To debug your program, run it with the GDK_SYNCHRONIZE environment > > > variable to change this behavior. You can then get a meaningful > > > backtrace from your debugger if you break on the gdk_x_error() function.) > > > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > > > not be saved or shared with other applications. > > > libEGL warning: DRI2: failed to authenticate > > > Xlib: sequence lost (0x1009a > 0x9b) in reply type 0x0! > > > > > > > > > Built using Poky/Yocto rev 43e652f3d1fee5ce7fad67e6400315eab1b34270 > > > > That is a different problem. > > You are getting here an X error, probably related with your OpenGL drivers. > > > > Try this: > > > > export WEBKIT_DISABLE_COMPOSITING_MODE=1 > > epiphany > > > > > > With that environment variable, you are telling WebKit to avoid using the > > accelerated compositing mode at runtime. > > > > If you are using EGL with X11, in the last release of WebKitGTK+ (2.14.2) we > > added some patches that workaround some issues we detected with the Vivante > > GPU drivers from Freescale on an i.MX6 board. > > Note: with the latest version, even the minibrowser > (/usr/libexec/webkit2gtk-4.0/MiniBrowser) doesn't work on this hardware. Have you tried to export that variable first? Also, the last version of Yocto is not the same that the last version upstream (webkitgtk.org project). I see oe-core master right now is still using 2.14.1. 68127 28 gary 2016-11-08 17:42:59 +0000 (In reply to comment #25) > (In reply to comment #24) > > Still doesn't work, neither on beaglebone nor my i.MX6 :-( > > > > It either shows a totally blank window or gives errors on the console such > > as: > > > > (WebKitWebProcess:1315): Gdk-ERROR **: The program 'WebKitWebProcess' > > received an X Window System error. > > This probably reflects a bug in the program. > > The error was 'BadValue (integer parameter out of range for operation)'. > > (Details: serial 154 error_code 2 request_code 0 (core protocol) > > minor_code 3) > > (Note to programmers: normally, X errors are reported asynchronously; > > that is, you will receive the error a while after causing it. > > To debug your program, run it with the GDK_SYNCHRONIZE environment > > variable to change this behavior. You can then get a meaningful > > backtrace from your debugger if you break on the gdk_x_error() function.) > > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > > not be saved or shared with other applications. > > libEGL warning: DRI2: failed to authenticate > > Xlib: sequence lost (0x1009a > 0x9b) in reply type 0x0! > > > > > > Built using Poky/Yocto rev 43e652f3d1fee5ce7fad67e6400315eab1b34270 > > That is a different problem. > You are getting here an X error, probably related with your OpenGL drivers. > > Try this: > > export WEBKIT_DISABLE_COMPOSITING_MODE=1 > epiphany > > > With that environment variable, you are telling WebKit to avoid using the > accelerated compositing mode at runtime. > > If you are using EGL with X11, in the last release of WebKitGTK+ (2.14.2) we > added some patches that workaround some issues we detected with the Vivante > GPU drivers from Freescale on an i.MX6 board. But this is happening on a BeagleBoneBlack which is not i.MX6+Vivante 68129 29 gary 2016-11-08 17:44:56 +0000 The real point of this bug is that I am not getting an "it works out of the box" experience for this program on any of these programs (and it is _the_ example web browser for Yocto) 68135 30 clopez 2016-11-08 17:58:01 +0000 (In reply to comment #29) > The real point of this bug is that I am not getting an "it works out of the > box" experience for this program on any of these programs (and it is _the_ > example web browser for Yocto) Sorry, the purpose of a bug report is not complaining, but helping developers to find and fix the bug. If you are interested in helping to fix the bug, then try what I suggested and report back. Also, this issue you are reporting is completely unrelated with the previous one of the JSC JIT that was already fixed. I think you should open a new bug instead of reopening this one. 68185 31 alex.kanavin 2016-11-09 13:37:22 +0000 Reality check: we don't test epiphany on ARM, and have no means to do so. So there is no "works out of the box" promise, and you should drop the assumption. Don't reopen the bug with an unrelated issue please; I'll put up with it this time, but next time you'll get a RESOLVED/INVALID and a request to file a new bug. 68187 32 gary 2016-11-09 14:03:45 +0000 (In reply to comment #31) > Reality check: we don't test epiphany on ARM, and have no means to do so. So > there is no "works out of the box" promise, and you should drop the > assumption. So is there no implied assurance that feature X works on all OE-core items? If no, I don't see how it can be considered "core". > > Don't reopen the bug with an unrelated issue please; I'll put up with it > this time, but next time you'll get a RESOLVED/INVALID and a request to file > a new bug. Sorry about that, my impression WAS that this was a regression which this bug covered. I can see now that it is not, but that does not really answer the issue of a working web browser on ARM hardware (arguably one of the largest segments of embedded devices if not THE largest) 68188 33 alex.kanavin 2016-11-09 14:05:42 +0000 Bugzilla is not the right place for this discussion. Please take it to oe-core list. 68189 34 gary 2016-11-09 14:11:17 +0000 (In reply to comment #30) > (In reply to comment #29) > > The real point of this bug is that I am not getting an "it works out of the > > box" experience for this program on any of these programs (and it is _the_ > > example web browser for Yocto) > > Sorry, the purpose of a bug report is not complaining, but helping > developers to find and fix the bug. IMHO, the purpose of bug reports is to report bugs, which is what I have done. I'm sorry if it sounded like whining... > > If you are interested in helping to fix the bug, then try what I suggested > and report back. I have tried your suggestion and got varying results. For the most part, this did allow epiphany to [mostly] render pages correctly, both on the i.MX6 and Beagle*. I tested both with SSH X11 tunneling as well as local [hardware] displays, with the same results. That said, it did still fail on the BeagleBone when I tried to access a simple WordPress site (my http://www.mlbassoc.com/ is an empty WP page). This page works correctly on the i.MX6 > > Also, this issue you are reporting is completely unrelated with the previous > one of the JSC JIT that was already fixed. I think you should open a new bug > instead of reopening this one. 68249 35 alex.kanavin 2016-11-11 13:31:05 +0000 Is there anything for Yocto project to do then? If most websites work, and there's one that does not, it looks like an upstream webkit issue, and should be filed there. And once again, when filing a bug, you absolutely have to be an active partner in developing a solution, and not just report that something doesn't work in very general terms and then act entitled to getting your problem solved. Specifically: - did you try latest upstream webkit as suggested? Updating the recipe and rebuilding is trivial. - when you say you have a webpage that fails, you need to be *specific*. How did it fail? Did you get error messages? Did the browser crash? Is it a totally blank page, or something that is incomplete or incorrectly rendered? What happened? Do consider these things in the future please; you must do your utmost to make us want to help you. 68270 36 gary 2016-11-14 13:57:39 +0000 (In reply to comment #25) > (In reply to comment #24) > > Still doesn't work, neither on beaglebone nor my i.MX6 :-( > > > > It either shows a totally blank window or gives errors on the console such > > as: > > > > (WebKitWebProcess:1315): Gdk-ERROR **: The program 'WebKitWebProcess' > > received an X Window System error. > > This probably reflects a bug in the program. > > The error was 'BadValue (integer parameter out of range for operation)'. > > (Details: serial 154 error_code 2 request_code 0 (core protocol) > > minor_code 3) > > (Note to programmers: normally, X errors are reported asynchronously; > > that is, you will receive the error a while after causing it. > > To debug your program, run it with the GDK_SYNCHRONIZE environment > > variable to change this behavior. You can then get a meaningful > > backtrace from your debugger if you break on the gdk_x_error() function.) > > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will > > not be saved or shared with other applications. > > libEGL warning: DRI2: failed to authenticate > > Xlib: sequence lost (0x1009a > 0x9b) in reply type 0x0! > > > > > > Built using Poky/Yocto rev 43e652f3d1fee5ce7fad67e6400315eab1b34270 > > That is a different problem. > You are getting here an X error, probably related with your OpenGL drivers. > > Try this: > > export WEBKIT_DISABLE_COMPOSITING_MODE=1 > epiphany > > > With that environment variable, you are telling WebKit to avoid using the > accelerated compositing mode at runtime. > > If you are using EGL with X11, in the last release of WebKitGTK+ (2.14.2) we > added some patches that workaround some issues we detected with the Vivante > GPU drivers from Freescale on an i.MX6 board. I have now tried 2.14.2 with the exact same results. I also tried to build for qemuarm (armv5) and webkitgtk no longer builds at all. What's the best place to report these results - directly to webkit or Yocto?