Just loaded Leap 15.0 and running it. But my computer keeps freezing for no apparent reason. Things run smoothly for a while then suddenly nothing responds.
I’m running Alienware with a Nvidia GTX980 card. I’ve installed the Nvidia G04 driver, though the same also happens with the G05 driver.
Im running top but there doesn’t appear to be anything obvious that’s grabbing resources.
ideas would be extremely welcome
How long ago was “just loaded”?
How long does a freeze last?
Which DE or WM are you using?
What are your basic hardware specs? e.g. ‘inxi -b’ (when installed)
I loaded fed it on Sunday.
Each freeze lasts from a few seconds to what seems like a minute. I’ve not timed them. But, on occasion it’s been long enough to lose an internet connection. It can also cause an “Unlocking failed” message when attempting to unlock my screen
I’m not sure what you mean by “DE or WM”. Please explain.
’inxi’ is not installed. I don’t know what that is. What are you wanting to know about my hardware specs?
Possibly relevant: when Leap is loading I get a list of messages saying “failed to get unique processor” and couldn’t find “mic handler”. The former messages appeared from when I first installed Leap 15.0, the second from when I installed the Nvidia driver.
Do these messages mean anything to anyone?
Several seconds is not a “freeze”, maybe just the system busy doing something. That might be anything from the system swapping (are you using 2GB RAM or so?), / root partition filling up (are you using btrfs on a disk partition smaller than 40 GB?) or simply some early maintenance jobs that will go away after a few hours of system use.
“DE” refers to Desktop Environment: Gnome is currently a memory hog, KDE/Plasma has issues with the proprietary Nvidia driver, “WM” refers to window managers like IceWM which are alternatives to DEs.
So to help you we need a clear idea of the specs of the HW in your system and the SW configuration (Filesystem, desktop environment etc.) you are using.
To help us debug your problem please run “top” in a small terminal window and leave it visible if possible, so that if a freeze occurs you can see (and report back here) the processes running at that moment.
Then open another terminal, become superuser by issuing:
su -
password: <enter the root password here>
Then one or more of the following commands should give a clue of possible problems. If anything suspicious shows up, please copy (SHIFT+CTRL+C in the terminal window) the result including the command and the prompt at the end and paste here between [CODE ] tags (use the # button above the editing space in the web interface).
To check for possible memory problems:
# free
To show the disk layout and filesystems in use:
# lsblk -alo NAME,SIZE,MOUNTPOINT,FSTYPE
To show filesystem usage:
# df
Please note, if you are using the btrfs filesystem for your / root filesystem ‘df’ does not give an accurate measure and you should use instead:
# btrfs filesystem df /
Since you are using an Nvidia dGPU and proprietary drivers, information about that is given by:
# lspci -nnk |grep -EA 3 "VGA|3D|Display"
In the unlikely case that the CPU might be overwhelmed, the following will show us the exact model:
# lscpu |grep Model
Please ask if anything is not clear to you.
Thanks for replying. In fact, I’ve been running **top **since I first had the problem, and I’ve seen no correlation between what’s running there and the occurrences of freezing and not freezing. However, I think that might be significant.
First, I should perhaps explain that there seem to be two different sorts of freezing - at least as I experience them - with one sometimes leading to the other.
The first sort is when a single application freezes. In this case I can switch to another application, most usefully top. Here I can see that the application that has frozen is not at the top of the list of running applications. This is not because it is waiting on a resource or paused, since sometime things freeze as I type. Sometimes, if I wait the application moves back to the top of the list and I can resume it. Other times everything freezes up and I can’t do anything. That’s the second sort of freeze.
Freezing can last, as I said before, from less than a minute to three, four minutes, occasionally longer.
When an application that freezes is conversing over the internet it can sometimes time out. If the application is one that times out then that is what happens. One one occasion, when I ran Speedtest in order to check if the problem was caused by internet connectivity, Firefox froze and my download speed, usually in the 70-75 or so Mbps range, came out as 0Mbps.
I’ve only once seen a problem with accessing an application locally, when I opened a photo from an email and, after a long pause, the window came up, after the freeze ended, that it could not access Gwenview. A rerun ran okay.
My machine, as I stated before, is an Alienware machine. Before installed Leap 15.0 on it I was running Leap 42,1 quite happily. As far as software is concerned, there are only two differences. One is that Dropbox will no longer run because I need to install an ext4 file system for this to happen. The other is that Baloo is running. Previously it used to crash soon after I started. Otherwise, everything I try to run is exactly as before.
As for the information you asked me to provide:
free
total used free shared buff/cache available
Mem: 32816840 7786684 282792 221692 24747364 24337900
Swap: 32817216 0 32817216
lsblk -alo NAME,SIZE,MOUNTPOINT,FSTYPE
NAME SIZE MOUNTPOINT FSTYPE
sda 1.8T
sda1 156M vfat
sda2 2G swap
sda3 40G btrfs
sda4 500M /boot/efi vfat
sda5 40G / btrfs
sda6 1.7T /home xfs
sda7 31.3G [SWAP] swap
sr0 1024M
btrfs filesystem df /
Data, single: total=12.01GiB, used=10.85GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=640.00MiB, used=545.06MiB
GlobalReserve, single: total=33.19MiB, used=0.00B
lscpu |grep Model
Model: 63
Model name: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Anything leap out there?
I should perhaps try running free the next time an application freezes on me
I omitted
lspci -nnk |grep -EA 3 "VGA|3D|Display"
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1)
Subsystem: NVIDIA Corporation Device [10de:1116]
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia
But I perhaps ought to explain that the freezing happened even before I upgraded my drivers to Nvidia. I initially thought it was happening because I had the wrong drivers loaded.
Nothing obvious from the info you posted. HW is quite capable, disk layout seems correct.
Your problem should be HW or configuration dependent since we are not seeing many other users complaining.
Just to rule out something, can you disable / uninstall baloo and see if you are still getting freezes? Baloo has been known to cause problems in the past but currently nobody is complaining…
We are seeing people complaining about the kernel ending in lp150.12.25.1: can you boot another (maybe older) kernel and see what happens?
Nvidia GPUs and / or proprietary drivers also gave headaches in the past, but since you experienced freezes also with the open source driver I would look elsewhere…
Apparently you are running KDE / Plasma as your desktop environment.
Can you please get to System Settings > Display and Monitor > Compositor and try to change the “Rendering Backend”, checking if you are still getting freezes with OpenGL2.0 or XRender?
Run all of the following and post the output:
iotop displays cumulative results; make sure it runs until freezes occur.
Thanks for the replies. They’ve been very useful.
I decided that the simplest thing to check (always check the easy things first, I say, and work towards the most complicated) was the suggestion that the problem might be Baloo, so I killed that and let things run for a couple of days. During that two days or so I did not have the problem once. Just to check if it was a coincidence (Since the occurrence of freezing appeared to have no pattern) I rebooted, letting Baloo run again. The freezing resumed, but stopped once I once more killed it.
This raises some questions:
Hi
From a quick search;
balooctl status
balooctl disable
You probably have to do on a per user basis, also check nothing down in ~/.config/autostart maybe there is something down in /etc/xdg/autostart but maybe the baloo* packages can be removed and locked/tabooed.
Baloo is a file indexer that if it works speeds up searches across/into files. One problem is that default it is set to pretty much index everything rather then restricting things to targeted directories. So it takes a huge amount of time to create the indexes and tends to slow things until it is done. But sometimes it never seems to finish.:’(
You may want to check System Settings > Search.
I have defaults Enable File Search: Checked, Also index file content: Unchecked
This works well since two years, baloo dumps core every now and then, but it never locks the machine:
Nov 30 07:18:15 erlangen baloo_file[7973]: UdevQt: unhandled device action “bind”
Nov 30 07:26:47 erlangen baloo_file[7973]: UdevQt: unhandled device action “unbind”
Nov 30 07:38:22 erlangen ksmserver[2262]: org.kde.kf5.ksmserver: Starting autostart service “/etc/xdg/autostart/baloo_file.desktop” ("/usr/bin/baloo_file")
Nov 30 07:38:22 erlangen baloo_file[2276]: KCatalog being used without a QApplication instance. Some translations won’t work
Nov 30 07:38:24 erlangen baloo_file[2879]: KCatalog being used without a QApplication instance. Some translations won’t work
Nov 30 07:38:24 erlangen baloo_file[2879]: Failed to register via dbus. Another instance is running
Nov 30 07:38:30 erlangen systemd-coredump[2921]: Resource limits disable core dumping for process 2276 (baloo_file).
Nov 30 07:38:30 erlangen systemd-coredump[2921]: Process 2276 (baloo_file) of user 1000 dumped core.
Nov 30 15:15:47 erlangen dbus-daemon[2164]: [session uid=1000 pid=2164] Activating service name=‘org.kde.runners.baloo’ requested by ‘:1.20’ (uid=1000 pid=2280 comm="/usr/bin/plasmashell “)
Nov 30 15:15:47 erlangen dbus-daemon[2164]: [session uid=1000 pid=2164] Successfully activated service ‘org.kde.runners.baloo’
Nov 30 17:47:05 erlangen ksmserver[30898]: org.kde.kf5.ksmserver: Starting autostart service “/etc/xdg/autostart/baloo_file.desktop” (”/usr/bin/baloo_file")
Nov 30 18:55:26 erlangen baloo_file[30916]: UdevQt: unhandled device action “bind”
Nov 30 18:55:26 erlangen baloo_file[30916]: UdevQt: unhandled device action “bind”
Nov 30 18:55:28 erlangen baloo_file[30916]: QObject::connect: invalid null parameter
Nov 30 18:55:28 erlangen baloo_file[30916]: QObject::connect: invalid null parameter
Nov 30 19:08:57 erlangen baloo_file[30916]: UdevQt: unhandled device action “unbind”
Nov 30 19:08:57 erlangen baloo_file[30916]: UdevQt: unhandled device action “unbind”
This is what I had as well, and it did cause me problems. This may well be a clash with some other configuration on my machine, or it might be a difference of hardware. I wasn’t able to use this PC for the first few months I had it until an updated version of SuSE was released.I can’t remember what the problem was, but it’s made me aware that not everyone gets the same results from the same OS.
Thanks for this information. I’ve now removed Baloo from /etc/xdg/autostart and things are working smoothly
Sure, removing /etc/xdg/autostart/baloo_file.desktop will disable baloo for now.
Beware: Updates of package baloo5-file will create this file again. A more canonical approach is given here: https://community.kde.org/Baloo/Configuration Current version is somewhat buggy and may require repair: https://forums.opensuse.org/showthread.php/534114-Baloo-file-indexing-daemon-closed?p=2888350#post2888350 Invoking the script once on my machine terminated a several weeks long sequence of core dumps (these were mildly annoying).