Unity8-dash on Intel Atom graphics crashes and restarts continuously [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, EglContext) == EGL_TRUE"]

When this happens you should actually be able to press Esc to recover the greeter. You can also press Ctrl+Alt+F1 and log in there, following by "sudo service lightdm restart", that will restart the display manager.

That said, can you please clear /var/log/lightdm and ~/.cache/upstart/, try logging in to the unity8 session and collect the logs from both directories and attach here?

Oh and also ~/.xsession-errors might be interesting - delete it as well before trying to log in a Unity8 session.

I did what you told me, but after pressing esc telling me that the password was wrong, but he was right, then I rebooted I pressed esc and the same thing happened to me, after I pressed ctrl + alt + f1 and I I added the command that you told me, but I would say again that the password is wrong

I tried without pressing esc and I was able to access, after putting the command restarts the screen but the problem is not resolved. how can I clean those libraries that you wrote me?

ok I did everything you told me including cleaning of those libraries, but it still does not work

I managed somehow to get in, but I do not open the applications and remain with the load wheel to 'infinity

We know about this issue and it's probably bug 1536662 you are seeing.

I hope to get some attention to this in the coming days.

By the way, the screenshot in comment #1 is what I see too (after bug 1536662 has timed out, Mir crashes and returns you to a broken login screen)

Although if your USC/Unity8 is crashing for some other reason than bug 1536662, I guess you would also see the same broken login screen.

So it really depends: Does it take 30 seconds to return you to the login screen or is it immediate?

Please attach these files so we can find out what the cause is:
  ~/.cache/upstart/unity8.log
  /var/log/lightdm/unity-system-compositor.log

But now the situation has changed, because I can not access but the cursor is slow and no application is opened, remains in loading, even the scope opens

how do I get those logs?

To get the logs you will need to:

1. Reboot and log into Unity 7 (not Unity8)
2. Open a terminal with Ctrl+Alt+T
3. Run: cp ~/.cache/upstart/unity8.log ~/Documents/
4. Run: sudo cat /var/log/lightdm/unity-system-compositor.log > ~/Documents/unity-system-compositor.log
5. Now open your web browser and attach the two files from your Documents folder to this bug.

Please note the above steps will only be helpful if you could not log in previously. If you did log in per comment #11 then please do not attach those files to this bug.

If the cursor is slow, that is likely bug 1539009 which we will release a fix for soon.

And if no applications open, please log a new bug for that here:
https://bugs.launchpad.net/ubuntu/+source/unity8/+filebug

emanuele@emanuele-AOD255:~$ cp ~/.cache/upstart/unity8.log ~/Documenti/
cp: impossibile eseguire stat di '/home/emanuele/.cache/upstart/unity8.log': File o directory non esistente
emanuele@emanuele-AOD255:~$ sudo cat /var/log/lightdm/unity-system-compositor.log > ~/Documents/unity-system-compositor.log
bash: /home/emanuele/Documents/unity-system-compositor.log: File o directory non esistente
emanuele@emanuele-AOD255:~$

not load

OK, try this then:

$ cp ~/.cache/upstart/unity8.log.1.gz ~/Documenti/
$ sudo zcat /var/log/lightdm/unity-system-compositor.log.1.gz > ~/Documents/unity-system-compositor.log

ok, i have send them

ok?

Thanks for the logs. That explains a lot, and I hope it's not a problem specific to your Intel Pineview hardware...

Mir 0.19.3 worked once, but mostly failed to start (Failed to find platform for current system). The new Mir 0.20.0 seems to be working more consistently for you.

Now that you can get Unity8 on screen, it seems to be just Unity8 issues remaining. I wonder if I can get a 10" Pineview netbook like yours to test on...

you managed to find a computer with graphic Pineview?

No, it will take me weeks/months to source that hardware. If I can get it at all cheaply...

