Upgraded from Kernel 4.19.143-1 to 5.4.62-1 and noticed that videos in a Steam Games ("Supreme Commander") are now stuttering when the game is launchs

After upgrading from Kernel 4.19.143-1 to 5.4.62-1 I noticed that videos (beginning cinematic and in game) in a Steam Games (“Supreme Commander”) is now stuttering when the game is launched. If I reboot my laptop back into the older Kernel 4.19.143-1 the stuttering stops.

The Proton DB\Steam recommended settings “Launch Flags:Disable Esync”, which are these settings “PROTON_NO_ESYNC=1 PROTON_DUMP_DEBUG_COMMANDS=1 %command%”
Source: https://www.protondb.com/app/9420

When I was on Kernel 4.19.143-1 and Esync was not disabled I would see similar stuttering in the game video.

  • Kernel 4.19.143-1 gets 30-45 fps during video playback

  • Kernel 5.4.62-1 gets 1 FPS during video playback.

To Troubleshoot:

  • Verified the CPU Governor was changing from Battery Saver to Performance when changing from Battery to AC Power adapter power (using sudo auto-cpufreq --log)
  • Verified that CPU turbo was turning on when system is loaded using sudo auto-cpufreq --log).
  • Tried playing High definition videos on on YouTube which generated CPU loads of 10 to 70% (No obvious frame drops or stuttering).
  • Tried running Supreme Commander with battery or AC to see if the gameplay video would stop stuttering (stuttered the same way).
  • Tried enabling and disabling esync in Steam with Kernel 5.4.62-1 and still the video stutters.
  • Updated all Manjaro and AUR packages from stable and AUR

Note: The issue presents as the game launches and plays the game introduction videos.

Question:

(1) I’m at a loss at how to troubleshoot this issue, so lookng for suggestions.

Environment:

System:    Kernel: 5.4.64-1-MANJARO x86_64 bits: 64 compiler: gcc v: 10.2.0
	       parameters: BOOT_IMAGE=/boot/vmlinuz-5.4-x86_64
	       root=UUID=85ccbb8b-086b-4c3b-a6c8-a45951356c8e rw apparmor=1 security=apparmor
	       usbcore.autosuspend=-1
	       Desktop: GNOME 3.36.6 tk: GTK 3.24.23 wm: gnome-shell dm: GDM 3.36.3
	       Distro: Manjaro Linux
Machine:   Type: Laptop System: LENOVO product:  v: ThinkPad X230 serial: <filter>
	       Chassis: type: 10 serial: <filter>
	       Mobo: LENOVO model:  serial: <filter> UEFI [Legacy]: LENOVO
	       v:  (2.77 ) date: 09/24/2019
Battery:   ID-1: BAT0 charge: 31.2 Wh condition: 34.9/57.7 Wh (60%) volts: 11.9/11.1
	       model: LGC 45N1025 type: Li-ion serial: <filter> status: Discharging
CPU:       Topology: Dual Core model: Intel Core i5-3320M bits: 64 type: MT MCP arch: Ivy Bridge
	       family: 6 model-id: 3A (58) stepping: 9 microcode: 21 L2 cache: 3072 KiB
	       flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 20760
	       Speed: 1219 MHz min/max: 1200/2600 MHz Core speeds (MHz): 1: 1219 2: 1255 3: 1215
	       4: 1304
	       Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages
	       Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
	       Type: mds mitigation: Clear CPU buffers; SMT vulnerable
	       Type: meltdown mitigation: PTI
	       Type: spec_store_bypass
	       mitigation: Speculative Store Bypass disabled via prctl and seccomp
	       Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
	       Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW,
	       STIBP: conditional, RSB filling
	       Type: srbds status: Vulnerable: No microcode
	       Type: tsx_async_abort status: Not affected
