Bug 76321 - [SNB/IVB DRI3] OSD's from Gnome-shell hangs or crashes the Intel driver
Summary: [SNB/IVB DRI3] OSD's from Gnome-shell hangs or crashes the Intel driver
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.0
Hardware: Other All
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-18 14:26 UTC by Alex Hultman
Modified: 2016-02-21 23:03 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (50.17 KB, text/plain)
2014-03-18 14:55 UTC, Samuel Iglesias Gonsálvez
Details
Xorg.0.log (34.18 KB, text/plain)
2015-01-19 17:21 UTC, martin.kamleithner
Details
Xorg.1.log (22.46 KB, text/plain)
2015-01-19 17:22 UTC, martin.kamleithner
Details
Dmesg after hang (63.66 KB, text/plain)
2015-01-19 17:50 UTC, martin.kamleithner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Hultman 2014-03-18 14:26:24 UTC
I reported this as a bug in GNOME a year ago but they told me it was a bug in the driver. So here I am, bounced to you.

The problem is very concrete: whenever I change volume while playing any fullscreen game, the game and gnome-shell crashes or hangs and I have to change TTY and run top and terminate (9) everything.

When you change volume in gnome, there is a visible "on screen display" showing a volume icon. When in fullscreen, gnome turns on redirection and this is probably what's causing it to fail. Reproducible like 80% but if you cant reproduce the first time, keep changing volume and it will surely mess up the game in some way.


Steps:

1. Run any OpenGL fullscreen game in gnome (3.10 or whatever).
2. Let it run for some seconds (so the gnome unredirection kicks in).
3. Change volume.
4. Watch the game either crash or hang.
(You can even reproduce this by running glxgears in fullscreen!)

This only seems to hapen on Intel graphics, I cant reproduce in any other driver. I run an Intel Ivy Bridge, *but I dont know what driver I use*:

OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.0.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.0.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

Here is my Steam system information:

Processor Information:
    Vendor:  GenuineIntel
    CPU Family:  0x6
    CPU Model:  0x3a
    CPU Stepping:  0x9
    CPU Type:  0x0
    Speed:  3400 Mhz
    8 logical processors
    4 physical processors
    HyperThreading:  Supported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Supported
    SSE4a:  Unsupported
    SSE41:  Supported
    SSE42:  Supported
    
Network Information:
    Network Speed:  
    
Operating System Version:
    "Fedora release 20 (Heisenbug)" (64 bit)
    Kernel Name:  Linux
    Kernel Version:  3.13.6-200.fc20.x86_64
    X Server Vendor:  Fedora Project
    X Server Release:  11404000
    X Window Manager:  GNOME Shell
    Steam Runtime Version:  steam-runtime-release_2014-02-05
    
