Bug 40962

Summary: [Arrandale/classic] kwin crashes with new xf86-video-intel 2.16.0 with both OpenGL and GLES
Product: Mesa Reporter: Sven Eden <yamakuzure>
Component: Drivers/DRI/i965Assignee: Chad Versace <chadversary>
Status: CLOSED FIXED QA Contact:
Severity: critical    
Priority: medium    
Version: 7.11   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Crash info with debugging symbols

Description Sven Eden 2011-09-17 04:55:10 UTC
OS: Gentoo x64 - Built from source
Tested with: (+ = enabled, - = disabled)
1.: Mesa: +egl -gallium -gbm +llvm -openvg -shared-dricore +shared-glapi
    kwin: +gles -opengl
2.: Mesa: +egl +gallium +gbm +llvm +openvg +shared-dricore +shared-glapi
    kwin: -gles +opengl
3.: Mesa: -egl +gallium -gbm +llvm -openvg -shared-dricore +shared-glapi
    kwin: -gles +opengl

First: Gallium Drivers don't work at all with i965, I have to chose the classic variant.

The settings under number 1. work flawlessly with intel drivers version 2.15.0, but the new version 2.16.0 do not work in any of the listed combinations. I have tested with kwin 4.7.0 and 4.7.1.

A bug at kde.org can be found here: https://bugs.kde.org/show_bug.cgi?id=280324 - The reaction was: "We cannot do anything about driver crashes. Please report to Intel devs.".

However, the linked bug holds Backtraces of the crash. I will add another one with OpenGL used (The Backtraces currently only show GLES) in a few minutes.
Comment 1 Sven Eden 2011-09-17 05:46:17 UTC
I have now succeeded using kwin-4.7.1 with intel drivers 2.16.0 and mesa 7.11.

