Leap freezes for a few seconds every few minutes

Hello openSUSE gurus,

I’ve been dealing with a frustrating problem that has made me want to avoid using my computer: this machine is constantly freezing every few minutes for up to 5-10s, and I’m not sure what is going on. During these ‘freezes’, the mouse is still operational and can be moved on the screen, but clicking on anything doesn’t work; however, the click is sometimes registered and occurs the instant the freeze is finished. Typing normally during a freeze works due to the same behavior - whatever I type is ‘saved’ and appears on the screen after the the freeze is done. Youtube videos can freeze also, but the sound continues normally and catches up when the freeze is over. As you can see, this is apparent throughout the whole system.

I’m on opensuse Leap 42.1, running GNOME desktop. I could be running as little as a terminal, a web-browser (chromium), and sometimes a text editor if I really want to get crazy, and this still occurs. CPU and RAM usage is minimal, so it’s not like my machine is going into SWAP or something.

I don’t mess around with my machine too much, but I did have an internet issue a few months ago with the same machine (see the my post), where I adjusted some network options on my machine due to a wifi problem. I’m not sure if those changes caused this problem, I’ve been reluctantly dealing with this for a number of months now and haven’t taken the time to submit an issue.

Are there any checks that I can do to determine what the issue is here?

You should probably start with overall system resources, like

CPU make and model
RAM physical, total
Hard drive - Size, RPM and seek time

If your overall system resources are very minimal like a relatively old CPU, 4GB RAM or less, or an older, slower hard drive with slow seek times, then you should either use less resources (turn off unnecessary, open fewer apps at once, etc) or change to a “lighter” Desktop than what you are using, in the openSUSE world XFCE is a good alternative to Gnome.

TSU

Thanks for the quick reply, here are some stats to answer your question:

CPU - Intel i7 dual core (computer sees 4 due to hyperthreading), purchased back in 2012 on a Toshiba laptop. Some specs of the first ‘core’, of which the other 3 are identical.:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core™ i7-3630QM CPU @ 2.40GHz
stepping : 9
microcode : 0x1b
cpu MHz : 3313.593
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt
bugs :
bogomips : 4789.09
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

RAM is 8 GB

I only have about 25% of my /home/ directory used up, which I determined by using ‘df -H’:

chris@linux-ugzt:~> df -H
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.2G 0 4.2G 0% /dev
tmpfs 4.2G 118M 4.1G 3% /dev/shm
tmpfs 4.2G 2.3M 4.2G 1% /run
tmpfs 4.2G 0 4.2G 0% /sys/fs/cgroup
/dev/sda9 43G 33G 9.4G 78% /
/dev/sda9 43G 33G 9.4G 78% /.snapshots
/dev/sda9 43G 33G 9.4G 78% /tmp
/dev/sda9 43G 33G 9.4G 78% /opt
/dev/sda9 43G 33G 9.4G 78% /usr/local
/dev/sda9 43G 33G 9.4G 78% /srv
/dev/sda9 43G 33G 9.4G 78% /boot/grub2/x86_64-efi
/dev/sda9 43G 33G 9.4G 78% /boot/grub2/i386-pc
/dev/sda2 269M 55M 215M 21% /boot/efi
/dev/sda9 43G 33G 9.4G 78% /var/tmp
/dev/sda9 43G 33G 9.4G 78% /var/opt
/dev/sda9 43G 33G 9.4G 78% /var/spool
/dev/sda9 43G 33G 9.4G 78% /var/lib/pgsql
/dev/sda9 43G 33G 9.4G 78% /var/lib/mysql
/dev/sda9 43G 33G 9.4G 78% /var/lib/mailman
/dev/sda9 43G 33G 9.4G 78% /var/lib/mariadb
/dev/sda9 43G 33G 9.4G 78% /var/lib/named
/dev/sda9 43G 33G 9.4G 78% /var/crash
/dev/sda9 43G 33G 9.4G 78% /var/log
/dev/sda9 43G 33G 9.4G 78% /var/lib/libvirt/images
/dev/sda10 343G 88G 255G 26% /home


If I need to switch over to XFCE, then so be it, but I’ve used Leap previously without issue. I think this freezing problem is caused by something else

sounds like a graphic acceleration issue to me, do you have an extra graphic card or are you using intel’s build in one, if you have an extra nvidia card you need bumblebee
https://en.opensuse.org/SDB:NVIDIA_Bumblebee

it could be a bad hdd sector or a bad ram chip, it could even be dust on the cooler, your issue is too vague.

Not likely a GPU driver issue,
I don’t know that an i7 has ever been in an optimus.

And, it looks like you have ample resources.

Recommend you open and run top in a console continuously on your machine so you can monitor what is happening in real time.
When your screen freezes, see what half dozen or so processes are running at the top. You can even try different versions of top (like htop), although you can customize what is displayed, it’s convenient to just try a different app.

At the moment I’m suspecting something like a cron job, perhaps indexing your hard drive in the middle of the day.
It might also be a clue if this only happens for a few hours at the same time each day or all day.

