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.