- kwin has to be compiled with OpenGL instead of GLES backend
- kwin has to be ensured to use DirectRendering and V2 Shaders
- mesa was compiled with support for egl, gbm, openvg, shared-dricore and shared-glapi and set to classic drivers (Gallium doesn't work for i965 anyway)

The resulting configure line for mesa 7.11 was:

./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-option-checking --with-driver=dri --disable-glut --without-demos --enable-xcb --disable-debug --enable-gbm --enable-glw --enable-motif --enable-glx-tls --enable-asm --enable-shared-dricore --enable-shared-glapi --with-dri-drivers=,swrast,i810,i915,i965 --with-gallium-drivers=,swrast,i915,i965 --enable-texture-float --disable-gles1 --disable-gles2 --enable-egl --enable-openvg --with-egl-platforms=x11,drm --enable-gallium-egl --with-state-trackers=glx,dri,egl,vega --enable-gallium-llvm

But the question remains, why kwin-4.7.0/1 worked with GLES support using intel drivers 2.15.0 while the newer drivers crash.
Comment 2 Franz Fellner 2012-05-05 23:16:34 UTC
I have this issue with kwin-4.8.2/4.8.3 and xf86-video-intel-2.19.0.
2.18.0 worked fine until kwin-4.8.2.
I also reported this issue on bugs.kde.org, with the same result - closed:
https://bugs.kde.org/show_bug.cgi?id=299420
This report contains a complete backtrace, nevertheless here the most recent calls:
#6  0x00007fe82e598059 in ?? () from /usr/lib64/dri/i965_dri.so
#7  0x00007fe82e591f01 in ?? () from /usr/lib64/dri/i965_dri.so
#8  0x00007fe82e59f2ad in ?? () from /usr/lib64/dri/i965_dri.so
#9  0x00007fe846cb6354 in KWin::SceneOpenGL::Texture::load (this=<optimized out>, pix=<optimized out>, size=..., depth=32, region=...) at /var/tmp/paludis/kde-base-kwin-4.8.3/work/kwin-4.8.3/kwin/scene_opengl_glx.cpp:679
#10 0x00007fe846cb3f93 in load (depth=32, size=..., pix=@0x7fff1d5a7158: 27341815, this=0x26b1cb0) at /var/tmp/paludis/kde-base-kwin-4.8.3/work/kwin-4.8.3/kwin/scene_opengl.cpp:316

I have built the xf86-video-intel with -ggdb -g3 and completely disabled splitting of debugging symbols, nevertheless I don't get the symbols (even after reboot). Is there a way to make them appear in the backtrace?
Comment 3 Franz Fellner 2012-05-05 23:30:30 UTC
Created attachment 61082 [details]
Crash info with debugging symbols

I realised, that i965_dri.so comes with mesa, so I rebuilt mesa with -g3 -ggdb and disabled splitting, resulting in the above backtrace.
Comment 4 Franz Fellner 2012-05-06 00:07:18 UTC
Sorry for the next followup, but I saw that there were inlined function calls...
I passed "-fno-inline -fno-inline-functions -fno-default-inline" resulting in this backtrace (only calls inside i965_dri.so):

#6  intel_miptree_release (mt=0x220) at intel_mipmap_tree.c:290
#7  0x00007fa5aecf1b65 in intel_process_dri2_buffer_with_separate_stencil (intel=0x25211a0, buffer=0x2ccd678, rb=0x2e86ce0, buffer_name=<optimized out>, drawable=<optimized out>) at intel_context.c:1269
#8  0x00007fa5aecf1f40 in intel_update_renderbuffers (context=<optimized out>, drawable=0x23ea940) at intel_context.c:361
#9  0x00007fa5aecffadd in intelSetTexBuffer2 (pDRICtx=0x2507740, target=3553, texture_format=8410, dPriv=0x23ea940) at intel_tex_image.c:335
Comment 5 Sven Eden 2012-05-07 00:41:43 UTC
(In reply to comment #3)
> Created attachment 61082 [details]
> Crash info with debugging symbols
> 
> I realised, that i965_dri.so comes with mesa, so I rebuilt mesa with -g3 -ggdb
> and disabled splitting, resulting in the above backtrace.

Are you using Gentoo, too? If you do I have it working with the following USE-Flags:

x11-drivers/xf86-video-intel-2.19.0 (dri sna -glamor)
media-libs/mesa-8.0.2 (classic egl g3dvl gallium gbm gles1 gles2 llvm nptl openvg osmesa shared-dricore shared-glapi video_cards_i965 video_cards_intel xvmc -bindist -d3d -debug -kernel_FreeBSD -pax_kernel -pic -selinux -vdpau -video_cards_i915 -video_cards_nouveau -video_cards_r100 -video_cards_r200 -video_cards_r300 -video_cards_r600 -video_cards_radeon -video_cards_vmware -wayland -xa)
kde-base/kwin-4.8.3 (gles opengl -aqua -debug)
Comment 6 Franz Fellner 2012-05-07 04:43:02 UTC
Yes, I'm using Gentoo.
Use-Flags for mesa/kwin/xf86-video-intel look nearly the same for me, execpt mesa: I had not enabled g3dvl, shared-dricore and xvmc. As g3dvl and xvmc should not change anything here, I just enabled shared-dricore. It did not help. Alt+Tab (=> cover switch) for ~3 seconds -> crash.
Running Mesa-8.0.2 and kde-4.8.3 on sandybridge with HD 3000.
Comment 7 Sven Eden 2012-05-07 09:18:35 UTC
Which libdrm are you using? This is a shot in the dark, but my laptop is an Intel Core i7 M640 (integrated HD, too, but Arrandale not Sandybridge) and it is working fine.

x11-libs/libdrm-2.4.33 (libkms video_cards_intel -static-libs -video_cards_nouveau -video_cards_omap -video_cards_radeon -video_cards_vmware)

Just for the record:
x11-base/xorg-server-1.12.1 (doc kdrive nptl udev xnest xorg xvfb -dmx -ipv6 -minimal -selinux -static-libs -tslib)

And as those are relevant for kwin:
x11-libs/qt-gui-4.8.1-r1 (accessibility cups dbus egl exceptions gif glib mng pch qt3support tiff xinerama xv -aqua -c++0x -debug -gtkstyle -nas -nis -qpa -trace)
x11-libs/qt-opengl-4.8.1 (egl exceptions pch qt3support -aqua -c++0x -debug -qpa)
Note that both are using EGL!

---

Note: Although it *might* come down to a configuration issue of the proper versions and USE flags within the gentoo package management, I appreciate your backtraces, as a hardware driver should not crash all of a sudden without the slightest hint what could be wrong. /Maybe/ there is a bug in there, which the intel gfx devs can find (and eventually fix) this way.
However, maybe we should move further discussion of Gentoo specific configuration issues to the gentoo forums? ;)
Comment 8 Chad Versace 2012-05-07 10:56:25 UTC
This bug looks very similar to a bug in mesa:src/mesa/drivers/dri/intel/intel_context.c that I and nobled fixed on master and 8.0. I forgot to cherry-pick the bugfix to 7.11.

This bug only appears on Sandybridge and Ivybridge with xf86-video-intel >= 2.16.

Sven, today I will upload a personal 7.11 branch for you to test. If your bug is fixed by that branch, then I will cherry-pick the fix to 7.11 and request that the maintainer roll a new 7.11 release.
Comment 9 Chad Versace 2012-05-07 11:15:47 UTC
Marking as ASSIGNED. I'm working on it.
Comment 10 Chad Versace 2012-05-07 11:39:48 UTC
Please disregard my comment #8. There is an overload of information in this discussion. I was confused by the Franz's backtrace; I believed it was Sven's; and my comments were targeted at that backtrace.

Let's sort things out.

--------

Franz, you have different a chipset (Arrandale vs Sandybridge) and a different backtrace than Sven. Please file a separate bug report. I don't believe your bug is related. With your bug report, please submit a backtrace and the output of `lspci -nn | grep 8086`.

--------

Sven, I see that in your original KDE bug report, you have submitted several backtraces that have crashed at different points. Let's try to solve one backtrace at a time. Please do the following to help me isolate the problem.

1. Submit the output of `lspci -nn | grep 8086`.

2. Submit the exact version of Mesa. Is it 7.11, 7.11.1, 7.11.2, or is it the 7.11 branch from the git repo? If git, then what is the sha?

2. Build Mesa with the configuration below. The important options here are that gallium, gles, and unneeded egl platforms are disabled.

./configure \
  --prefix=/usr \
  --build=x86_64-pc-linux-gnu
  --host=x86_64-pc-linux-gnu \
  --mandir=/usr/share/man \
  --infodir=/usr/share/info \
  --datadir=/usr/share \
  --sysconfdir=/etc \
  --localstatedir=/var/lib \
  --libdir=/usr/lib64 \
  --disable-option-checking \
  --disable-glut
  --without-demos \
  --enable-xcb \
  --enable-debug \
  --enable-glw \
  --enable-asm \
  --enable-egl \
  [comment:  I really care only about the options below. The options above I listed only for completeness' sake because I saw them in your comment #1.]
  --with-egl-platforms=x11 \
  --enable-glx-tls \
  --enable-shared-dricore
  --enable-shared-glapi \
  --with-dri-drivers=swrast,i965
  --with-gallium-drivers= \
  --enable-texture-float \
  --disable-gles1 \
  --disable-gles2 \

3. Submit a backtrace for a crash.

You may also want to try the Mesa 8.0 branch. Your bug may already be fixed there.
Comment 11 Sven Eden 2012-05-08 05:00:43 UTC
First of all, thank you very much! I had a feeling all those backtraces could be too much at once. This always clashes horribly with the desire to provide information as complete as possible. ;)

However, please note that I did not have any issues since intel driver version 2.17.0 and mesa 8.0.

The versions I am using:
libdrm-2.4.33
mesa-8.0.2
xf86-video-intel-2.19.0

Franz, did you upgraded the intel driver but not mesa by chance?
Comment 12 Chad Versace 2012-05-10 11:42:47 UTC
(In reply to comment #11)
> However, please note that I did not have any issues since intel driver version
> 2.17.0 and mesa 8.0.

Sven, do you still want to pursue fixing the bug on Mesa 7.11? If not, then we can close this bug.
Comment 13 Sven Eden 2012-05-14 10:47:01 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > However, please note that I did not have any issues since intel driver version
> > 2.17.0 and mesa 8.0.
> 
> Sven, do you still want to pursue fixing the bug on Mesa 7.11? If not, then we
> can close this bug.

Yes, you are absolutely right. Unfortunately Franz did not add himself to the CC-list, so he won't get a notification.

However, Franz, if you come back, my user name in the gentoo forums is "Yamakuzure", please PM me there if you still have problems getting this up and running. (But I bet the solution there is to update to latest Mesa-8.x, too.)

Thanks again for your help, Chad, and sorry for the confusion. ;)
Comment 14 Franz Fellner 2012-05-16 08:10:19 UTC
I have bookmarked this topic and follow it. But I just did not want to further confuse people and opened a seperate bug as I was told:
https://bugs.freedesktop.org/show_bug.cgi?id=49619

I am running latest (stable) software stack:
mesa-8.0.2
libdrm-2.4.33 (2.4.34, as soon as it is unmasked)
kernel-3.3.5 (3.3.6 after the next sync)
on top of this, xf86-video-intel-2.19.0 causes problems, 2.18.0 does not.
Comment 15 Chad Versace 2012-05-16 10:54:27 UTC
Marking CLOSED/FIXED.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.