Bug 104991

Summary: [skl] GPU HANG: ecode 9:0:0x85dffffb, in Xorg
Product: Mesa Reporter: iko
Component: Drivers/DRI/i965Assignee: Intel 3D Bugs Mailing List <intel-3d-bugs>
Status: RESOLVED DUPLICATE QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: /sys/class/drm/card1/error after first crash
/sys/class/drm/card1/error after second crash
dmesg output, after both crashes
xrandr --verbose output
/sys/class/drm/card1/error on 4.14.0-1
dmesg on 4.14.0-1
screen dump of xterm, pre-crash

Description iko 2018-02-07 10:26:17 UTC
Created attachment 137206 [details]
/sys/class/drm/card1/error after first crash

It seems to happen shortly after I start a VM in virtualbox (debian version 5.2.6-dfsg-2), so far two out of two times tried.

uname -m: x86_64 (with amd64 userland)
uname -r: 4.14.0-3-amd64
running debian unstable
ThinkPad T460p with dual GPUs and 2560x1440 display panel
Comment 1 iko 2018-02-07 10:27:05 UTC
Created attachment 137207 [details]
/sys/class/drm/card1/error after second crash
Comment 2 iko 2018-02-07 10:27:42 UTC
Created attachment 137208 [details]
dmesg output, after both crashes
Comment 3 iko 2018-02-07 10:28:08 UTC
Created attachment 137209 [details]
xrandr --verbose output
Comment 4 iko 2018-02-07 10:35:37 UTC
Three times out of three, so pretty consistent with starting the virtual box VM.
Comment 5 iko 2018-02-07 10:53:36 UTC
Downgrading the kernel to

uname -r: 4.14.0-1-amd64

seems to have cured it
Comment 6 iko 2018-02-07 10:57:34 UTC
Nope, it didn't. Just took a bit longer to crash on 4.14.0-1-amd64
Comment 7 iko 2018-02-07 10:59:30 UTC
Created attachment 137210 [details]
/sys/class/drm/card1/error on 4.14.0-1
Comment 8 iko 2018-02-07 10:59:52 UTC
Created attachment 137211 [details]
dmesg on 4.14.0-1
Comment 9 iko 2018-02-07 12:33:42 UTC
virtualbox was not at fault. The actual culprit was xterm, when editing a long command line.

Attaching screendump of xterm pre-crash. Starting to type "--exclude config" has invariably caused the crash before getting to the end of "--exclude", usually right before typing "l", but not always.
Comment 10 iko 2018-02-07 12:34:18 UTC
Created attachment 137214 [details]
screen dump of xterm, pre-crash
Comment 11 iko 2018-02-07 12:35:18 UTC
said "--exclude config" is inserted where the cursor is in the screen dump, as the first --exclude option to rsync
Comment 12 Elizabeth 2018-03-06 18:21:52 UTC
Hi, which mesa version are you using?
Comment 13 iko 2018-03-19 22:40:09 UTC
(In reply to Elizabeth from comment #12)
> Hi, which mesa version are you using?

I was using (debian packaged) 17.3.5. I think it showed up (but not as bad)
in 17.3.3, since I had occational crashes with that version. It seems to have gone away in 17.3.6.
Comment 14 Mark Janes 2018-03-20 15:34:27 UTC

*** This bug has been marked as a duplicate of bug 104411 ***

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.