In the meantime, can you please describe more about the problems you see in Unity8 (comment #11)?

no nothing, when I entered seemed to me the scope of the window loaded with the wheel but you never opened

Can you please take a photo or screenshot and attach it here?

but because if I open an app for unity 8 ( in this case the browser ) in unity 7 it starts and runs ?

It remains indefinitely

I have an intel atom catching some dust here. As long as pineview does not contain the GMA 500 poulsbo gpu.. it should be a similar chip.

And what happens is, that unity8-dash keeps restarting. Last time I tracked that down this was due to lack of GL 2.0 support in mesa for that cpu. Just upgrading now, to check if this is still the case.

Ok thanks you for signing interested

Any update?

Yes I believe there is still a problem setting up the rendering context. When I run unity8-dash in isolation I get this:
file:///usr/share/unity8//Dash/Dash.qml:39: ReferenceError: window is not defined
file:///usr/share/unity8//Dash/Dash.qml:265: ReferenceError: scopeStyle is not defined
ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE" in file ../../../src/ubuntumirclient/glcontext.cpp, line 71

A failure there will affect all qt applications..

then?

Mesa in Ubuntu has a patch for i915 that disables OpenGL 2.0 but not GLES 2,0. Thats why all mir clients and the unity8 session starts up.. since mirserver always use GL|ES.

Regular qt clients do the EGL init in a different path and they insist on GL 2.0.

When you recompile mesa without that patch you get the unity8 desktop but it is just too slow.. It would be better to implement a less demanding QtQuick backend .. and/or use a different mir compositor..

i915 does not have native shader support so mesa simulate that with llvmpipe, using i915 only for blitting.. So a less demanding - (but also not existing) fixed-function gl-1.x backend is the probably your best chance to use that gpu with unity8.

Ok

I've mentioned the possibility of a GL 1.x backend before in other bugs (somewhere...). While it's a fun thought, the problem I recall is that GL 1.x may not provide any sufficient EGLImage binding extensions (which we need to get client window contents on screen). Without that you will forever just see the shell but can't see the client window contents.

Then i don't have possibility for use unity8?

Nothing is impossible and you should not assume all the above comments are always relevant and accurate :)

Status changed to 'Confirmed' because the bug affects multiple users.

Today I tried again (with ubuntu 16.10) to reopen unity8, the session is very fast game more than usual (it was from 2 weeks since the felt) but still the applications do not work and remain in their infinite loading. the cursor was displayed very large and it was slow (although I think it is caused by failure of applications open)

Using mir 0.21 and unity8.12+16.10.201605.18

Hi Emanuele,
you attached a branch of mine to this bug - it makes our GL/EGL managing code more robust. I had hoped it would fix this issue, but unfortunately it doesn't. That's why I didn't attach that branch to this bug.

Annoyingly I don't have the hardware to hand either, so I'm flying slightly blind. I make a change, then ask someone else to test it. I'll have access to the hardware in about 2 weeks time, hopefully I'll have a breakthrough then.

In the mean time, I've assembled some diagnostic applications that might help me out.

If you're feeling adventurous, grab and compile lp:~gerboland/+junk/qteglchooser/

Run it with
 ./qteglchooser -o
and
 ./qteglchooser -o -i
and pastebin me the output.

It's a tool I made to try explain how Qt is deciding which EGL
configuration to use. Qt can end up jumping through many hoops figuring
out a good EGL config, but also I might be using it slightly wrong
(hence the -i switch).

I would also appreciate if you could please grab, compile, run and
pastebin me the output of lp:~gerboland/+junk/eglinfo

That just prints the EGL configurations available, plus other EGL stuff.

Hi Gerry,
I'm sorry if I'm not very experienced, but could you explain the full procedure to download it and run? I am interested in trying it

Hey Emanuele,
Albert got me the data I wanted from those tools, and the results are still inconclusive. I think I need access to the hardware to make real progress on this. So there's no need to bother with the trying those tools.

