Bug 89035 - [snb blorp] GPU hang in zbarcam
Summary: [snb blorp] GPU hang in zbarcam
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-09 09:06 UTC by Ting-Wei Lan
Modified: 2019-09-25 18:53 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (118.44 KB, text/plain)
2015-02-09 09:07 UTC, Ting-Wei Lan
Details
/sys/class/drm/card0/error (2.19 MB, text/plain)
2015-02-09 09:08 UTC, Ting-Wei Lan
Details
Linux 3.18.6, Mesa 10.5.0-rc1 dmesg (118.60 KB, text/plain)
2015-02-13 16:10 UTC, Ting-Wei Lan
Details
Linux 3.18.6, Mesa 10.5.0-rc1 /sys/class/drm/card0/error (2.19 MB, text/plain)
2015-02-13 16:12 UTC, Ting-Wei Lan
Details

Description Ting-Wei Lan 2015-02-09 09:06:16 UTC
When I run zbarcam with a non-compositing window manager, such as openbox and xfwm with compositing disabled, it works mostly fine although it may cause the kernel to show some error:

[drm:ilk_display_irq_handler] *ERROR* Pipe A FIFO underrun
[drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A
[drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun


When I run zbarcam with a compositing window manager, such as gnome-shell (mutter) and xfwm with compositing enabled, it also shows the above error, but it stops showing the video captured by the webcam and shows the zbar logo instead after the window is moved. If I keep moving the window for more than 30 seconds, it causes Xorg to hang and it tells me to report the bug here. The system may crash after showing the error.

[drm] stuck on render ring
[drm] GPU HANG: ecode 0:0x84fefffc, in Xorg.bin [1114], reason: Ring hung, action: reset
[drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[drm] GPU crash dump saved to /sys/class/drm/card0/error
[drm] stuck on render ring
[drm] GPU HANG: ecode 0:0x84fefffc, in Xorg.bin [1114], reason: Ring hung, action: reset


Hardware:
Intel Core i7-2640M CPU @ 2.80GHz
Intel Sandybridge Mobile

Software:
Linux 3.18.5
Xorg 1.16.3
Mesa 10.4.3
xf86-video-intel 2.99.916

Window Managers:
GNOME Shell 3.14.3 (Mutter 3.14.3)
Openbox 3.5.2
Xfwm 4.10.1
Comment 1 Ting-Wei Lan 2015-02-09 09:07:20 UTC
Created attachment 113273 [details]
dmesg
Comment 2 Ting-Wei Lan 2015-02-09 09:08:44 UTC
Created attachment 113274 [details]
/sys/class/drm/card0/error
Comment 3 Ian Romanick 2015-02-11 22:14:21 UTC
There have been some fixes related to Sandy Bridge GPU hangs made on Mesa master and on the 10.5 branch.  Can you retry with the 10.5 branch?
Comment 4 Ting-Wei Lan 2015-02-12 12:59:34 UTC
I will try Mesa 10.5 ... An interesting thing to know is that I cannot reproduce the problem without using GDM.
Comment 5 Ting-Wei Lan 2015-02-13 16:09:24 UTC
(In reply to Ian Romanick from comment #3)
> There have been some fixes related to Sandy Bridge GPU hangs made on Mesa
> master and on the 10.5 branch.  Can you retry with the 10.5 branch?

I upgraded to Mesa 10.5.0-rc1 and used the same version of Xorg and xf86-video-intel, but it still hangs when I move the window of zbarcam under gnome-shell.
Comment 6 Ting-Wei Lan 2015-02-13 16:10:25 UTC
Created attachment 113471 [details]
Linux 3.18.6, Mesa 10.5.0-rc1 dmesg
Comment 7 Ting-Wei Lan 2015-02-13 16:12:37 UTC
Created attachment 113472 [details]
Linux 3.18.6, Mesa 10.5.0-rc1 /sys/class/drm/card0/error
Comment 8 jontis 2015-03-12 22:47:04 UTC
Same thing. zbarcam with video feed kills the system.
zbarcam --nodisplay causes no problems.

Fedora 21 with Gnome
Haswell graphics with SNA but crashed with UXA too
mesa                10.4.3-1.20150124.fc21
kernel              3.18.7-200.fc21
xorg-x11-drv-intel  2.99.916-3.20141117.fc21
Comment 9 Ting-Wei Lan 2015-05-02 08:59:41 UTC
I tried git master branch. The 'FIFO underrun' messages showed, but Xorg didn't hang. However, zbarcam still stopped showing the video and showed the logo instead after the window was moved.

Software:
Linux 3.19.5
Xorg 1.17.99 (xorg-server-1.17.0-76-gb102971)
Mesa 10.6.0-devel (10.5-branchpoint-1847-geeee212)
xf86-video-intel 2.99.917-294-ge7016d3

Window Managers:
Mutter 3.14.4
Openbox 3.5.2
Comment 10 Matt Turner 2017-03-22 03:23:42 UTC
Please reopen if you can still reproduce with Mesa 17.0.
Comment 11 Ting-Wei Lan 2017-05-20 15:22:09 UTC
Although zbarcam still doesn't work with compositing window managers, running it no longer causes Xorg hang or system crash. zbarcam seems to work correctly with non-compositing window managers and Xwayland.

Software:
Linux 4.10.15
Xorg 1.19.3
Mesa 17.0.5
xf86-video-intel 2.99.917-708-g8f33f80

Window Managers:
GNOME Shell 3.22.3 (Mutter 3.22.4)
Openbox 3.6.1
Xfwm 4.12.4

Wayland Compositors:
GNOME Shell 3.22.3 (Mutter 3.22.4)
Weston 1.12.0
Comment 12 vadym 2018-05-11 10:59:11 UTC
I can run zbarcam on Ubuntu (Xubuntu 16.04) without issues:

    Kernel: 4.13.0-38-generic x86_64
    Desktop: Xfce 4.12.3 (Gtk 2.24.28) with compositing enabled
    Mesa 10.1.0-devel (git-a61ae2a), Mesa 17.2.8

Unable to build mesa-10.4.3 (mentioned in comments) so tested with Mesa 10.4.7 (git-cb154bb) - all OK.
Comment 13 GitLab Migration User 2019-09-25 18:53:14 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/1469.


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.