Graphics:  Device-1: Intel 3rd Gen Core processor Graphics vendor: Lenovo driver: i915 v: kernel
	       bus ID: 00:02.0 chip ID: 8086:0166
	       Device-2: Acer ThinkPad Integrated Camera type: USB driver: uvcvideo bus ID: 1-1.6:4
	       chip ID: 5986:02d2
	       Display: x11 server: X.Org 1.20.8 compositor: gnome-shell driver: intel
	       display ID: :0 screens: 1
	       Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 361x203mm (14.2x8.0")
	       s-diag: 414mm (16.3")
	       Monitor-1: LVDS1 res: 1366x768 hz: 60 dpi: 124 size: 280x160mm (11.0x6.3")
	       diag: 322mm (12.7")
	       OpenGL: renderer: Mesa DRI Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 20.1.7
	       compat-v: 3.0 direct render: Yes
Audio:     Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Lenovo
	       driver: snd_hda_intel v: kernel bus ID: 00:1b.0 chip ID: 8086:1e20
	       Sound Server: ALSA v: k5.4.64-1-MANJARO
Network:   Device-1: Intel 82579LM Gigabit Network vendor: Lenovo driver: e1000e v: 3.2.6-k
	       port: 6080 bus ID: 00:19.0 chip ID: 8086:1502
	       IF: enp0s25 state: down mac: <filter>
	       Device-2: Intel Centrino Advanced-N 6205 [Taylor Peak] driver: iwlwifi v: kernel
	       port: efa0 bus ID: 03:00.0 chip ID: 8086:0085
	       IF: wlp3s0 state: up mac: <filter>
Drives:    Local Storage: total: 465.76 GiB used: 55.79 GiB (12.0%)
	       ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB block size:
	       physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 1B6Q scheme: MBR
	       SMART Message: Unknown smartctl error. Unable to get data.
Partition: ID-1: / raw size: 147.46 GiB size: 144.15 GiB (97.75%) used: 55.79 GiB (38.7%)
	       fs: ext4 block size: 4096 B dev: /dev/sda4
Swap:      Alert: No Swap data was found.
Sensors:   System Temperatures: cpu: 48.0 C mobo: 0.0 C
	       Fan Speeds (RPM): cpu: 0
Info:      Processes: 205 Uptime: 22m Memory: 11.41 GiB used: 1.17 GiB (10.2%) Init: systemd
	       v: 246 Compilers: gcc: 10.2.0 Packages: 1476 pacman: 1459 lib: 411 flatpak: 11
	       snap: 6 Shell: fish v: 3.1.2 running in: alacritty inxi: 3.1.05

Looping in @megavolt as he helped with the original upgrade. This issue was noticed as I have been testing the 5.4.62-1. I already fixed the thinkfan and auto-cpufreq errors I found yesterday.

1 Like

Looks like the PROTON_NO_ESYNC=1 startup command is being ignored. I did some looking in the Proton project and I found the below ticket. Just in my case the issue is only present in Kernel 5.4.62-1.

I will need some assistance to gather the evidence to prove my guess. Maybe guidance on where to file a bug.

Hi :slight_smile:

So you guess it is not fixed for you with Proton 5.0-7 ?

If not done already, it would be essential to have a debug log:

PROTON_DEBUG_DIR=/home/$USER/proton_debug PROTON_DUMP_DEBUG_COMMANDS=1 PROTON_LOG=1 PROTON_NO_FSYNC=1 PROTON_NO_ESYNC=1 %command%

If using DXVK, then it would good to activate the HUD also:

DXVK_HUD=full

Hi Megavolt,

Thanks for your feedback. My Steam setup actually was using Proton 5-0-9. I made sure I forced the configuration in the Steam settings.

I read through the notes\links you provided and ended up disabling both esync and fsync and the problem went away (now frame rates are back up to 60 FPS. So not sure if this is expected or a bug. But hopefully the post being here will make it easier for other people to fix the issue I hit.

PROTON_NO_FSYNC=1 PROTON_NO_ESYNC=1 %command%

i will go ahead and write a bug in the Proton project to see what they have to say. Thanks again for your assistance.

1 Like

It is actually not a bug. fsync and esync are for games which uses more than one cpu core. It handles it somehow better. But on older games which are running on one core it could drops fps. That is known.

Fsync is integrated into the kernel, but esync works in the userspace. Therefore fsync is faster.

Perhaps then the next best way to help people is to post the settings I used in the Proton DB databases for other Linux users to find. Previously the “Supreme Commander: Forged Alliance” community has always recommended the PROTON_NO_ESYNC=1 %command% setting. This will be a change in convention for sure.

Related Links:
https://www.protondb.com/app/9420
https://wiki.faforever.com/index.php?title=Setting_Up_FAF_Linux

Don’t file a useless bug with Proton. This isn’t a bug. Fsync and Esync are enabled by default when available. Manjaro (which is the only distro to do this) has started to enable fsync on its kernels a few weeks ago. Well, fsync relies on esync. So if your kernel supports fsync, then you have to disable both fsync and esync in order for esync to be disabled. That’s not a bug, it’s completely intended behavior.

Thanks for the feedback.

Then my follow up question here is as an end user what documentation would I look at to know that I will have to explicitly disable both FSYNC and ESYNC together? Just scanning the ProtonDB, Reddit, and other Software Company Forums did not mention this relationship.

This link below is a good example of how someone like me can get confused trying to troubleshoot a problem seeing he numerous assumptions. I prefer to reference documentation (why I also try to source the information in my notes).

https://github.com/ValveSoftware/Proton/issues/2922

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.