[SOLVED] Freezes randomly

Hi !

After days of research, I finally post here.
I'm experiencing some freezes randomly since I installed Manjaro.
When it freezes, I can't do anything, even the key commands and the screen stay on the present screen, my shift key flashes and the computer restarts after a few seconds.
I have Ubuntu in dualboot and the problem don't appear on it so I don't thing the problem is hardware.
Before Ubuntu I had windows 10 and I had blue screen errors so I think maybe that's the same problem as Manjaro...

I have the latest Bios version.
I tried to desactive tlp.
I tried many kernel command like acpi=off, noapic, pci=assign-busses, apicmaintimer, idle=poll, reboot=cold,hard, intel_pcstate=disable, intel_idle.max_cstate=1 (together or not ) and many others.
I have the latest microcode.
I tried with the two CPU frequency scaling drivers : intel_pstate and acpi_cpufreq.
Switched intel video driver to modesetting.
The problem appear also on Arch with Anarchy.
It happens when I'm on manjaro or a live usb, or when I install a new distribution.
I have the latest kernel LTS.
I don't have swap partition.
In journalctl nothing about the freeze.
If I listen a music, it repeat the last 2 secondes like the arch threads below.

Sometimes it freezes quickly when I plug an usb (no problem on journalctl) but without also.
it can freeze at login like 10h later.

My problem seems to be exactly like this arch users : https://bbs.archlinux.org/viewtopic.php?id=236686

Thanks in advance ! You are my last hope.

inxi -Fxxxz
System:
  Host: tom-ux331un Kernel: 5.6.8-1-MANJARO x86_64 bits: 64 compiler: gcc 
  v: 9.3.0 Desktop: Xfce 4.14.2 tk: Gtk 3.24.13 info: xfce4-panel wm: xfwm4 
  dm: LightDM 1.30.0 Distro: Manjaro Linux 
Machine:
  Type: Laptop System: ASUSTeK product: UX331UN v: 1.0 serial: <filter> 
  Mobo: ASUSTeK model: UX331UN v: 1.0 serial: <filter> 
  UEFI: American Megatrends v: UX331UN.308 date: 04/17/2019 
Battery:
  ID-1: BAT0 charge: 43.4 Wh condition: 43.4/50.1 Wh (87%) volts: 15.9/15.9 
  model: ASUSTeK ASUS Battery type: Li-ion serial: <filter> 
  status: Not charging cycles: 42 
CPU:
  Topology: Quad Core model: Intel Core i7-8550U bits: 64 type: MT MCP 
  arch: Kaby Lake rev: A L2 cache: 8192 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 32012 
  Speed: 900 MHz min/max: 400/4000 MHz Core speeds (MHz): 1: 900 2: 900 
  3: 901 4: 900 5: 900 6: 900 7: 900 8: 901 
Graphics:
  Device-1: Intel UHD Graphics 620 vendor: ASUSTeK driver: i915 v: kernel 
  bus ID: 00:02.0 chip ID: 8086:5917 
  Device-2: NVIDIA GP108M [GeForce MX150] vendor: ASUSTeK driver: nvidia 
  v: 440.82 bus ID: 01:00.0 chip ID: 10de:1d12 
  Display: x11 server: X.Org 1.20.8 driver: modesetting,nvidia 
  alternate: fbdev,intel,nouveau,nv,vesa resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2) v: 4.6 Mesa 20.0.6 
  direct render: Yes 
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio vendor: ASUSTeK 
  driver: snd_hda_intel v: kernel bus ID: 00:1f.3 chip ID: 8086:9d71 
  Sound Server: ALSA v: k5.6.8-1-MANJARO 
Network:
  Device-1: Intel Wireless 8265 / 8275 driver: iwlwifi v: kernel port: e000 
  bus ID: 03:00.0 chip ID: 8086:24fd 
  IF: wlp3s0 state: up mac: <filter> 
Drives:
  Local Storage: total: 476.94 GiB used: 37.45 GiB (7.9%) 
  ID-1: /dev/sda vendor: Micron model: 1100 MTFDDAV512TBN size: 476.94 GiB 
  speed: 6.0 Gb/s serial: <filter> rev: A031 scheme: GPT 
Partition:
  ID-1: / size: 191.37 GiB used: 37.45 GiB (19.6%) fs: ext4 dev: /dev/sda2 