If you fancy a go, just to play:
1. Install build dependencies (I don't know if I have all here):
sudo apt install bzr build-essential qtbase5-dev qtbase5-private-dev

2. Download the code:
bzr branch lp:~gerboland/+junk/qteglchooser/
cd qteglchooser/

3. Compile:
qmake
make

You should get a qteglchooser binary, that you can then run as above.

I currently have a problem with the internet and the network is down, but if you say you have not had good results does not know what to do

Ok, progress, my tools can exhibit the problem:
http://pastebin.ubuntu.com/16677278/

Problems include:
1. libEGL warning: DRI3: xcb_connect failed <- should not be trying that
2. EGL version: 8.-1225087968 <- this is garbage

I suspect that there is an issue with EGL.

Forgot to say, that was reproduced running the qteglchooser while there was no X server running, instead just a Mir server running.

It is a good thing that you are able to find the problem? It is fixable?

Ok, I figured out hte EGL issue, it was my misunderstanding. Modifying the tools to act correctly, I get this for eglinfo:
http://pastebin.ubuntu.com/16686113/
and the qteglchooser correctly chooses a valid Mir EGL config. Why Qt itself cannot do this, I have yet to understand.

Ok, I suspect I have found the issue. Seems this hardware only supports OpenGL 1.4 compatibility profile. Qt's EGL code is asking for at least version 2.0, and so getting no valid context back.

Could you please install "mesa-utils" package and run "glxinfo". On the hardware I have access to, I see these lines in the output:

    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 1.4
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0

I need to figure out why the X11 glx code is working, but the EGL code is not. I also need to understand why at least OpenGL2.0 is desired by Qt.

An option is to use GLES2 on this hardware, but as the GL/GLES switch is made in Qt at compile time, that won't be straightforward either.

/me has to stop using "Ok, " at the start of his sentences

@Gerry hahaha

name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample,
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
    GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample,
    GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
    GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float,
    GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB,
    GLX_ARB_get_proc_address, GLX_ARB_multisample,
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Pineview M (0xa011)
    Version: 11.2.1
    Accelerated: yes
    Video memory: 384MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 1.4
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Pineview M
OpenGL version string: 1.4 Mesa 11.2.1
OpenGL extensions:
    GL_3DFX_texture_compression_FXT1, GL_AMD_shader_trinary_minmax,
    GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5,
    GL_APPLE_...

this is the result of that unity 7

Gerry:
I would say you're looking in the wrong place asking GLX, but can confirm the same results with EGL: Full desktop OpenGL on Pineview is limited to 1.4, but GLES is version 2.0. Also: https://www.opengl.org/wiki/FAQ#Why_is_my_GL_version_only_1.4_or_lower.3F

But I don't think this is a problem at all. Right now I can see Mir demo servers running perfectly on Pineview in either mode with full hardware acceleration (no fallbacks) and even full desktop GLSL support at version 1.20 ...

mir_proving_server from lp:mir - GLESv2 default build:

[2016-05-27 12:02:05.879585] GLRenderer: EGL vendor: Mesa Project
[2016-05-27 12:02:05.879710] GLRenderer: EGL version: 1.4 (DRI2)
[2016-05-27 12:02:05.880050] GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[2016-05-27 12:02:05.880144] GLRenderer: EGL extensions: EGL_EXT_buffer_age EGL_KHR_create_context EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_surfaceless_context EGL_MESA_configless_context EGL_MESA_drm_image EGL_WL_bind_wayland_display
[2016-05-27 12:02:05.880215] GLRenderer: GL vendor: Intel Open Source Technology Center
[2016-05-27 12:02:05.880357] GLRenderer: GL renderer: Mesa DRI Intel(R) Pineview M
[2016-05-27 12:02:05.880432] GLRenderer: GL version: OpenGL ES 2.0 Mesa 11.2.0
[2016-05-27 12:02:05.880492] GLRenderer: GLSL version: OpenGL ES GLSL ES 1.0.16
[2016-05-27 12:02:05.880554] GLRenderer: GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888 GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_fbo_color_attachments GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_OES_surfaceless_context GL_EXT_separate_shader_objects GL_EXT_draw_elements_base_vertex GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
[2016-05-27 12:02:05.880664] GLRenderer: GL max texture size = 2048
[2016-05-27 12:02:05.880767] GLRenderer: GL framebuffer bits: RGBA=8888, depth=0, stencil=0

mir_proving_server from lp:mir with desktop OpenGL (-DMIR_SERVER_LIBGL=libGL):

[2016-05-27 12:03:13.811224] GLRenderer: EGL vendor: Mesa Project
[2016-05-27 12:03:13.811352] GLRenderer: EGL version: 1.4 (DRI2)
[2016-05-27 12:03:13.811413] GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[2016-05-27 12:03:13.811586] GLRenderer: EGL extensions: EGL_EXT_buffer_age EGL_KHR_create_context EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image...

Shorter version:

mir_proving_server from lp:mir - GLES v2 works:

[2016-05-27 12:02:05.879585] GLRenderer: EGL vendor: Mesa Project
[2016-05-27 12:02:05.879710] GLRenderer: EGL version: 1.4 (DRI2)
[2016-05-27 12:02:05.880050] GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[2016-05-27 12:02:05.880215] GLRenderer: GL vendor: Intel Open Source Technology Center
[2016-05-27 12:02:05.880357] GLRenderer: GL renderer: Mesa DRI Intel(R) Pineview M
[2016-05-27 12:02:05.880432] GLRenderer: GL version: OpenGL ES 2.0 Mesa 11.2.0
[2016-05-27 12:02:05.880492] GLRenderer: GLSL version: OpenGL ES GLSL ES 1.0.16
[2016-05-27 12:02:05.880664] GLRenderer: GL max texture size = 2048
[2016-05-27 12:02:05.880767] GLRenderer: GL framebuffer bits: RGBA=8888, depth=0, stencil=0

mir_proving_server from lp:mir with desktop OpenGL (-DMIR_SERVER_LIBGL=libGL):

[2016-05-27 12:03:13.811224] GLRenderer: EGL vendor: Mesa Project
[2016-05-27 12:03:13.811352] GLRenderer: EGL version: 1.4 (DRI2)
[2016-05-27 12:03:13.811413] GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[2016-05-27 12:03:13.811784] GLRenderer: GL vendor: Intel Open Source Technology Center
[2016-05-27 12:03:13.811880] GLRenderer: GL renderer: Mesa DRI Intel(R) Pineview M
[2016-05-27 12:03:13.812004] GLRenderer: GL version: 1.4 Mesa 11.2.0
[2016-05-27 12:03:13.812241] GLRenderer: GLSL version: 1.20
[2016-05-27 12:03:13.813381] GLRenderer: GL max texture size = 2048
[2016-05-27 12:03:13.813769] GLRenderer: GL framebuffer bits: RGBA=8888, depth=0, stencil=0

Using simple test apps (lp:~gerboland/+junk/openglwindow & lp:~gerboland/+junk/qquickwindow-debug), it appears that yes Qt is using OpenGL 1.4 on X for both raw GL and QtQuick apps.

./qquickwindow-debug
Window format: QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile 0)
Context format: QSurfaceFormat(version 1.4, options QFlags(0x4), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile 0)
GLES: false

