Solved Hard System Lock-Ups

rhsbsd

Member

Reaction score: 12
Messages: 73

Recently my computer is experiencing lock-ups, which, require hitting the power button. This has never happened to me in over 8 years of FreeBSD desktop usage. My computer has always lived on the edge of the ports tree, kernel is box stock, and user-land is built entirely by pouderiere. I have stopped using SVN source builds for kernel updates for quite a while now because freebsd-update fetch/install has been doing the job quite nicely. This info may (I don't believe it myself) be relevant because I jumped on FreeBSD 12.1 about a month after it was out. Everything was fine until about patch level 5 (12.1-RELEASE-p5). This is probably just coincidental because when I see a new patch level I upgrade my ports to lattest and/or once per month. That is my best recollection of a time frame reference that comes to mind.
The problem I believe seems to be centered around Plasma5 window/taskbar animations. In particular the 'fallapart' effect in conjunction with 'cursor bounce' busy/working effect. I use a task bar in each of my 4 activities that has an embedded folder view which drops down to all the applications/places/directories I constantly use. Funny thing about starting applications from a folder view short cut none of the animations take place. PLEASE DO NOT FIX THAT! This has worked this way since FreeBSD 11. If an application is started in this way I never have a problem. If an application is started from a launcher (I have 2) LOCK-UP. Used to be rare but recently its becoming evident that something is breaking.
You know I cant even remember if SVN source upgrades touch /usr/local/etc.
The thing that might help is if I knew how to log a hard crash at Plasma failure time. That might help???
PS: At the moment I do not ever start certain applications from launcher with these animations enabled.
 

Mjölnir

Daemon

Reaction score: 1,509
Messages: 2,114

I can not provide any proven solution, but I agree that the lastest Q3/2020 package update caused much more problems than any other I remember. For my part, I'll switch back to my previous habit of avoiding *.1 & *.2 releases. Don't know if that's going to help when the issue is pulled in by a quarterly package update, but chances are such combination is more stable overall.
You could try to set another AccelMethod for you graphics driver in e.g. /usr/local/etc/X11/xorg.conf.d/intel.conf. E.g. glamor is kind of stable, it needs to be loaded
Code:
Section Module
    load glamoregl
EndSection
 
OP
rhsbsd

rhsbsd

Member

Reaction score: 12
Messages: 73

You could try to set another AccelMethod for you graphics driver in e.g. /usr/local/etc/X11/xorg.conf.d/intel.conf. E.g. glamor is kind of stable, it needs to be loaded.
Did not know that! That is definitly something to checkout. At the moment I just went to p7 and upgraded all my ports. Then proceeded to launch the worst offenders and, no problems. I will post back in a week or so and at that time I should definitely know. It seems as if smaller apps that launch quickly bring this on.
 
OP
rhsbsd

rhsbsd

Member

Reaction score: 12
Messages: 73

Not one lockup since upgrading to p7 and rebuilding ports. Wish I knew WHY? I do suspect that this machines GPU (Intel HD3000, Sandy bridge, 1st release Huron river hardware) did have something to do with this. I have had several rocky periods over the years with composting and acceleration, which, are all documented on this site. Since its been over two weeks I am marking this solved for now.
 

judd

Active Member

Reaction score: 206
Messages: 237

% freebsd-version -ku
12.1-RELEASE-p8
12.1-RELEASE-p8
 
Top