Sensors:
  System Temperatures: cpu: 44.0 C mobo: N/A 
  Fan Speeds (RPM): cpu: 3100 
Info:
  Processes: 230 Uptime: 6m Memory: 15.50 GiB used: 986.9 MiB (6.2%) 
  Init: systemd v: 244 Compilers: gcc: 9.3.0 Shell: zsh v: 5.8 
  running in: xfce4-terminal inxi: 3.0.37
1 Like

I've had the same problem for over a year: random freezing at Manjaro Cinnamon and not in Mint Cinnamon. Nothing appeared in the logs and after trying all sorts of things, when I disconnected one of my disks I noticed that the problem disappeared. I replaced it with one of another brand but they came back.

After much research I discovered that there are two major differences between Manjaro and Mint: I/O Schedulers and TRIM. Manjaro was using "bfq scheduler" for all disks and "continuous TRIM" for SSD while Mint was using "cfq scheduler" for all disks and "periodic TRIM" for SSD. In the Arch wiki I found a way to change the scheduler used for each disk type. I decided to use "deadline" for SSD and "cfq" (same that Mint) for HDD (the disk that gave problems). For this I had to create the file:

sudo nano /etc/udev/rules.d/60-ioschedulers.rules

And add the lines:

# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

The "cfq scheduler" is available in kernel 4.14 which I use. To find out the scheduler used for each disk and those available in the current kernel:

cat /sys/block/sdX/queue/scheduler

I haven't had a problem for five days.

Regarding the TRIM, there are disks that have problems with it. That is why it is recommended not to use the "continuous TRIM" and to activate "periodic TRIM" so that it is performed only once a week and to minimize the risks. To do this, remove the "discard" from /etc/fstab file and activate fstrim.timer service with:

sudo systemctl enable fstrim.timer
sudo systemctl start fstrim.timer

I haven't tried this second solution yet.

1 Like

Hi,

First, thank you very much for your reply.

I have mq-deadline enable by default on Manjaro like Ubuntu.
Indeed it was in continuous trimming so I edited fstab and enable fstrim.timer like Ubuntu but freezes occur.
I found that blinking Shift key LED = Kernel panic.

Start with removing video-vesa from mhwd.
Also add nouveau.noaccel=1 as kernel boot option.

Hi openminded thanks for your help.

I already uninstalled video-vesa
I had the nvidia driver so I switched to nouveau.
I tried to put the kernel command but it keeps freezing.

inxi -G
Graphics:
  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel 
  Device-2: NVIDIA GP108M [GeForce MX150] driver: nouveau v: kernel 
  Display: x11 server: X.Org 1.20.8 driver: intel,nouveau 
  unloaded: modesetting resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2) v: 4.6 Mesa 20.0.6

Oh and I forgot to tell that before Ubuntu I had windows 10 and I had blue screen errors so I think that's maybe the same problem as Manjaro... That could be a clue.

Bad move, this one.
MX150 do not like nouveau driver, using it is a perfect way to face problems. You can try adding nouveau.modeset=0 but I suggest getting rid of nouveau completely anyway.

I found using kernels above 4.14 was causing periodic freezes. After changing my schedulers as you did the issue mostly went away.

I had an old 1 TB platter hard drive in my Manjaro box that would give me periodic problems. It speced out fine when smartmon was run on it, but I started to suspect it might be part of the problem. When I replaced the 1 TB platter with a 1 TB SSD the freezing issue seems to have completely gone away. I suspect the drive being very old was starting to contribute to the problems. Everything seems fine now.

My system has an SSD and an HDD. I have installed the three recommended kernels by Manjaro (4.14, 4.19 and 5.4), removed the file /etc/udev/rules.d/60-ioschedulers.rules and launched the "cat /sys/block/sd*/queue/scheduler" command with each of them to find out which schedulers are available and which one is the default in each case:

4.14
noop deadline cfq [bfq-sq]
noop deadline cfq [bfq-sq]

4.19
[mq-deadline] kyber bfq bfq-mq none
[mq-deadline] kyber bfq bfq-mq none

5.4
[mq-deadline] kyber bfq none
[mq-deadline] kyber bfq none

As we can see, each kernel has different schedulers, a different one by default and they use the same one for all drives regardless of the type of disk.