The "Context format: ... version 1.4" the thing to look for.

The EGL backend for Qt (X uses the GLX backend) is requiring OpenGl2 or greater (since that is what the Window is asking for), but the GLX backend seems to ignore that request, and just work.

I've updated the attached branch with my proposed fix.

@Gerry, have you tested it on pineview hardware?

@Emanuele yes I did - but only via SSH. A colleague will verify it works visually before approving

@Gerry Ok thanks!

it works?

Yep. The branch has been approved, will take a while to get it landed.

Note that it will be almost unusable until bug 1585723 is resolved.

Thanks!!!

roughly how long should we wait?

This bug was fixed in the package qtubuntu - 0.62+16.10.20160614-0ubuntu1

---------------
qtubuntu (0.62+16.10.20160614-0ubuntu1) yakkety; urgency=medium

  [ Daniel d'Andrada ]
  * Generate better mir session names

  [ Gerry Boland ]
  * Convert UbuntuOpenGLContext to use QEGLPlatformContext, and allow
    clients to customize chosen GLConfig (LP: #1507817, #1549455)
  * Integration: no need for the non-const versions of createWindow and
    createGLContext

  [ Nick Dedekind ]
  * Support for cross building

 -- Albert Astals Cid <email address hidden> Tue, 14 Jun 2016 08:34:32 +0000

I've Tried it but is very very slow!

Had to revert this due to bug #1594198, stay tuned.

and now that the fix is ​​no longer present, when will solve this bug? Now you can not use more

?

one day we will never use Unity 8 on Atom?

Of course we will. We need to re-land the fix. It was reverted because it broke something else, but that's been solved now. Sorry for the delay, but it takes time to get things done just right.

When?

Added to the description that Cherryview (Braswell 14nm Atom with Broadwell-level 8th gen Intel graphics) seems similarly affected. I can test fixes.

Correcting, err, the fifth time worked or something which I guess couldn't be possible with this bug. Also I did not find the EGL error from unity8-dash.log. Sorry for the noise.

I've already confirmed Cherryview is not affected by this bug. But I'll update and check again.

I confirm that the atom N470 processor is affected by this bug.

With the last version of QtUbuntu mir and unity8 work on Atom, thanks Gerry! It is very slow ( but faster than the old EGL convenience version) but it works.

Fix reapplied in lp:qtubuntu r335 and now fix released to yakkety in:
  qtubuntu 0.63+16.10.20160809-0ubuntu1