Some application become unresponsive when saving/exporting files

Support Software & Applications
1

When I save a file from brave-browser (for the first time after boot), and when I export images from GIMP (for the first time after boot), both of the applications become unresponsive for a few seconds.In case of brave-browser, the file is being downloaded in the background when its unresponsive.

Exporting files from audacity and Kdenlive doesn’t seem to have this problem yet. And saving files from vim, Kate (text editor) also doesn’t have this problem.

System:

  Kernel: 5.9.1-1-MANJARO x86_64 bits: 64 compiler: N/A 
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.9-x86_64 
  root=UUID=021ac587-2598-4e39-b7e0-5634da992ec8 rw apparmor=1 
  security=apparmor resume=UUID=3c820242-6b38-4805-ba9a-bda2db7c6952 
  udev.log_priority=3 
  Desktop: KDE Plasma 5.19.5 tk: Qt 5.15.1 wm: kwin_x11 dm: SDDM 
  Distro: Manjaro Linux 
Machine:
  Type: Laptop System: HP product: HP Pavilion Notebook 
  v: Type1ProductConfigId serial: <filter> Chassis: type: 10 serial: <filter> 
  Mobo: HP model: 8216 v: 83.18 serial: <filter> UEFI: Insyde v: F.52 
  date: 05/02/2019 
Battery:
  Device-1: apple_mfi_fastcharge model: N/A serial: N/A charge: N/A 
  status: N/A 
  Device-2: hidpp_battery_0 model: Logitech Wireless Mouse MX Master 2S 
  serial: <filter> charge: 100% (should be ignored) rechargeable: yes 
  status: Discharging 
CPU:
  Topology: Dual Core model: Intel Core i7-7500U bits: 64 type: MT MCP 
  arch: Amber Lake family: 6 model-id: 8E (142) stepping: 9 microcode: D6 
  L2 cache: 4096 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 23209 
  Speed: 793 MHz min/max: 400/3500 MHz Core speeds (MHz): 1: 792 2: 773 3: 778 
  4: 792 
  Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
  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 mitigation: Microcode 
  Type: tsx_async_abort status: Not affected 
Graphics:
  Device-1: Intel HD Graphics 620 vendor: Hewlett-Packard driver: i915 
  v: kernel bus ID: 00:02.0 chip ID: 8086:5916 
  Device-2: NVIDIA GM108M [GeForce 940MX] vendor: Hewlett-Packard 
  driver: nvidia v: 455.28 alternate: nouveau,nvidia_drm bus ID: 01:00.0 
  chip ID: 10de:134d 
  Device-3: Sunplus Innovation HP Wide Vision HD type: USB driver: uvcvideo 
  bus ID: 1-3:3 chip ID: 1bcf:2c87 
  Display: x11 server: X.Org 1.20.9 compositor: kwin_x11 
  driver: modesetting,nvidia display ID: :0 screens: 1 
  Screen-1: 0 s-res: 1920x1080 s-dpi: 75 s-size: 652x366mm (25.7x14.4") 
  s-diag: 748mm (29.4") 
  Monitor-1: eDP-1-1 res: 1920x1080 hz: 60 dpi: 142 
  size: 344x193mm (13.5x7.6") diag: 394mm (15.5") 
  OpenGL: renderer: GeForce 940MX/PCIe/SSE2 v: 4.6.0 NVIDIA 455.28 
  direct render: Yes 
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio vendor: Hewlett-Packard 
  driver: snd_hda_intel v: kernel alternate: snd_soc_skl bus ID: 00:1f.3 
  chip ID: 8086:9d71 
  Sound Server: ALSA v: k5.9.1-1-MANJARO 
Network:
  Device-1: Realtek RTL810xE PCI Express Fast Ethernet vendor: Hewlett-Packard 
  driver: r8169 v: kernel port: 3000 bus ID: 03:00.0 chip ID: 10ec:8136 
  IF: eno1 state: up speed: 100 Mbps duplex: full mac: <filter> 
  Device-2: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi 
  v: kernel port: 3000 bus ID: 05:00.0 chip ID: 8086:24fb 
  IF: wlo1 state: down mac: <filter> 
  IF-ID-1: eth0 state: down mac: <filter> 
Drives:
  Local Storage: total: 2.26 TiB used: 693.50 GiB (30.0%) 
  SMART Message: Unable to run smartctl. Root privileges required. 
  ID-1: /dev/sda vendor: Seagate model: ST2000LM003 HN-M201RAD size: 1.82 TiB 
  block size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s 
  rotation: 5400 rpm serial: <filter> rev: 0001 scheme: GPT 
  ID-2: /dev/sdb vendor: Western Digital model: WDS480G2G0A-00JH30 
  size: 447.13 GiB block size: physical: 512 B logical: 512 B speed: 6.0 Gb/s 
  serial: <filter> rev: 0400 scheme: GPT 
Partition:
  ID-1: / raw size: 429.75 GiB size: 422.01 GiB (98.20%) 
  used: 86.05 GiB (20.4%) fs: ext4 dev: /dev/sdb2 
Swap:
  Kernel: swappiness: 60 (default) cache pressure: 100 (default) 
  ID-1: swap-1 type: partition size: 17.08 GiB used: 0 KiB (0.0%) priority: -2 
  dev: /dev/sdb3 
Sensors:
  System Temperatures: cpu: 45.0 C mobo: N/A gpu: nvidia temp: 45 C 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 229 Uptime: 1h 29m Memory: 15.53 GiB used: 3.22 GiB (20.8%) 
  Init: systemd v: 246 Compilers: gcc: 10.2.0 clang: 10.0.1 Packages: 
  pacman: 1380 lib: 372 flatpak: 0 Shell: Bash v: 5.0.18 running in: konsole 
  inxi: 3.1.05  ```
2

Welcome to the forum! :slight_smile:

It could be down to two things.

  1. According to your system information, you have a dual-core processor, so it could just be a momentary hiccup due to process scheduling.

  2. You are using kernel 5.9, which is still fairly new and still has a lot more issues than 5.8 or an LTS kernel like 5.4.

I would propose testing this with an earlier kernel generation such as 5.4 LTS, and if the problem persists, then it’s really down to the fact that your machine has only two processor cores.

In the past, such hiccups were considered quite acceptable, and especially if you keep in mind that multi-core processor chips weren’t quite mainstream yet until the mid 2000s. There were multi-socket motherboards, yes, but those were exclusively reserved for high-end workstations and professional servers, given their retail price at the time.

Even with those hiccups, as long as the application eventually returns to functioning/responding normally again after downloading/saving the file, I wouldn’t worry about it.

The applications you’re mentioning as exhibiting this behavior are also GTK-based, and GTK is a different widget toolkit to what KDE Plasma and the KDE applications use ─ they are based upon Qt instead. And although the following is my personal observation, I often find GTK applications more problematic than Qt-based applications.

There are certain things for which you need GTK-based applications because there’s no viable Qt-based alternative ─ e.g. GIMP ─ but if it were possible, then I myself would definitely prefer a Qt-based solution. Again, this is personal, and I’m sure a lot of people here will disagree with me, but to each their own. :wink:

3

Thanks for the welcome!
I’ll try using the 5.4 LTS kernel and give an update after.
I have been using manjaro for months now and didn’t had this issue. I think I have this for about 2 weeks max, a few days before the latest kernel was released.

1 Like
4

Then it is indeed most likely down to an interaction between the 5.9 kernel and GTK. :wink:

5

Thank you for the help.
Used 5.4lts for a couple of days now and it seems to have fixed the problem.

1 Like
6

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