Stuttering and/or freezing when loading programs or writing to boot SSD

I just want to make sure, to sanity check.

tl;dr the Operating System for my current Fedora KDE install and most of everything else (basically all software is installed on it, with some games which require SSD and which I also tested before having a new HDD for Linux alone) are on a single 2tb SSD (normal Sata 3) and both sometimes when I open a lot of programs at the same time after boot (happened more up to Fedora 39) and/or when I am writing a lot of stuff (like Steam updating a game) the Operating System would either start stuttering or freezing for some time, up to 1 to 2 minutes.

Is it normal?

[ I KNOW it may just be the same with any and all Operating Systems, but honestly I don’t remember Windows stuttering and/or freezing, it just made me hang there while it loaded.]

If anyone is questioning why I posted this here:

I have Fedora KDE, so might as well ask directly here, and other than the fact that NOWHERE else there was anyone discussing this directly I’d have gotten no answer if I were to post on Reddit or anywhere else (here people actually answer to most things).

Hello again Isaac. :slightly_smiling_face: Glad to see that you are enjoying and benefiting from this forum!

I’m surprised that a decent SSD would have any trouble keeping up with your system’s I/O demands.

That said, if you want to prioritize your interactive applications over your data throughput, the BFQ I/O scheduler is designed to do that.

To see which I/O scheduler your drives are currently using, run the following command:

$ for i in /sys/block/sd?/queue/scheduler; do echo "$i: $(<$i)"; done

To change one of the drives to the BFQ scheduler, run the following commands:

$ sudo -i
# echo bfq > /sys/block/sda/queue/scheduler
# exit

Note that the change will not persist across system reboots. You’ll have to create a “udev” rule if you decide that you want the setting to be the default on system startup.

For example:

# cat << END > /etc/udev/rules.d/60-ioscheduler-rotational.rules
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="bfq"
END

HTH.

1 Like

I don’t think it’s doing anything.
Is this just a copy-paste?

Exclude the $ at the start. That is just an indicator that the command that follows can be run as a normal “unprivileged” user.

Likewise with the commands that start with a #. The # means that the command that follows must be run as root.

Your command prompt should end with $ or # depending on whether you are running commands as a privileged user or not.

Use sudo -i to escalate to the privileged root user account.

Use exit to de-escalate back to your normal user account.


Edit: Also, that command is only looking for drives attached to the SCSI Disk (sd) subsystem. You might need to modify it slightly if your drives are listed under other device node paths. You can use the following command to get a readout of all your drives and what their corresponding device node paths are.

$ lsblk --nodeps --paths -o name,size,model
~$ for i in /sys/block/sd?/queue/scheduler; do echo "$i: $(<$i)"; done
/sys/block/sda/queue/scheduler: none mq-deadline kyber [bfq] 
/sys/block/sdb/queue/scheduler: none mq-deadline kyber [bfq] 
/sys/block/sdc/queue/scheduler: none mq-deadline kyber [bfq] 
/sys/block/sdd/queue/scheduler: none mq-deadline kyber [bfq] 
/sys/block/sde/queue/scheduler: none mq-deadline kyber [bfq] 

I read that this is “for high performance SSDs and Nvme-s”.

.

This instead, other than having a brief breakdown (feel free to link any wiki page when you believe they’d be best) is something which I’d like to have for each and all systems.
I’d rather have “a superfast Nvme lose 2 seconds when copying 20gb” than “a superfast Nvme freezing for 1 minute because it’s copying 5gb” (this PC does not have the install on an Nvme, I’m just making a very practical example).

More than that, it’d be beneficial for those whom have a OLD computer (I’ll never leave a chance to link this work everywhere it’s relevant, both to help and because other than an “obsession” [fascination?] of mine) who just want to slam an SSD in there and run le desktop to read le taxes.

I take it you were happy with the results.

I think the BFQ scheduler was the default for a while, but these settings are not a one-size-fits-all sort of thing. The results can vary drastically depending on both your hardware and software configuration as well as the type of workload you run.

The mq-deadline scheduler, for example, works well on large server systems with lots of CPU cores and disk drives because it can do more “in parallel” (“mq” stands for multi-queue).

Good SSDs (on high bandwidth connections) might perform best without a scheduler.

So it’s just one of those things you have to tweak a bit and find what works best for you.

Gonna be honest, I have no idea what “none mq-deadline kyber [bfq]” actually means, other than what little I read before,
and frankly, as almost ALL End Users actually do, I don’t really care about the technicalities. I just want my PC to not freeze, EVER.