After all I have read, I have come to the following conclusions:

  • mq = multiqueue and sq = singlequeue.
  • bfq-mq, kyber, none and mq-deadline are multiqueue.
  • deadline, cfq and noop are singlequeue.
  • noop is not recommended for HDDs
  • HDDs are singlequeue.
  • SSDs are multiqueue.
  • The performance difference between multiqueue schedulers is so small, that on low-resource PCs it is preferable to use "none" to free up CPU usage.

All 4.14 kernel schedulers are singlequeue, so you may be losing performance on the SSD. Using deadline and cfq in 60-ioschedulers.rules for SSD and HDD everything works fine for me for days. Any scheduler could be used for the HDD except noop.

All 4.19 kernel schedulers are multiqueue except bfq. This allows us to use in 60-ioschedulers.rules multiqueue for SSD and singlequeue for HDD. Only bfq should be used for the HDD. The only combination that doesn't crash my system is "none" for SSD and "mq-deadline" for HDD.

All 5.4 kernel schedulers are multiqueue except bfq. This allows us to use in 60-ioschedulers.rules multiqueue for SSD and singlequeue for HDD. Only bfq should be used for the HDD. The only combination that doesn't crash my system is "none" for SSD and "mq-deadline" for HDD.

Using the default combination of either kernels hangs my system. I'm currently using the file:

sudo nano /etc/udev/rules.d/60-ioschedulers.rules

With the content:

# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"

That works fine for kernels 4.19 and 5.4.

2 Likes

Hello,

"Old" (2015) Intel documentation, indicating that you should not use the discard option on their SSDs.

Quote from page 6:

"Filesystem Recommendations

IMPORTANT: Do not discard blocks in filesystem usage.

Be sure to turn off the discard option when making your Linux filesystem. You want to allow the SSD manage blocks and its activity between the NVM (non-volatile memory) and host with more advanced and consistent approaches in the SSD Controller.

Core Filesystems:

• ext4 – the default extended option is not to discard blocks at filesystem make time, retain this, and do not add the “discard” extended option as some information will tell you to do.

• xfs – with mkfs.xfs, add the –K option so that you do not discard blocks.

If you are going to use a software RAID, it is recommended to use a chunk size of 128k as starting point, depending on the workload you are going to run. You must always test your workload."

A Monkey In Winter.

Yes I kept mq-deadline because cfq and deadline are legacy single queue I/O schedulers and were dropped from kernel since 5.0. Also I only have an integrated M.2 SSD. Besides my Ubuntu install wich doesn't freeze uses mq-deadline as well as periodic TRIM so I aligned the Manjaro TRIM setting on it, but that didn't seem to have any effect on my issue.

For openminded : Ok I only switched to nouveau to try out the "nouveau.noaccel" kernel parameter.

I tried to use a kernel before 4.14 without success.

Today I tried a ubuntu live usb to check if it was freezing, but no.
It seems to freeze only on arch based distribution and windows for the time being.

Good evening,

Today I tried to start with live usb of Debian and Fedora to see if there were freezing as Manjaro, Arch, and Windows.
Debian is like Ubuntu, zero freeze.
Fedora on the other hand freezes but without the shift key flashing. And if I take the option with basic graphics in the start boot it don't freeze... So when I have a 800x600 resolution it's ok.
But I tried put this resolution on Manjaro it didn't work.
Also I tried to found a processus which is on the normal Fedora live cd and not on the basic graphic but I only found stuffs like gdm-wayland instead of gdm-x.

So I recapitulate ->

• Freezes randomly on Manjaro, Fedora, Arch and other Arch based distrib. And maybe the same problem on windows it's why I came to Linux ( Blue screen of the dead)
• I can't do anything.
• Shift key flashes on Manjaro. (Kernel Panic)
• The computer restart.
• NO feeze on Ubuntu and debian, in live cd or installed OS AND Fedora with basic graphic option on live CD.

Hi,

For the one who have the same problem I solved it with this commands in the grub ( in /etc/default/grub/ after GRUB_CMDLINE_LINUX_DEFAULT= ) :

"noirqdebug pci=noaer i915.enable_psr=0 idle=nomwait i915.enable_dc=0 i915.enable_fbc=0 processor.max_cstate=1 rcu_nobs=0-11"

I have no idea what they do but It work ! :smiley:

Time will tell.

2 Likes

this solved the problem for me too, I have a same model laptop with same specs, thank you so much

This topic was automatically closed after 180 days. New replies are no longer allowed.

Forum kindly sponsored by