Intel i915 Chipset crashes

[RJ Skerry-Ryan]

This is a tracking bug for issues in the Intel i915 driver implementation on Linux.

Some users are seeing crashes related to Intel i915 chipsets on Linux.

The tell-tale sign is a segfault on launch:

mixxx: i915_fragprog.c:1225: i915BindProgram: Assertion `p->on_hardware == 0' failed.

This has been reported on Archbang, Debian Sid, Manjaro, and Ubuntu.

https://bugs.freedesktop.org/show_bug.cgi?id=22309
http://mixxx.org/forums/viewtopic.php?f=3&t=5726
http://forum.manjaro.org/index.php?topic=8241.0
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2013-09-03

Workarounds:

From the Freedesktop.org bug report:
"A downgrade to MesaLib-6.5.2.tar.bz2 fixed it for me.
Apparently it is a bug with the intel 915/945 chipset DRI."

An IRC user reported luck with using the "dri-alternatives" driver:
<dreamer> oh sweet, got it to work somehow. using the dri-alternatives driver and LIBGL_DRIVERS_PATH environment variable

[dreamer (dreamer-j)]

Some extra remarks:

Running current debian sid, compiled latest mixxx git which gave same result als apt package.

Installed libgl1-mesa-dri-experimental and running with LIBGL_DRIVERS_PATH=/usr/lib/i386-linux-gnu the program seems to run perfectly.

[RJ Skerry-Ryan (rryan)]

dreamer posted this log with backtrace

[RJ Skerry-Ryan (rryan)]

The relevant slice of the backtrace:

Thread 1 (Thread 0xb3e2c740 (LWP 26953)):
#0 0xb7fde424 in __kernel_vsyscall ()
#1 0xb5d2d81f in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2 0xb5d30cd3 in __GI_abort () at abort.c:90
#3 0xb5d26717 in __assert_fail_base (fmt=0xb5e69914 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    assertion=assertion@entry=0x8d4399c2 "p->on_hardware == 0",
    file=file@entry=0x8d439a68 "../../../../../../../src/mesa/drivers/dri/i915/i915_fragprog.c",
    line=line@entry=1225, function=function@entry=0x8d439d58 "i915BindProgram") at assert.c:92
#4 0xb5d267c7 in __GI___assert_fail (assertion=0x8d4399c2 "p->on_hardware == 0",
    file=0x8d439a68 "../../../../../../../src/mesa/drivers/dri/i915/i915_fragprog.c", line=1225,
    function=0x8d439d58 "i915BindProgram") at assert.c:101
#5 0x8d40da46 in ?? () from /usr/lib/i386-linux-gnu/dri/i915_dri.so
#6 0x8d0f00ff in _mesa_update_state_locked () from /usr/lib/i386-linux-gnu/libdricore9.2.2.so.1
#7 0x8d0f0414 in _mesa_update_state () from /usr/lib/i386-linux-gnu/libdricore9.2.2.so.1
#8 0x8d06d128 in _mesa_valid_to_render () from /usr/lib/i386-linux-gnu/libdricore9.2.2.so.1
#9 0x8d05978e in ?? () from /usr/lib/i386-linux-gnu/libdricore9.2.2.so.1
#10 0x8d05a199 in _mesa_validate_DrawArrays () from /usr/lib/i386-linux-gnu/libdricore9.2.2.so.1
#11 0x8d140ecb in ?? () from /usr/lib/i386-linux-gnu/libdricore9.2.2.so.1
#12 0xb7f161df in ?? () from /usr/lib/i386-linux-gnu/libQtOpenGL.so.4
#13 0xb7f1c00e in QGL2PaintEngineEx::drawImage(QRectF const&, QImage const&, QRectF const&, QFlags<Qt::ImageConversionFlag>) () from /usr/lib/i386-linux-gnu/libQtOpenGL.so.4
#14 0xb75d7396 in QPaintEngineEx::drawImage(QPointF const&, QImage const&) ()
   from /usr/lib/i386-linux-gnu/libQtGui.so.4
#15 0xb75f0137 in QPainter::drawImage(QPointF const&, QImage const&) ()
   from /usr/lib/i386-linux-gnu/libQtGui.so.4
#16 0x085b431b in drawImage (image=..., p=..., this=0xbfffed2c)
    at /usr/include/qt4/QtGui/qpainter.h:928
#17 WaveformRenderBackground::draw (this=0xa002468, painter=0xbfffed2c)
    at src/waveform/renderers/waveformrenderbackground.cpp:35

[RJ Skerry-Ryan (rryan)]

So, from what I gather:

* The QImage is non-null because QPainter::drawImage skips null images.
* The Qt paint engine in use is QGL2PaintEngineEx
* OpenGL context sharing seems to have been setup successfully:

Debug [Main]: Set root GL Context widget valid: QGLWidget(0x9a41760) true
Debug [Main]: Created root GL Context valid: 0x9a41990 true
Debug [Main]: Root GL Context format:
Debug [Main]: Double Buffering: true
Debug [Main]: Swap interval: 0
Debug [Main]: Depth buffer: true
Debug [Main]: Direct rendering: true
Debug [Main]: Has overlay: false
Debug [Main]: RGBA: true
Debug [Main]: Sample buffers: false
Debug [Main]: Stencil buffers: true
Debug [Main]: Stereo: false

[damaru (gef-ponnuki)]

Any workaround for arch? I tried to disable visuals with

Visuals 1

in the cfg, but it didn't work. Strangely using the vesa driver almost work (it doesn't crash but the display is not workable).

The downgrade sounds like quite a process for the arch distro atm

[RJ Skerry-Ryan (rryan)]

Hi damaru -- do you have the intel-dri package?

https://www.archlinux.org/packages/extra/x86_64/intel-dri/

What is your LIBGL_DRIVERS_PATH?

[RJ Skerry-Ryan (rryan)]

BTW, "Visuals 1" is no longer supported in Mixxx 1.11.0 onwards.

You should add:

[Waveform]
WaveformType 0

To your mixxx.cfg file to switch to Empty waveforms. You could also try 1 for software (non-OpenGL) waveforms.

[damaru (gef-ponnuki)]

I tried the WaveformType 0 (and 1 to 7) to no avail.

Yes I have the intel-dri package installed.

For the LIBGL_DRIVERS_PATH, I had nothing in there, then I Added

/usr/lib/xorg/modules/dri/

with no luck. I am not sure that is what is supposed to be there.

[RJ Skerry-Ryan (rryan)]

Hm, bummer. I believe:

export LIBGL_DRIVERS_PATH=/usr/lib/xorg/modules/dri/

is correct for Arch based on the intel-dri package

[damaru (gef-ponnuki)]

Sounds like there is a AUR for the older version so you can still use mixxx in arch without too much trouble :

https://aur.archlinux.org/packages/mixxxold/

installing now and will report

[Jeremy Wong (navcar)]

Hi, I have an Intel GMA 3150 netbook running Fedora 20. I had the same issue, but as a workaround I got Mixxx to work by installing Intel's Linux Graphics Installer ("https://01.org/linuxgraphics/"), then using

export LIBGL_DRIVERS_PATH=/usr/lib64/xorg/modules/drivers/

before running mixxx at the terminal.

[Goran (6oran)]

Hi there.

This bug reproduces on Debian testing fresh install, graphics card Intel 945, WaveformType set to 6.

Workaround: When WaveformType is set to 2 it mixxx works and shows a functional but not so smooth waveform.

[RJ Skerry-Ryan (rryan)]

does the glsl renderer trigger this crash?
On May 4, 2014 5:15 AM, "Goran" <email address hidden> wrote:

> Hi there.
>
> This bug reproduces on Debian testing fresh install, graphics card Intel
> 945, WaveformType set to 6.
>
> Workaround: When WaveformType is set to 2 it mixxx works and shows a
> functional but not so smooth waveform.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1274315
>
> Title:
> Intel i915 Chipset crashes
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1274315/+subscriptions
>

[Federico Briata (federicobriata)]

Hi guys,
any update?

kernel: Linux laptop 3.14-1-amd64
graphics card: Intel 945
OS: Debian jessie with xserver-xorg-video-intel version 2:2.21.15-2+b2

Following suggestion by Jeremy I can run again mixxx, thanks!

so after run: export LIBGL_DRIVERS_PATH=/usr/lib/xorg/modules/drivers/
mixxx is fine.

[Johannes Obermayr (jobermayr)]

It is a bug in Mesa codebase, not mixxx ...

[Max Linke (max-linke)]

@jobermayr Do you have a link to the bug ticket for mesa?

[RAWRR (rawrr)]

I'm running mixxx-1.12.0-beta1-1.12-git5418 on Slackware with both Mesa 10.0.5 and 10.2.9 and getting this as well.

[RAWRR (rawrr)]

nvm - installed mesa-libGL-10.6.0-0.devel.3.f80af89.fc23.i686 (from Fedora Rawhide) and I'm up and running just fine.