As the title says, my system randomly freezes while in use. I’m unable to share links to my logs yet from Manjaro Logs helper (above is the end of my link from log helper). I can usually reproduce the scenario while running MakeMKV on my system however today it was in the middle of a youtube video. I’ve been using linux for my home server for a few years now, but still would consider myself a novice in supporting it, so forgive me if there is a glaring error that I’m missing. It’s used as my personal desktop plus has 2 vm’s that run on it full time through virt-manager.
Are you using a swap partition/file? I used to have some issues similar to yours and it partially disappeared after I added just a 4Gb swap file. I was currently working without a swap btw.
I do not, I just went with the recommended install, I did not manually partition. From recollection it’s just a eufi partition and then the rest was ext4.
How did you come to that conclusion? To be more specific, is there anyway I can test that theory without reinstalling?
Further details. I ran 1 full turn of memtest86 today without any errors, and I had this problem with the Gnome variation of manjaro as well. This installation is only ~1 day old.
Make a swapfile and test it out when carrying out your normal tasks. It used to freeze while having video conferences and suddenly it didn’t happen anymore. I’m no expert, though. Are you perhaps using nvidia (I am)? I’ve heard that plasma and nvidia are not in the best terms, lol.
For my own curiosity, if anyone is willing to enlighten me. This system has 32G of ram. What does swap do that ram will not? My vm’s are allotted 10G ram between the 2 of them, so still 22 left for the main system.
Link to the logs for easy acces: Ubuntu Pastebin
The only thing I see that could be an issue in the inxi output is: resolution: 1: 3840x2160~60Hz 2: 3840x2160~30Hz Why is the 2nd screen on 30Hz?
The boot log is from a sessions that has not frozen yet?, check the option for -b -1
Or run journalctl --since=today --priority=3 to get all the errors or worse for ‘today’.
To get the text on the forum directly paste it like below:
One monitor uses displayport, the other hdmi. These were the refresh rates the system defaulted to on initial install. I don’t game or anything on this machine, so I’ve never investigated further.
Edit: I am unable to change the second display to 60Hz, it is not listed as an option.
Option for -b -1
-b -1 summary
Jan 29 17:21:20 Workstation kernel: microcode: microcode updated early to revision 0x28, date = 2019-11-12
Jan 29 17:21:20 Workstation kernel: Linux version 5.10.7-3-MANJARO (builduser@LEGION) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #1 SMP PREEMPT Fri Jan 15 21:11:34 UTC 2021
Jan 29 17:21:20 Workstation kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.10-x86_64 root=UUID=c3e3f37e-cf46-40bf-808b-733a15ae635c ro quiet apparmor=1 security=apparmor udev.log_priority=3
Jan 29 17:21:20 Workstation kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Jan 29 17:21:20 Workstation kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Jan 29 17:21:20 Workstation kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Jan 29 17:21:20 Workstation kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Jan 29 17:21:20 Workstation kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Jan 29 17:21:20 Workstation kernel: BIOS-provided physical RAM map:
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009efff] usable
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000a9a64fff] usable
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000a9a65000-0x00000000a9a6bfff] ACPI NVS
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000a9a6c000-0x00000000aa732fff] usable
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000aa733000-0x00000000aac17fff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000aac18000-0x00000000bd12afff] usable
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000bd12b000-0x00000000bd1bbfff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000bd1bc000-0x00000000bd202fff] usable
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000bd203000-0x00000000bd33dfff] ACPI NVS
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000bd33e000-0x00000000bdf7afff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000bdf7b000-0x00000000bdffefff] type 20
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000bdfff000-0x00000000bdffffff] usable
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000bf000000-0x00000000cf1fffff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Jan 29 17:21:20 Workstation kernel: BIOS-e820: [mem 0x0000000100000000-0x000000082fdfffff] usable
Jan 29 17:21:20 Workstation kernel: NX (Execute Disable) protection: active
Jan 29 17:21:20 Workstation kernel: efi: EFI v2.31 by American Megatrends
Jan 29 17:21:20 Workstation kernel: efi: ACPI=0xbd30b000 ACPI 2.0=0xbd30b000 SMBIOS=0xf04d0
Jan 29 17:21:20 Workstation kernel: SMBIOS 2.8 present.
Jan 29 17:21:20 Workstation kernel: DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme6, BIOS P2.80 03/06/2018
Jan 29 17:21:20 Workstation kernel: tsc: Fast TSC calibration using PIT
Jan 29 17:21:20 Workstation kernel: tsc: Detected 3999.077 MHz processor
Jan 29 17:21:20 Workstation kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Jan 29 17:21:20 Workstation kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Jan 29 17:21:20 Workstation kernel: last_pfn = 0x82fe00 max_arch_pfn = 0x400000000
Jan 29 17:21:20 Workstation kernel: MTRR default type: uncachable
Jan 29 17:21:20 Workstation kernel: MTRR fixed ranges enabled:
Jan 29 17:21:20 Workstation kernel: 00000-9FFFF write-back
--since=today --priority=3 summary
-- Journal begins at Thu 2021-01-28 14:47:36 EST, ends at Sat 2021-01-30 10:06:56 EST. --
-- No entries --
Second Edit: It just froze again, and journalctl logs look different.
A few more facts about my system in case they are useful. It is a dual boot setup with windows 10, both on separate ssd’s. There are also 4x3TB drives in a zfs raid setup. We homeschool, and I use this system to stream our homeschooling videos over Plex for maximum portability.
My VM’s run HassIO (home automation) and the second one is housing my Plex server. Hosted this way so if I decide to reinstall a new host OS (i.e. my recent move from manjaro gnome > kde) it’s a little less work (or so I think).
I use makemkv to rip my homeschooling DVD’s (this is done weekly), and Plex also records live TV. These all go straight to the zpool.
I’m happy to provide any other information if it’s useful.
@Hanzel I changed both monitors to 30HZ. I’ll test again today to see if freezing continues to occur. Does this seem likely?
I’m not sure if it is likely, it stuck out to me as odd. Not sure if I can help you any further.
The posted logs do not show anything that I would find disturbing, the coredump of systemsettings, no clue if it happens often there might be something wrong with kde settings.
One thing to check is that the resources you share with the VM’s like core’s must together allway’s be less then the host iirc. Some lockups can occur when over-committing.
I hope some more knowledgeable users can help you further
Unfortunately changing the frequency of the monitors had no effect.
journalctl --boot --priority=err shows more of the same.
There was a libvirtd error in there I’m pretty sure that had to do with having the auto-start at boot box checked. (now corrected)
I’m not convinced the VM’s have anything to do with it. System has 4 cores, 8 threads. Both VM’s are only getting 2 virtual cores (4 total). Plus the system freeze happened tonight while the VM’s weren’t running.
My gut says this is a hardware issue, but I don’t have anything to back that up with, other than a lack of evidence that it’s anything else. Since memory seemed to check out, should I test the CPU? If so, whats the recommended way to go about that?
This problem has persisted since August 2020, on both Gnome and KDE versions of Manjaro. It’s not something new, just something I’ve put up with. I have a little time at the moment so it would be nice if I could solve this annoyance. My wife who does half the homeschooling would also appreciate a more stable system, ha! She doesn’t mix well with technology.
I just experienced a total system hang after lots of time without experiencing them even with the swap fix (What I believed had worked fine). I moved back to my manjaro budgie backup and even with no swap it has been solid for the last 10 or so days. You should try budgie is really stable and doesn’t have the issues you might find with either gnome or kde. Too bad kde plasma does not play nice with nvidia.
Well here I am with the same issue as you. Forced me to reinstall and start all over. Same issues every now and again. I will add a 4gb swap and see what happens.