Open browser tabs, the writing documents, videos playing (which worse of all may keep on playing, but the UI does not respond, only keyboard inputs managing to control it as the last played frame before freezing keeps still upon the video’s window, like with YouTube), exploring Dolphin folders, even just the damn Task Manager (name changes with Distro, but it’s always the same job) sometimes fails to come up.

.

Talking about the present, if someone comes to Linux from Windows 10 or 11, what they experienced was a complete freeze happening almost never, and the less critical situation of “I can still move windows, but their contents lag and is frozen” usually has at least Task Manager opening.

It should already be default with any and all Operating Sytem ever
(because a case where the user’s input is second to anything else is a machine made not for the End User’s activities in mind)
that at least the “base functions of an OS”
(desktop, alt-tab, and some critical software like Task Manager)
should NEVER be dropped from “absolute priority position” because even if any developer actually has a reason to “make the OS stutter or freeze” as a feature it should be always avoided for the sake of the End User’s experience.

tl;dr How do I make Fedora KDE force its priority list to make the “base functions of an OS” and absolute priority to NEVER have freezes and stutters ever again?

But the typical Windows user also has not added 5 disk drives of radically different specs to their system and tried to span a single filesystem across them. (And if they did even Windows probably would do the same thing that your system is apparently doing.)

I’m not sure if you’ve linked your drives together with a common filesystem (or spanned a partition across them), but that is my guess as to why your system is not performing as well as you had hoped. But really, there are many ways a system can be poorly configured that would cause it to stutter, regardless of whether it is Windows or any other OS.

If I’m interpreting what you mean by “the base functions of an OS” correctly, then setting the system to use the BFQ scheduler by default (as you have done) is probably about the best you can do.

Really though, the BFQ scheduler should not be necessary. It is likely that it is just “masking” a deeper problem with the performance of your system. I’m guessing that your drives are “unequally yoked”, if you are familiar with that (very) old saying.[1] It might be a similar concept with your disk drives – one poor performing drive might be preventing the rest from being able to keep up.

Another possibility (among many really) is that you have mis-aligned partitions.[2]


  1. Ancient wisdom was that you don’t yoke (bind) a strong ox with a weaker ox or else their ability to pull the plow together will be even worse than either of them would be able to do on their own. ↩︎

  2. ↩︎

It happened even when the 2tb SSD was alone.

2 years ago I had my Nvme with Windows 10, 4tb HDD for games & files, 2tb HDD for recordings & video backups and then a 1tb SSD for some more games like Baldurs’ Gate 3.

There were some strange stutters on my PC with Windows 10 too, always have been, where W10 would “work in slow motion” where the sound skipped between “playing it” and “silence because of the skip”, the mouse input got delayed and then slowed while also skipping, and so would the windows too.

It would happen basically randomly, there was no way to reliably reproduce it.

.

I don’t know why, but my PC always had some strange stutters sometimes, but with Fedora it’s assured to happen when I do something like updating a game which is installed on the main 2tb SSD.

It might just be a poorly designed computer. Sometimes they are made with inadequate interrupt lines for the expansion cards or under-performing I/O controllers. Buggy firmware can also cause such problems.

Computers really are quite complex and there are many ways that things can go wrong.

You might check to see if your PC has any available firmware updates. You could also run something like Memtest86+ to see if there are any problems with the memory chips. You can try swapping out various components to see if any of them might be generating “noise” that could be interfering with the system. Beyond that, there probably isn’t much you can do.


Edit: I just saw it mentioned that a few other users are now reporting “freezing” when they upgrade their computers to Fedora Linux 42. If you are also using Fedora Linux 42, it is possible that there is a common (software) cause of the problem.

https://discussion.fedoraproject.org/search?q=Freeze%20%23ask%20after%3A2025-04-15%20in%3Atitle

Sounds like a platform timer thing and HPET and TSC stuff (I have an Ivy Bridge laptop that sped-up music when I ran a high-CPU app on Windows 10; I’ve never seen this Skylake+ though). I’m not too sure what to suggest for this.

If you have Intel SATA; if you were using Intel RST/RAID on, it’s possible both the NVMe and SATA drives were remapped through the RST controller, and on Windows Intel’s driver does MSI-X. Using MS Standard AHCI would have SATA drives on MSI (not X), but NVMe on MSI-X.

There were different IRQ amounts used with NVMe with AHCI vs RAID/RST modes too on Windows and it changes with CPU SMT/HT enabled/disabled; RST has like 3s faster boot according to Task Manager but real-world I’m not sure I saw a difference anywhere. I’m not sure if the IRQ amounts change between the SATA modes on Linux.