TSU

all ix cpu’s have a build in gpu, being a high end cpu it’s highly probable he has an external gpu, if not am optimus rig then in bios he should check and see what gpu is set as active, select the external and install propitiatory drivers

Intel is the exception,
The latest and current Intel architecture (i7) which first started appearing about 3 years ago (I think today is something like 4th generation i7) usually has one of the two highest end Intel HD GPUs, nothing lower has ever been included AFAIK.

So, I don’t think you’ll ever see an alternate GPU built into an i7 system because it’s already got the best Intel can offer at the time.

TSU

Massive indexing?

Boot and run for some time in text-only mode. See whether freezes are there.

I have seen these freezes too. They can last for up to a minute or so in my experience.
They don’t happen all the time, I can go a month without seeing one, then there will be another quite randomly.
The strange thing is that when it happens there is very little activity on the CPUs or memory (that is able to be recorded), but intensive activity on the hard drive.
This could imply swap activity, but I won’t be running any heavy duty apps at the time.

it could be snapper taking snapshots I never used btrfs, take a look at the log files
http://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.trouble.html#tab.trouble.info
I think btrfs should allow transparent backups but maybe it is resource intensive, there is a snapper module in yast for managing system snapshots take a look at it.
I had similar issues on plasma 5 with the nouveau driver the propitiatory nvidia driver fixed things, also intel’s graphics is buggy on plasma 5, according to the kde devs intel graphic users should use uxa acceleration the other methods can cause hangups (that’s why I asked about the graphic card)
see this kde thread for more info and a fix for intel video under plasma 5
https://mail.kde.org/pipermail/kde-distro-packagers/2015-August/000088.html

yes it is 1+ year old but it hasn’t been fixed yet

Intense HD activity may indicate one or more bad/weak sectors. The OS will attempt to read until all the checksums are right. Run smartctl to check for bad sectors

Yup, did that about a month ago when a freeze was particularly noticeable. The extended check came up clean as a whistle. Not much time in this drive at all. Great suggestion though.

Could be snapper I guess but the way it work’s I’d not expect large hits on the drive It simply preserves and organizes modified blocks. Unless it is maybe rebalancing the B-trees.

Since what ever it is not showing in top it has to be a kernel process. Maybe try booting from previous kernel at boot???

those checks aren’t really reliable
I’ve had 2 hard disks die on me without an error being thrown by those file system scanning utilities, yet both times the reallocated count in my disks SMART was bigger then 1 (once ~40 the other time over 500)
I’d say check your hard drive’s SMART status try smartmontools
https://software.opensuse.org/package/smartmontools
use smartmontools and check if the realocated couinter is bigger then zero, although most disks can and do provide extra sectors, once a disk starts dyeing there’s no going back
or go to your hard drive’s manufacturer site, most disk makers have diagnosis and repair tools (the repair never works)

That’s the tool I used, smartctl’s extended or long test. Took about 4 hours so must be pretty thorough.

you don’t really need a test, if the hard disk has bad sectors the reallocated sectors count in the disks SMART chip will be above 0, you just need to read the value stored on the disk itself
smartctl --info /dev/sda (or the path to your drive)
when running tests a thing to consider is that you should not boot from the disk you are testing, if you don’t have another hdd with an OS on it you can boot from a DVD/USB,
you file system might have issues like a large fragmented index file, I know it’s a chore but if you had an improper shutdown and the file system was damaged you might need a reformat.
ps what file system are you using btrfs/xfs/ext4?

Actually, it is quite common for very good disks to drop sectors now & then, not a sign of a bad disk until it gets beyond the manufacturer’s threshold or until it is dropping many sectors in a short period of time.

Also, the count in the SMART depends on whether or not you actually have the SMART system enabled in the drive.

In other words, a few dropped sectors means little, and a SMART count of 0 does not necessarily mean the drive is good.

There is also – something I have noticed has become quite common with WD drives in the past decade – the problem of some drives developing an intermittent electrical problem as they age. This causes the drive to mysteriously disappear, then reappear, for no apparent reason, while the platter surfaces remain in a perfectly healthy state.

I have a pile of WD drives where the only problem is the electronics. When they are detected, all contents can be accessed reliably and the drives pass all tests.

When they are not detected, when they disappear, they cannot even be tested … until they reappear. And then they will pass, again.

It is why I have switched back to Seagate. I have had Seagate disks fail in the normal, expected manner, but not yet had one come up with that aggravating and difficult to detect electrical problem.

The WD pile of drives is a large stack of perfectly good platters that are useless because of something on the circuit board.

I’ve been poking around the different options you all presented and determined that the real issue came down to available hard drive space - I unfortunately didn’t remove the old windows partition when installing OS. Basically the hard drive ran out of space even though there was no windows partition available to boot into. I fixed the mistake with a brute force method of reinstalling OS and paying more attention to how the partitions were being set up.

I’m now running a perfectly smooth version of OS. Thanks for the help everyone!