Bug 77918 - GPU crash on WebGL application (stuck on render ring) | drm/i915 | GM965 | Kernel 3.14.1 | MESA 10.1
Summary: GPU crash on WebGL application (stuck on render ring) | drm/i915 | GM965 | Ke...
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.1
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2014-04-25 09:28 UTC by acidicX
Modified: 2019-09-25 18:51 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

journal-log (32.42 KB, text/plain)
2014-04-25 09:28 UTC, acidicX
the ominous error file (41.78 KB, application/x-xz)
2014-04-25 18:54 UTC, acidicX

Description acidicX 2014-04-25 09:28:04 UTC
Created attachment 97947 [details]

When I tried to start a WebGL application (triggerrally.com), the GPU crashed while loading the game.

This happened with Chromium Nightly and Firefox Stable (28) and is reproducable.

I've attached the full log from journal - sorry, I don't know how much you guys need to debug. If you need any more information please let me know.

The error file (gpu crash dump at /sys/class/drm/card0/error) is empty / 0 bytes..?

HP Compaq 6510b w. Intel GMA X3100

Arch Linux x64,
Kernel 3.14.1,
MESA 10.1.1,
intel-dri 10.1.1
Comment 1 Chris Wilson 2014-04-25 09:40:08 UTC
The error state is essential; cat /sys/class/drm/card0/error | xz -9 > error.xz
Comment 2 acidicX 2014-04-25 11:09:02 UTC
$ sudo cat /sys/class/drm/card0/error
no error state collected

How can I make sure the error state is being collected (as I said, the bug is reproducable)?
Comment 3 Chris Wilson 2014-04-25 12:22:09 UTC
It is collected. It only lasts until the next reboot however.
Comment 4 acidicX 2014-04-25 18:54:35 UTC
Created attachment 97976 [details]
the ominous error file

I wonder what happens when the system completely crashes and you cannot ssh into the machine and copy the file? :D
A bit unfriendly for users but I managed it... there you go!
Comment 5 acidicX 2014-05-09 19:33:51 UTC
Is there any update on this?
Do you need anything else?
Comment 6 Kenneth Graunke 2014-05-10 04:45:54 UTC
I can reproduce this.  The first time I went to the site, I got an assertion failure in the blitter code.  The second time, it seemed to work, but I then got a GPU hang on 3DSTATE_CONSTANT_COLOR.  I figured it was the first non-pipelined command, but it wasn't - 3DTATE_GLOBAL_DEPTH_OFFSET_CLAMP happened earlier in the batch, and there was no intervening drawing.  Odd...
Comment 7 Matt Turner 2017-03-22 04:44:34 UTC
Please reopen if you can still reproduce with Mesa 17.0.
Comment 8 GitLab Migration User 2019-09-25 18:51:27 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1442.

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.