I was on F42 Workstation/GNOME and Xfce without any noticeable issue vs F41, but I do different things :stuck_out_tongue:

  • mitigations=off and i915.mitigations=off
  • iommu=pt and VT BIOS-disabled (no re-map)
  • C-States off, tuned removed, forced max-perf with x86_energy_perf_policy
  • ext4 root (not Btrfs)
  • Other stuff (notes)

I’m thinking disabling IOMMU would be a good start (if CPU virtualization is enabled Fedora does IOMMU device remapping by-default).

1 Like

My apologies.

~$ inxi -Fzxx
System:
  Kernel: 6.14.2-300.fc42.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 15.0.1
  Desktop: KDE Plasma v: 6.3.4 tk: Qt v: N/A wm: kwin_wayland dm: SDDM
    Distro: Fedora Linux 42 (KDE Plasma Desktop Edition)
Machine:
  Type: Desktop Mobo: ASUSTeK model: PRIME B450-PLUS v: Rev X.0x
    serial: <superuser required> part-nu: SKU UEFI: American Megatrends v: 3211
    date: 08/10/2021
CPU:
  Info: 6-core model: AMD Ryzen 5 5600X bits: 64 type: MT MCP arch: Zen 3+
    rev: 0 cache: L1: 384 KiB L2: 3 MiB L3: 32 MiB
  Speed (MHz): avg: 3598 min/max: 550/4654 boost: enabled cores: 1: 3598
    2: 3598 3: 3598 4: 3598 5: 3598 6: 3598 7: 3598 8: 3598 9: 3598 10: 3598
    11: 3598 12: 3598 bogomips: 88805
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
  Device-1: NVIDIA TU106 [GeForce RTX 2070] vendor: ZOTAC driver: nvidia
    v: 570.133.07 arch: Turing pcie: speed: 8 GT/s lanes: 16 ports: active: none
    off: DP-1,DP-2,DP-3 empty: DVI-D-1,HDMI-A-1 bus-ID: 09:00.0
    chip-ID: 10de:1f02
  Display: wayland server: X.org v: 1.21.1.16 with: Xwayland v: 24.1.6
    compositor: kwin_wayland driver: gpu: nvidia,nvidia-nvswitch display-ID: 0
  Monitor-1: DP-1 model: Philips 109P2 res: 1280x1024 hz: 85 dpi: 72
    diag: 450mm (17.7")
  Monitor-2: DP-2 model: MSI Optix MAG27CQ res: 2560x1440 hz: 144 dpi: 110
    diag: 686mm (27")
  Monitor-3: DP-3 model: BenQ ZOWIE XL LCD res: 1920x1080 dpi: 90
    diag: 623mm (24.5")
  API: EGL v: 1.5 platforms: device: 0 drv: nvidia gbm: drv: nvidia
    surfaceless: drv: nvidia wayland: drv: nvidia x11: drv: nvidia
  API: OpenGL v: 4.6.0 vendor: nvidia v: 570.133.07 glx-v: 1.4
    direct-render: yes renderer: NVIDIA GeForce RTX 2070/PCIe/SSE2
    display-ID: :0.0
  API: Vulkan v: 1.4.309 surfaces: xcb,xlib,wayland device: 0
    type: discrete-gpu driver: N/A device-ID: 10de:1f02 device: 1 type: cpu
    driver: N/A device-ID: 10005:0000
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: nvidia-settings,nvidia-smi
    wl: wayland-info x11: xdriinfo, xdpyinfo, xprop, xrandr
Audio:
  Device-1: NVIDIA TU106 High Definition Audio vendor: ZOTAC
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 09:00.1 chip-ID: 10de:10f9
  Device-2: Advanced Micro Devices [AMD] Starship/Matisse HD Audio
    vendor: ASUSTeK driver: snd_hda_intel v: kernel pcie: speed: 16 GT/s
    lanes: 16 bus-ID: 0b:00.4 chip-ID: 1022:1487
  Device-3: C-Media SADES Locust Plus
    driver: hid-generic,snd-usb-audio,usbhid type: USB rev: 1.1 speed: 12 Mb/s
    lanes: 1 bus-ID: 1-7:3 chip-ID: 0d8c:0012
  API: ALSA v: k6.14.2-300.fc42.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.4.2 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: ASUSTeK RTL8111H driver: r8169 v: kernel pcie: speed: 2.5 GT/s
    lanes: 1 port: f000 bus-ID: 04:00.0 chip-ID: 10ec:8168
  IF: enp4s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 17.74 TiB used: 7.07 TiB (39.8%)
  ID-1: /dev/nvme0n1 vendor: Kingston model: SA2000M8500G size: 465.76 GiB
    speed: 31.6 Gb/s lanes: 4 serial: <filter> temp: 29.9 C
  ID-2: /dev/sda vendor: Seagate model: ST4000DM004-2U9104 size: 3.64 TiB
    speed: 6.0 Gb/s serial: <filter>
  ID-3: /dev/sdb vendor: Mushkin model: MKNSSDEL2TB size: 1.82 TiB
    speed: 6.0 Gb/s serial: <filter>
  ID-4: /dev/sdc vendor: Seagate model: ST10000NM0046 size: 9.1 TiB
    speed: 6.0 Gb/s serial: <filter>
  ID-5: /dev/sdd vendor: Western Digital model: WD20PURZ-85AKKY0
    size: 1.82 TiB speed: 6.0 Gb/s serial: <filter>
  ID-6: /dev/sde vendor: Kingston model: SA400S37960G size: 894.25 GiB
    type: USB rev: 3.1 spd: 5 Gb/s lanes: 1 serial: <filter>
  ID-7: /dev/sdf vendor: SanDisk model: Cruzer Glide size: 28.65 GiB
    type: USB rev: 2.0 spd: 480 Mb/s lanes: 1 serial: <filter>
Partition:
  ID-1: / size: 1.82 TiB used: 877.64 GiB (47.1%) fs: btrfs dev: /dev/sdb3
  ID-2: /boot size: 973.4 MiB used: 331.3 MiB (34.0%) fs: ext4
    dev: /dev/sdb2
  ID-3: /boot/efi size: 598.8 MiB used: 19.3 MiB (3.2%) fs: vfat
    dev: /dev/sdb1
  ID-4: /home size: 1.82 TiB used: 877.64 GiB (47.1%) fs: btrfs
    dev: /dev/sdb3
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 1.29 GiB (16.1%) priority: 100
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 46.8 C mobo: N/A
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 16 GiB available: 15.52 GiB used: 5.5 GiB (35.4%)
  Processes: 435 Power: uptime: 1h 26m wakeups: 0 Init: systemd v: 257
    target: graphical (5) default: graphical
  Packages: pm: rpm pkgs: N/A note: see --rpm pm: flatpak pkgs: 33
    Compilers: gcc: 15.0.1 Shell: Bash v: 5.2.37 running-in: konsole
    inxi: 3.3.37

Anyways, thanks for your input.
Could you dumb it down? I’d like to have an easy, not-so-precise explanation of all the things you listed.

If it just happened to others, then I don’t believe it’s the same issue.

Every once in a while (1-2 months) my computer (under Windows 10) just went https://youtu.be/9SCeK6BxAI4?si=Zi2JUt-G3_SX6ftU and now on Linux it does something similar when “the same Drive as the OS is installed upon gets hammered with copy/paste action” (it may also do the same thing Windows 10 did, I mostly believe that they are separate, distinct events).

I am checking multiple things now, even if I’m tired, so I ain’t gonna do anything which requires important work now.

Still one important thing I am checking too is that the “Sata 5 and 6 connectors” do not seem to work.
I have to check why, but I just hope that they are not broken or something. I don’t want to buy a PCI-e Sata expansion card or a new Motherboard…

Oh…
Oh that’s sad…


I have to buy a Sata controller for more Drives… : (

1 Like

It looks like the freezing that others are reporting is turning out to be something to do with the WiFi driver. It doesn’t look like your system has a WiFi card, so it’s probably unrelated to your problem, but you might try disabling your network driver (r8169) just to see if it makes any difference. (Maybe the easiest way to test it would be to temporarily disable the network device in the BIOS settings?) That would be a long-shot though.

Mate, gonna be honest:

I believe it’s somehow the OS choking and dying when I am copying data onto it.
Happens mainly when I am updating BGs over GBs of data on Steam.

1 Like

I’d start to try to rule that out with a clean install with ext4 no separate /home

Could you explain it better?

.

Regardless of that, my very good reason which brings me to this firm belief is that no other PC of mine had ever experienced a straight-up freeze when copying to and from the boot disk (even the mouse doesn’t move), while Fedora (KDE) seems to just do that if you copy lots of GB, or as I said before, even when you just booted up the PC and started a couple things as Brave, Steam and Discord.

.

Now all my PCs are set, so I don’t have to copy much data to and from their boot drives at any time, so I have to go from memory about these things.