Created attachment 135580 [details] Console.log showing a few runs, crashes and alternate VAC complaints from switching HDR option In Team Fortress 2 if I set High Dynamic Range option to Bloom (If available), I get the following errors. These are from 3 separate crashes, all immediately after entering a server and attempting to choose a class at the class loadout screen, or within seconds of starting play. MatQueue0[16918]: segfault at 8 ip 00000000f51e49e8 sp 0000000004556ed0 error 4 in i965_dri.so[f4de6000+8d4000] hl2_linux[17355]: segfault at 0 ip 00000000f51fa929 sp 00000000ffcda660 error 6 in i965_dri.so[f4e0e000+8d4000] MatQueue0[18870]: segfault at 0 ip 00000000f7e39dcc sp 00000000009169d8 error 6 in libc-2.26.so[f7cfd000+1cf000] These crashes stop if I set the High Dynamic Range option to None. However, when I do set the value of HDR to None, VAC swears I've modified my game files for some strange reason. If I set HDR back to Bloom (If available), suddenly I'm ok and can connect to servers again without VAC complaining...But then it crashes. I will post this in Valve's Git as well because I'm torn between this being a Mesa issue and a Valve issue. Note: I've also seen: https://bugs.freedesktop.org/show_bug.cgi?id=101443 BUT per Comment #3, that user states his crashes occur with HDR disabled, and he is using an older version of Mesa (17.1.2). I see the issue with Bloom enabled, and I'm using Mesa 17.2.2
Hi Robert, are you still experiencing this issue with today's Mesa master (commit ee57b15ec764736e2d5360beaef9fb2045ed0f68 or later)?
I've updated to the latest UNSTABLE Padoka PPA: 1:17.4git171201235300.d93fabba~padoka0 https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa I am still getting these crash errors (not related to the MSAA crash that is fixed). Today they happened with and without HDR enabled, but the difference in setting seemed to change the rate at which the crash occurred. I did not experience a VAC message upon changing the setting this time.
Hello Robert, just in case, what is your platform and what linux distro are you using? Thank you.
Computer Information: Manufacturer: Unknown Model: Unknown Form Factor: Laptop No Touch Input Detected Processor Information: CPU Vendor: GenuineIntel CPU Brand: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz CPU Family: 0x6 CPU Model: 0x8e CPU Stepping: 0x9 CPU Type: 0x0 Speed: 3500 Mhz 4 logical processors 2 physical processors HyperThreading: Supported FCMOV: Supported SSE2: Supported SSE3: Supported SSSE3: Supported SSE4a: Unsupported SSE41: Supported SSE42: Supported AES: Supported AVX: Supported CMPXCHG16B: Supported LAHF/SAHF: Supported PrefetchW: Unsupported Operating System Version: Ubuntu 17.10 (64 bit) Kernel Name: Linux Kernel Version: 4.13.0-18-generic X Server Vendor: The X.Org Foundation X Server Release: 11905000 X Window Manager: Xfwm4 Video Card: Driver: Intel Open Source Technology Center Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) x86/MMX/SSE2 Driver Version: 3.0 Mesa 17.4.0-devel - padoka PPA OpenGL Version: 3.0 Desktop Color Depth: 24 bits per pixel Monitor Refresh Rate: 59 Hz VendorID: 0x8086 DeviceID: 0x5916 Revision Not Detected Number of Monitors: 2 Number of Logical Video Cards: 1 Primary Display Resolution: 2560 x 1440 Desktop Resolution: 5760 x 1800 Primary Display Size: 23.62" x 13.39" (27.13" diag) 60.0cm x 34.0cm (68.9cm diag) Primary VRAM Not Detected Sound card: Audio device: Realtek ALC3246 Memory: RAM: 15923 Mb Miscellaneous: UI Language: English LANG: en_US.UTF-8 Total Hard Disk Space Available: 479190 Mb Largest Free Hard Disk Block: 25070 Mb VR Headset: None detected Recent Failure Reports:
Hello again, so if HDR don't trigger the hang directly with latest tip, how can it be reproduced? What steps needs to be done? Summarizing, is a KBL with ubuntu 17.10, Xcfe, playing steam Team Fortres 2, isn't it?
Yes, currently it crashes with and without HDR enabled with the above setup and any version of Mesa between 7.2 and 7.4-git. All that is required is to play a while.
Created attachment 136394 [details] error_state_mesa_17_3_1 I was able to reproduce with mesa 17.2.2 and 17.3.1 (git-f66496d291), with default kernel 4.13-21 and latest stable 4.14.8 To reproduce: 1. Install fresh ubuntu 17.10, xfce4, mesa, and steam, update & upgrade. 2. Download team fortress 2. 3. Open game, go to "Find a game" -> "Training" -> "Offline practice" -> Choose default options -> Continue without watching movie -> No coaching -> Choose character -> Start playing. The play will hang after a few, less than 5min., you need to move outside the "base" and you don't have to die. Run around an shot. kernel version : 4.14.8 os version : Ubuntu 17.10 artful x86_64 mesa : 17.3.1 (git-f66496d291) libdrm : 2.4.8 Xorg : 2:1.9.5 platform : Kabylake-Laptop cpu information : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz gpu card : Intel Corporation HD Graphics 620 (rev 02) (prog-if 00 [VGA controller]) memory ram : 16 GB display resolution : 5440x1080 displays connected : eDP-1
Created attachment 136395 [details] Crash_dump_tf2
Created attachment 136396 [details] console_stdout
Created attachment 136397 [details] console_stdout I got a lot of dbus-connection messages, but not sure if it's because my proxy, and that I'm using steam in "offline" mode.
Hey Robert, could you lend me a hand? I'm trying to find a "good" commit for this issue. Do you have identified any version/commit where the game worked correctly?? Thank you.
So back in March I was running Ubuntu 16.04 and having an issue with Portal 2 when I posted the following in a different bug: Mesa: v12.0.6-0ubuntu0.16.04.1 xserver-xorg-video-intel: 2:2.99.917+git20160325-1ubuntu1.2 I can definitely say I was not experiencing this particular crash in TF2 at the time running Mesa 12.0.6. I know that is a big difference between 17.2 and a lot of commits to bisect. Mesa 17.0 or 17.1 might be ok as well, but I'm not 100% on those versions. I think this crash is a rather recent development, like Mesa 17.2 and newer. A possible duplicate issue reported to Valve's Git by another person shows they are running Mesa 17.1.5 in their gist: https://github.com/ValveSoftware/Source-1-Games/issues/2310 So I'd say it started somewhere between 12.0.6 and 17.1.5.
Thanks for the research Robert, if you have the time to bisect, it would be really helpful. I'll try first with 17.0 and 17.1.5, let's see if we can get a good one.
I have compiled and performed bisects with git for WINE in the past. I've not built Mesa or any such major component before. I am currently running the latest build of git Mesa from the Padoka PPA. Any tips on how to go about building Mesa and deploying on the same system? I'll take a look at what documentation I can find.
(In reply to Robert from comment #14) > I have compiled and performed bisects with git for WINE in the past. I've > not built Mesa or any such major component before. I am currently running > the latest build of git Mesa from the Padoka PPA. Any tips on how to go > about building Mesa and deploying on the same system? > > I'll take a look at what documentation I can find. You may want to take a look to bug 103818.
Created attachment 136723 [details] Card error
Created attachment 136724 [details] dmesg
Tested on HP ZBook with Ubuntu 16.04 LTS. I'm able to reproduce the issue only on mesa 17.2.4 (1b10d08). I also tried mesa 17.3.1 (f66496d) and 17.4-devel (42f421c) but issue is gone there (played around 30 mins for each test). My HW info: Manufacturer: HP Product Name: HP ZBook 14u G4 Version: Serial Number: 5CG7442WKZ UUID: C8764034-3466-44AD-4BD7-92CFB70F9AD0 Wake-up Type: Power Switch SKU Number: 1LL55AV Family: 103C_5336AN HP EliteBook # glxinfo -B name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) x86/MMX/SSE2 (0x5916) Version: 17.4.0 Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) x86/MMX/SSE2 OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel (git-42f421cbbf) OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 3.0 Mesa 17.4.0-devel (git-42f421cbbf) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.4.0-devel (git-42f421cbbf) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
Hello Vadym, I tested 18.0 with kernel 4.15, an I'm still able to reproduce. Where did you get 17.4?
Hi Elizabeth, I took 17.4 from master branch. Probably I missed something. I'll try to reproduce it again with the latest branch. I'm just curious what TM2 graphics settings are you using to reproduce the bug (default or with any changes) ?
Hi Elizabeth, Not sure why but I'm still not able to reproduce that. Below is my sw/hw info: kernel version : 4.14.16-041416-generic os version : Ubuntu 17.10 64-bit mesa : 18.1.0-devel (git-2ef5ce1198) libdrm : 2.4.0 Xorg : 2:1.19.5-0ubuntu2 platform : Kabylake-Laptop cpu information : Intel® Core™ i7-7500U CPU @ 2.70GHz × 4 gpu card : Intel® HD Graphics 620 (Kaby Lake GT2) memory ram : 16 GB display resolution : 1920x1080 displays connected : eDP-1
Created attachment 137114 [details] Team Fortress 2 video settings Also attaching TM2 video settings used for testing.
Hi Elizabeth, I tested again with old mesa 17.2.4 (git-1b10d0851a) and issue is 100% reproducible with exactly the same error as it was initially reported. Here is crash info from gdb: Thread 32 "MatQueue0" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xba018b40 (LWP 16639)] 0xda19df88 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/tf/bin/client.so (gdb) bt #0 0xda19df88 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/tf/bin/client.so #1 0xda19e0a6 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/tf/bin/client.so #2 0xda19e154 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/tf/bin/client.so #3 0xda19e22d in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/tf/bin/client.so #4 0xda19e26e in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/tf/bin/client.so #5 0xda146716 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/tf/bin/client.so #6 0xda146a19 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/tf/bin/client.so #7 0xf7d1754b in ?? () from /lib/i386-linux-gnu/libc.so.6 #8 0xf7d175b1 in exit () from /lib/i386-linux-gnu/libc.so.6 #9 0xf510b48e in _intel_batchbuffer_flush_fence.part.5 () from /usr/local/lib/dri//i965_dri.so #10 0xf5118ba5 in intel_dri2_flush_with_flags () from /usr/local/lib/dri//i965_dri.so #11 0xf7fa7d21 in loader_dri3_flush () from /usr/local/lib/libGL.so.1 #12 0xf7fa2bfe in glx_dri3_flush_drawable () from /usr/local/lib/libGL.so.1 #13 0xf7fa822d in loader_dri3_swap_buffers_msc () from /usr/local/lib/libGL.so.1 #14 0xf7fa2ea4 in dri3_swap_buffers () from /usr/local/lib/libGL.so.1 #15 0xf7f74bd9 in glXSwapBuffers () from /usr/local/lib/libGL.so.1 #16 0xf5ecacd7 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/libSDL2-2.0.so.0 #17 0xf5ebea31 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/libSDL2-2.0.so.0 #18 0xf5e50704 in SDL_GL_SwapWindow () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/libSDL2-2.0.so.0 #19 0xf65906ad in ?? () from bin/launcher.so #20 0xf5f58981 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/libtogl.so #21 0xf5f48f1b in IDirect3DDevice9::Present(_RECT const*, _RECT const*, void*, RGNDATA const*) () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/libtogl.so #22 0xf157fef5 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/shaderapidx9.so #23 0xf316b7bb in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/materialsystem.so #24 0xf316bade in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/materialsystem.so #25 0xf3145ad1 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/materialsystem.so #26 0xf314f34a in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/materialsystem.so #27 0xf314e3f7 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/materialsystem.so #28 0xf6437d75 in ?? () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/libvstdlib.so #29 0xf653d9a1 in CThread::ThreadProc(void*) () from /home/vadym/.steam/steam/steamapps/common/Team Fortress 2/bin/libtier0.so #30 0xf7ec537c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #31 0xf7dde0c6 in clone () from /lib/i386-linux-gnu/libc.so.6 In Comment 7 you mentioned that 17.3.1 (git-f66496d291) mesa was used for testing but in console_stdout attachment (https://bugs.freedesktop.org/attachment.cgi?id=136397) I can see that other mesa was used: Mesa 17.2.2 (3.0.0). Probably this log was attached by mistake. Just in case can you please double check that TM2 is linked with mesa 17.3.1 or older ?
Bisected to first good commit: commit ee57b15ec764736e2d5360beaef9fb2045ed0f68 (HEAD) Author: Jason Ekstrand <jason.ekstrand@intel.com> Date: Wed Nov 29 16:22:42 2017 -0800 i965: Disable regular fast-clears (CCS_D) on gen9+ This partially reverts commit 3e57e9494c2279580ad6a83ab8c065d01e7e634e which caused a bunch of GPU hangs on several Source titles. To date, we have no clue why these hangs are actually happening. This undoes the final effect of 3e57e9494c227 and gets us back to not hanging. Tested with Team Fortress 2. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102435 Fixes: 3e57e9494c2279580ad6a83ab8c065d01e7e634e Cc: mesa-stable@lists.freedesktop.org With this patch issue is no longer reproducible. I think this should be marked as duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=102435
Thanks Vadym, will double check, and test with that commit. Yes, it seems to be a dup of bug 102435.
(In reply to vadym from comment #24) > Bisected to first good commit: > > commit ee57b15ec764736e2d5360beaef9fb2045ed0f68 (HEAD) > Author: Jason Ekstrand <jason.ekstrand@intel.com> > Date: Wed Nov 29 16:22:42 2017 -0800 > > i965: Disable regular fast-clears (CCS_D) on gen9+ > > This partially reverts commit 3e57e9494c2279580ad6a83ab8c065d01e7e634e > which caused a bunch of GPU hangs on several Source titles. To date, we > have no clue why these hangs are actually happening. This undoes the > final effect of 3e57e9494c227 and gets us back to not hanging. Tested > with Team Fortress 2. > > Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102435 > Fixes: 3e57e9494c2279580ad6a83ab8c065d01e7e634e > Cc: mesa-stable@lists.freedesktop.org > > With this patch issue is no longer reproducible. > I think this should be marked as duplicate of > https://bugs.freedesktop.org/show_bug.cgi?id=102435 I'm actually the reporter of both issues, and I do not believe them to be the same. I am now running Mesa 1:18.1~git180129151100.0347a83~a~padoka0 from the Padoka PPA which includes the patch you mention. Yet TF2 continues to crash. CSGO has not exhibited any crashing since that patch.
(In reply to Elizabeth from comment #15) > (In reply to Robert from comment #14) > > I have compiled and performed bisects with git for WINE in the past. I've > > not built Mesa or any such major component before. I am currently running > > the latest build of git Mesa from the Padoka PPA. Any tips on how to go > > about building Mesa and deploying on the same system? > > > > I'll take a look at what documentation I can find. > > You may want to take a look to bug 103818. Elizabeth, I've successfully built from the first bisect between 12.0.6 and 13.0.6. I hope everything I need is included. Is it now just installed with sudo make install?? Do I need to purge the Mesa 18.x Git PPA first?? After testing would a sudo make uninstall, re-adding the PPA, and apt-get update && apt-get dist-upgrade get me back to the state I'm in now? Thanks
Hello Robert, Is better to use git for that http://www.paranormal-entertainment.com/idr/blog/posts/2015-12-03T20:40:31Z-Bisecting_like_a_boss/ Right now, I'm having some issues with my installation, so it may take me a little to test again. Thanks for your patient.
(In reply to Elizabeth from comment #28) > Hello Robert, > Is better to use git for that > http://www.paranormal-entertainment.com/idr/blog/posts/2015-12-03T20:40:31Z- > Bisecting_like_a_boss/ > Right now, I'm having some issues with my installation, so it may take me a > little to test again. > Thanks for your patient. Hi Elizabeth, I am using git for the custom build testing. I'm only using the padoka PPA while not testing. I just wanted to make sure the transition between the two installs did not leave my system in an unusable state. I may try this weekend.
Hi again, I have an SKL where others steam games work fine by using <18 mesa. I haven't been able to test on tf2 though. If you don't want to risk it, you could try with https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers packages for now.
Created attachment 137942 [details] game_log Hello again. Sorry for the long delay, but I was finally able to use the KBL to test it, and can confirm that with mesa 18.0.1 the hang is no longer reproducible. Though it seems to exist some bug in the game itself, when using the tutorial mode inside the items menu, it seems that the upper layer does nothing, so no matter where do I click I can't go further or back into the game. The rest of the system keeps working properly, no hangs in dmesg, no frozen mouse, even steam keeps working properly, only the game window is stuck, so I just close it and if instead of going to the tutorial I go directly to the menu, it works. I don't know if this is the issue you're still seeing.
Thank you Elizabeth. Yes, that crash appears to be gone now. There are other bugs I'm noticing that I'll report within the git Valve community. I'd say this is fixed with 18.0.1. It would be nice to know what fixed it.
I'm betting for fix on bug 104411, but I'm not sure: commit 20f70ae3858bc213e052a8434f0e637eb36203c4 Author: Jason Ekstrand <jason.ekstrand@intel.com> Date: Tue Jan 23 23:47:26 2018 -0800 i965/draw: Set NEW_AUX_STATE when draw aux changes I'll mark as resolve then. Thanks for you time :)
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.