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''
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)
In my case, dmesg log file doesn't show any error on the kernel driver.
It only happens for fullscreen games. Did you run CS fullscreen? It's not 100% reproducible but almost.
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.
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.
Others have reported the same bug: https://github.com/ValveSoftware/portal2/issues/82
This bug is still present on my system. Using Fedora 21 with Intel HD 4000 graphics.
(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?
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".
(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?
Created attachment 112488 [details] Xorg.0.log
Created attachment 112489 [details] Xorg.1.log
>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
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.
(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.
>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.
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
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.
(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.
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]
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.