Counter Strike 2 becomes temporarily unresponsive in loading screens and disconnects from server (Linux)

Open adixdzx15 opened this issue 4 months ago • 4 comments

This bug was introduced at some point between 25-06-2025 and 05-08-2025.

The issue seems to be driver-related, but I post it here, since the release date for one of the driver versions under which the issue occurs is the 28-05-2025, so before the first occurrence of the issue for me. So I believe it to be caused by an interaction of CS2 with the driver API rather than an issue with the driver itself. But I might be wrong.

Description

In a loading screen, CS2 starts using exactly 100% of 3 of my (logical) CPU cores at maximum frequency and becomes unresponsive ("Application not responding") for about 3-7 seconds. After that, the loading screen completes. However, if the loading screen was due to map change (e.g. in Arms Race), the game client does no longer send any information to the server, but -apart from a short period of packet loss- keeps receiving data from the server (as seen in the network telemetry statistics). This then causes the connection to the server to time out after about 30 total seconds (loading screen + time spent in team selection screen).

Occurrence

The issue always occurs when starting the game (while showing the "Counter Strike 2" splash screen, but also briefly while showing the "Valve" logo) and when loading to the main menu. However, these occurrences are at best annoying, since they only produce "Application not responding" notifications, but let the game work normally afterwards.

The issue normally does not appear when loading into a map from the main menu. The issue does appear in this case if the game shader cache (at .steam/steam/steamapps/shadercache/730/mesa_shader_cache_sf) and the general shader cache (at .cache/mesa_shader_cache) were deleted. In that case, it will occur the first few times when loading a map from the main menu (even the same one multiple times and even if loading the same map in practice mode before). The issue partially appears if loading a map for the first time after a game update, but the match is not disconnected in that case.

The issue almost always occurs when changing to a different map (i.e. in Casual, Deathmatch or Arms Race). Very rarely, seemingly at random, the issue does not occur when changing a map (I was unable do deduce a pattern).

Hypotheses

I assume that this is related to the shader cache/graphics API, for the following reasons:

The pattern of 3 CPUs running at max capacity is also present in the regular shader compilation occurring after a game update (see above)
When changing a map, the hang (at least when I was paying attention to it) always occurs at a rather late stage of the "Compiling shaders" step (e.g. with about 100 out of 1700 shaders or 3 out of 353 remaining)
As described above, the problem is temporarily amplified by deleting the shader cache

I also assume that the issue is related to an interaction with Mesa specifically (maybe the rather recent change back to single file caching?), but I cannot be certain, since my only indication for that is the following:

A friend of mine with an NVIDIA graphics card (RTX 3090, to be precise), who is running the proprietary NVIDIA Linux drivers, was unable to reproduce the issue

Reproducibility/System information

Steam system information

Computer Information:
Manufacturer: Micro-Star International Co., Ltd.
Model: PRO Z690-A WIFI (MS-7D25)
Form Factor: Desktop
No Touch Input Detected

Processor Information:
CPU Vendor: GenuineIntel
CPU Brand: 13th Gen Intel(R) Core(TM) i5-13600K
CPU Family: 0x6
CPU Model: 0xb7
CPU Stepping: 0x1
CPU Type: 0x0
Speed: 5100 MHz
20 logical processors
14 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Unsupported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
BMI1: Supported
BMI2: Supported
F16C: Supported
FMA: Supported

Operating System Version:
"Arch Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 6.15.9-arch1-1
X Server Vendor: The X.Org Foundation
X Server Release: 12401008
X Window Manager: Hyprland :D
Steam Runtime Version: steam-runtime_1.0.20250519.130917

Client Information:
Version: 1751405894
Browser GPU Acceleration Status: Enabled
Browser Canvas: Enabled
Browser Canvas out-of-process rasterization: Enabled
Browser Direct Rendering Display Compositor: Disabled
Browser Compositing: Enabled
Browser Multiple Raster Threads: Enabled
Browser OpenGL: Enabled
Browser Rasterization: Enabled
Browser Raw Draw: Disabled
Browser Skia Graphite: Disabled
Browser Video Decode: Enabled
Browser Video Encode: Disabled
Browser Vulkan: Disabled
Browser WebGL: Enabled
Browser WebGL2: Enabled
Browser WebGPU: Disabled
Browser WebNN: Disabled

Video Card:
Driver: Intel Mesa Intel(R) Arc(tm) A770 Graphics (DG2)
Driver Version: 4.6 (Compatibility Profile) Mesa 25.2.0-cachyos1.1
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 164 Hz
VendorID: 0x8086
DeviceID: 0x56a0
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 2560 x 1440
Desktop Resolution: 2560 x 1440
Primary Display Size: 23.62" x 12.99" (26.93" diag), 60.0cm x 33.0cm (68.4cm diag)
Primary VRAM: 16288 MB

Sound card:
Audio device: Realtek ALC897
Memory:
RAM: 31864 Mb
VR Hardware:
VR Headset: None detected

Miscellaneous:
UI Language: English
LANG: en_UK.UTF-8
Total Hard Disk Space Available: 897773 MB
Largest Free Hard Disk Block: 255945 MB

Storage:
Number of SSDs: 3
SSD sizes: 2048G,2000G,1024G
Number of HDDs: 0
Number of removable drives: 0

System specs:

graphics card: Intel Arc A770 LE
CPU: Intel Core i5 13600K
Motherboard MSI Z690 Pro WiFi DDR5

The issue first occured on the following OS and configuration (which most of my testing was conducted on as well):

Arch Linux, latest default packages and default Kernel (Mesa 25.1.7)
Hyprland compositor
CS2 running in native Wayland

The issue persisted upon switching to CS2 running in Xwayland. The issue also persisted in the following configuration:

Arch Linux, optimized packages from CachyOS, adjusted Kernel from CachyOS (Mesa 25.2.0)
Hyprland compositor
CS2 running in native Wayland/Xwayland

The issue was also present in the following configuration:

Linux Mint 22.1, updated to the latest packages (Mesa 25.0.7)
Cinnamon desktop
CS2 running in X11

I was not able to reproduce the issue in Windows 11. However, the issue still persisted on Linux after performing a firmware update of my graphics card in Windows.

Attempts to fix the issue (apart from the above configuration switches)

Delete all CS2 shader data (.steam/steam/steamapps/shadercache/730)
Delete all shader data related to CS2 (the above in addition to .cache/mesa_shader_cache)
Uninstall the game and perform steps 1 and 2, then reinstall
Skip shader precompilation
Do not skip shader precompilation
Delete ALL steam shader data (.steam/steam/steamapps/shadercache/*)

Additional notes

Upon executing step 4, I noticed that the Mesa part of the shader cache for CS2 did not seem to grow larger than about 150 MB (correction: this size does not seem to be consistent, maybe it is just growing slowly). With shader precompilation, it grows to about 2.4 GB. Maybe that is related to this part of the Mesa documentation stating that single file caching does not support cache size limits? But that does not really seem consistent with the map load from the main menu completing without any shader compilation CPU spike.
Running CS2 with MESA_SHADER_CACHE_SHOW_STATS=1 shows a relatively large number of cache misses (greater than or equal to the number of hits, about 1300 hits/misses), even when only loading to the main menu. Though I am not sure whether this number is normal, since I do not have a working baseline for comparison.

Anyways, that is all I was able to figure out. I really hope someone who knows more about the internal workings will be able to find the root of the issue, since I pretty much am out of ideas.

Aug 12 '25 11:08 adixdzx15