Video Card:
    Driver:  Intel Open Source Technology Center Mesa DRI Intel(R) Ivybridge Mobile 

    Driver Version:  3.0 Mesa 10.0.3
    OpenGL Version: 3.0
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 59 Hz
    VendorID:  0x10de
    DeviceID:  0xfd1
    Number of Monitors:  1
    Number of Logical Video Cards:  2
    Primary Display Resolution:  1920 x 1080
    Desktop Resolution: 1920 x 1080
    Primary Display Size: 13.54" x 7.64"  (15.51" diag)
                                            34.4cm x 19.4cm  (39.4cm diag)
    Primary VRAM Not Detected
    
Sound card:
    Audio device: Realtek ALC663
    
Memory:
    RAM:  7871 Mb
    
Miscellaneous:
    UI Language:  English
    LANG:  en_US.UTF-8
    Microphone:  Not set
    Total Hard Disk Space Available:  645133 Mb
    Largest Free Hard Disk Block:  538493 Mb
    
Installed software:
    
Recent Failure Reports:
    Wed Mar 12 21:10:58 2014 GMT: file ''/tmp/dumps/crash_20140312221051_1.dmp'', upload yes: ''CrashID=bp-ea78e410-a5b2-48a4-87be-e851f2140312''
Comment 1 Samuel Iglesias Gonsálvez 2014-03-18 14:55:30 UTC
Created attachment 96006 [details]
Xorg.0.log

I can reproduce this bug on a SandyBridge laptop with mesa git master.

When running Counter Strike: Source, if I change the volume as indicated, the game is going to background. There is no crash or hang on the X server nor the game. It's weird but it doesn't crash anything.

However, when doing the same with glxgears on fullscreen mode, the X server hanged. I tried to reset GDM without success, so I rebooted the machine. Attached it's the corresponding Xorg.0.log file.

Mesa version:

OpenGL version string: 3.0 Mesa 10.2.0-devel (git-63e7b51)
OpenGL shading language version string: 1.30

Linux Kernel version: 3.13-1-amd64
OS version: Debian Jessie amd64 (GNOME desktop)
Comment 2 Samuel Iglesias Gonsálvez 2014-03-18 14:56:36 UTC
In my case, dmesg log file doesn't show any error on the kernel driver.
Comment 3 Alex Hultman 2014-03-18 15:24:41 UTC
It only happens for fullscreen games. Did you run CS fullscreen? It's not 100% reproducible but almost.
Comment 4 Samuel Iglesias Gonsálvez 2014-03-18 17:03:36 UTC
Yes, I run CS:S fullscreen and it goes to background when changing the volume in my system. I repeated the sequence several times just to be sure that it could be a matter of likelihood.

Steam prints the following output when CS:S goes to background due to volume changing issue and when I select the game to be in foreground (fullscreen) by using alt-tab.

[...]
OnFocusWindowChanged to window type: k_EWindowTypeNonSteamDesktop, 0
OnFocusWindowChanged to window type: k_EWindowTypeSteamDesktop, 0
OnFocusWindowChanged to window type: k_EWindowTypeGame, 240
OnFocusWindowChanged to window type: k_EWindowTypeNonSteamDesktop, 0
OnFocusWindowChanged to window type: k_EWindowTypeSteamDesktop, 0
OnFocusWindowChanged to window type: k_EWindowTypeGame, 240
[...]

As I said in a previous comment, I can reproduce the bug with glxgears. I will start debugging the issue using glxgears and provide more info to the bug if needed.
Comment 5 Samuel Iglesias Gonsálvez 2014-03-20 07:30:30 UTC
It seems that I cannot reproduce the bug anymore even with glxgears -fullscreen :-(

I am going to check if there is something that I missed or what I reproduced was another issue. Maybe the problem is specific to IvyBridge (or newer) and SandyBridge is not affected, dunno.
Comment 6 Alex Hultman 2014-07-17 09:31:23 UTC
Others have reported the same bug:

https://github.com/ValveSoftware/portal2/issues/82
Comment 7 martin.kamleithner 2014-12-24 23:28:45 UTC
This bug is still present on my system.
Using Fedora 21 with Intel HD 4000 graphics.
Comment 8 Eero Tamminen 2015-01-12 10:42:47 UTC
(In reply to martin.kamleithner from comment #7)
> This bug is still present on my system.
> Using Fedora 21 with Intel HD 4000 graphics.

What version of:
- Mesa
- kernel
- X server
- X intel driver
you have?

My first suspicion would be for X intel driver.  Does issue go away if you switch from SNA to UXA acceleration in xorg.conf (or other way round if you were using UXA).  Or from DRI3 to DRI2 if you have DRI3 enabled?
Comment 9 martin.kamleithner 2015-01-19 13:04:33 UTC
Here is my steam system information:

Processor Information:
    Vendor:  GenuineIntel
    CPU Family:  0x6
    CPU Model:  0x2a
    CPU Stepping:  0x7
    CPU Type:  0x0
    Speed:  2200 Mhz
    4 logical processors
    2 physical processors
    HyperThreading:  Supported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Supported
    SSE4a:  Unsupported
    SSE41:  Supported
    SSE42:  Supported
    
Network Information:
    Network Speed:  
    
Operating System Version:
    "Fedora release 21 (Twenty One)" (64 bit)
    Kernel Name:  Linux
    Kernel Version:  3.17.8-300.fc21.x86_64
    X Server Vendor:  Fedora Project
    X Server Release:  11602901
    X Window Manager:  GNOME Shell
    Steam Runtime Version:  steam-runtime-release_2014-08-20
    
Video Card:
    Driver:  Intel Open Source Technology Center Mesa DRI Intel(R) Sandybridge Mobile 

    Driver Version:  3.0 Mesa 10.4.1
    OpenGL Version: 3.0
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 59 Hz
    VendorID:  0x8086
    DeviceID:  0x116
    Number of Monitors:  1
    Number of Logical Video Cards:  1
    Primary Display Resolution:  1366 x 768
    Desktop Resolution: 1366 x 768
    Primary Display Size: 13,54" x 7,64"  (15,51" diag)
                                            34,4cm x 19,4cm  (39,4cm diag)
    Primary VRAM Not Detected
    
Sound card:
    Audio device: Intel CougarPoint HDMI
    
Memory:
    RAM:  7898 Mb
    
Miscellaneous:
    UI Language:  English
    LANG:  en_US.utf8
    Microphone:  Not set
    Total Hard Disk Space Available:  95625 Mb
    Largest Free Hard Disk Block:  70312 Mb

Switching from SNA to UXA did not fix the bug.
I have never edited the xorg.conf before, so I think I should still be running DRI2. (How do I check? glxinfo says just: direct rendering: Yes)

What I noticed: If I plug in a second monitor and use both (not mirrored), then this bug does not appear. I can change the volume and the OSD works fine and does not crash the system.

If a game hangs, I can get it running again most of the time by switching to a virtual terminal and then switch back using "chvt 1".
Comment 10 Eero Tamminen 2015-01-19 15:11:01 UTC
(In reply to martin.kamleithner from comment #9)
> Switching from SNA to UXA did not fix the bug.
> I have never edited the xorg.conf before, so I think I should still be
> running DRI2. (How do I check? glxinfo says just: direct rendering: Yes)

Xorg log file states which acceleration and DRI mode it's using.

What about your X intel driver version?
(intel_drv.s version is also logged to Xorg log file)


> What I noticed: If I plug in a second monitor and use both (not mirrored),
> then this bug does not appear. I can change the volume and the OSD works
> fine and does not crash the system.
> 
> If a game hangs, I can get it running again most of the time by switching to
> a virtual terminal and then switch back using "chvt 1".

Is there something in dmesg after the hang?
Comment 11 martin.kamleithner 2015-01-19 17:21:18 UTC
Created attachment 112488 [details]
Xorg.0.log
Comment 12 martin.kamleithner 2015-01-19 17:22:41 UTC
Created attachment 112489 [details]
Xorg.1.log
Comment 13 martin.kamleithner 2015-01-19 17:34:41 UTC
>Xorg log file states which acceleration and DRI mode it's using.
>
>What about your X intel driver version?
>(intel_drv.s version is also logged to Xorg log file)

I uploaded the Xorg.0.log and Xorg.1.log.
Xorg.0.log loads just DRI2, in Xorg.1.log also DRI3 was loaded.

Intel driver Version
 (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
[    42.938] (II) Module intel: vendor="X.Org Foundation"
[    42.938] 	compiled for 1.14.5, module version = 2.99.911
[    42.938] 	Module class: X.Org Video Driver
[    42.938] 	ABI class: X.Org Video Driver, version 14.1
Comment 14 martin.kamleithner 2015-01-19 17:50:39 UTC
Created attachment 112491 [details]
Dmesg after hang

Dmesg after hang.
I think it might be a problem with the focus.
While the game hangs, a can give the focus to a terminal via alt-tab and kill it for example.
The game is still in the foreground, so the terminal is not rendered, but the input is definitely delivered to the terminal.
One time when I tried to kill the game via terminal while it was hanging, the whole system crashed (just a black screen), but I could not reproduce this.
Comment 15 Eero Tamminen 2015-01-20 09:30:03 UTC
(In reply to martin.kamleithner from comment #13)
> >Xorg log file states which acceleration and DRI mode it's using.
> >
> >What about your X intel driver version?
> >(intel_drv.s version is also logged to Xorg log file)
> 
> I uploaded the Xorg.0.log and Xorg.1.log.
> Xorg.0.log loads just DRI2, in Xorg.1.log also DRI3 was loaded.
> 
> Intel driver Version
>  (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
> [    42.938] (II) Module intel: vendor="X.Org Foundation"
> [    42.938] 	compiled for 1.14.5, module version = 2.99.911
> [    42.938] 	Module class: X.Org Video Driver
> [    42.938] 	ABI class: X.Org Video Driver, version 14.1

You're using two X servers?

One is 1.14 with March version of intel DDX and another 1.16 with September version of Intel DDX.  With latter I would recommend disabling DRI3, it's not reliable ('Option "DRI" "2"' in xorg.conf).

Besides DRI3, I didn't see anything suspicious in the log files.
Comment 16 martin.kamleithner 2015-01-20 10:33:35 UTC
>You're using two X servers?

If I do, it is not intentional. I thought, the Xorg.0.log file is the current one, and the Xorg.1.log file is an older one? I found both, so I uploaded both.

I now forced DRI2 in the xorg.conf file, but this also does not fix the hangs on OSD events.

Workaround for now is either not using fullscreen or plugging in a second monitor, I hope that the new Intel driver for Fedora 21, which is supposed the be released in the next weeks fixes my issues.
Comment 17 martin.kamleithner 2015-01-20 11:25:01 UTC
After experimenting with various configurations, I found that 
the combination SNA/DRI 2 seems to be stable.
The performance is subjectively a bit worse than before, though.

Here is the relevant section in the xorg.conf:

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "sna"
   Option      "DRI"          "2"
EndSection
Comment 18 Eero Tamminen 2015-01-20 12:15:43 UTC
Main performance difference between DRI2 & DRI3 should come only in synthetic benchmarks where you go much over 60 FPS, with Vsync it should not be visible to user. That was about memory overhead and how perf is visible to the application.

There are also differences in how frames get to screen after application has rendered them to the double/triple buffer.
Comment 19 martin.kamleithner 2015-01-20 15:52:48 UTC
(In reply to Eero Tamminen from comment #18)
> Main performance difference between DRI2 & DRI3 should come only in
> synthetic benchmarks where you go much over 60 FPS, with Vsync it should not
> be visible to user. That was about memory overhead and how perf is visible
> to the application.
> 
> There are also differences in how frames get to screen after application has
> rendered them to the double/triple buffer.

You are right, the performance difference is not from DRI2 vs DRI3, but from SNA vs UXA: Switching back to UXA brings back good performance, but reintroduces the bug.


The performance drop is not 100% reproduceable, it only happens on fullscreen and only sometimes with various games (E.g. Binding of Isaac:Rebirth, Super Hexagon), but when it happens, it is very noticeable (below 30 fps).
I don't know how to measure fps on Linux, but the fps drop is definitely there.
Comment 20 martin.kamleithner 2015-11-14 14:41:58 UTC
A bit late, but better now then never:

The newest Intel driver fix this problems, OSD's now work without crashing any OpenGL applications, performance is now also fine with UXA. I did not test SNA with the new drivers yet.

[Fedora 23]
Comment 21 Benjamin Xiao 2016-02-21 11:38:52 UTC
I am still getting crashes on Fedora 23 with SNA and DRI3. Way to reproduce is the same. Launch a fullscreen game and wait until unredirection kicks in. Try changing the volume. OSD will appear to flicker very rapidly and then X will crash, taking me back to the login screen.

Disabling DRI3 prevents the crash but causes vsync issues.


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.