Hi! I have had this problem before and I had to completely reinstall the system.
This time I haven’t installed any software or changed any settings. After a reboot my X.org keeps freezing up and behaving weirdly. The mouse pointer moves when I move the mouse, when I click a shortcut to run Firefox for example, I don’t see the program’s window popping up until I “manually refresh the screen” by opening another terminal with Ctrl+Alt+F1 and switching back to the X server with Ctrl+Alt+F7.
I’ve tried booting up from the different snapshots and restarting the X server with Ctrl+Alt+Backspace and it didn’t help.
Do you really know that you installed a DE that uses the Xorg X server or could you be installed using Wayland?
TSU
I’ve checked it before. I positively have Xorg X server
Is this the same HP laptop with “00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo [1002:9874] (rev c8)” that you’ve gotten help here for before? Which DE are you using? Gnome? Plasma? Other? Are you still using the Amdgpu-pro driver?
**inxi**](https://smxi.org/docs/inxi-installation.htm#inxi-manual-install) -GxxSza
Yes, it’s the same laptop. I use KDE Plasma. I’ve reinstalled my system and I didn’t bother to install Amdgpu-pro driver this time.
aleksandr@aleksandr-pc:~> inxi -GxxSzA > output.txt
e[1;34mSystem: e[0;37m e[1;34mHost:e[0;37m aleksandr-pc e[1;34mKernel:e[0;37m 4.12.14-lp151.28.40-default x86_64 e[1;34mbits:e[0;37m 64 e[1;34mgcc:e[0;37m 7.5.0e[0;37m
e[1;34m e[0;37m e[1;34mConsole:e[0;37m tty 1 e[1;34mdm:e[0;37m sddm,sddm e[1;34mDistro:e[0;37m openSUSE Leap 15.1e[0;37m
e[1;34mGraphics: e[0;37m e[1;34mCard:e[0;37m Advanced Micro Devices [AMD/ATI] Wani [Radeon R5/R6/R7 Graphics]e[0;37m
e[1;34m e[0;37m e[1;34mbus-ID:e[0;37m 00:01.0 e[1;34mchip-ID:e[0;37m 1002:9874e[0;37m
e[1;34m e[0;37m e[1;34mDisplay Server:e[0;37m X.org 1.20.3 e[1;34mdrivers:e[0;37m ati,amdgpu (unloaded: modesetting,fbdev,vesa)e[0;37m
e[1;34m e[0;37m e[1;34mtty size:e[0;37m 170x48 e[1;34mAdvanced Data:e[0;37m N/A out of Xe[0;37m
e[1;34mAudio: e[0;37m e[1;34mCard-1e[0;37m Advanced Micro Devices [AMD/ATI] Kabini HDMI/DP Audioe[0;37m
e[1;34m e[0;37m e[1;34mdriver:e[0;37m snd_hda_intel e[1;34mbus-ID:e[0;37m 00:01.1 e[1;34mchip-ID:e[0;37m 1002:9840e[0;37m
e[1;34m e[0;37m e[1;34mCard-2e[0;37m Advanced Micro Devices [AMD] Family 15h (Models 60h-6fh) Audio Controllere0;37m
e1;34m e0;37m e1;34mdriver:e0;37m snd_hda_intel e1;34mbus-ID:e0;37m 00:09.2 e1;34mchip-ID:e0;37m 1022:157ae0;37m
e1;34m e0;37m e1;34mSound:e0;37m Advanced Linux Sound Architecture e1;34mv:e0;37m k4.12.14-lp151.28.40-defaulte0;37m
e0m
GxxSza is what I asked for (a for admin, doesn’t exist in antique versions), not the same as GxxSzA (A for audio). As you can see, some data (that I was after) is missing because I forgot to have you run it from within X. Here is what it looks like from here (with a few years’ older AMD GPU):
# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
2560x1440 59.95*+ 74.92
# inxi -V | head -n1
inxi 3.0.38-00 (2020-03-14)
# inxi -GxxSza
System: Kernel: 4.12.14-lp151.28.40-default x86_64 bits: 64 compiler: gcc v: 7.5.0
parameters: root=<redacted> radeon.si_support=0 amdgpu.si_support=1 noresume mitigations=auto consoleblank=0
Desktop: Trinity R14.0.7 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM Distro: openSUSE Leap 15.1
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] vendor: Dell driver: amdgpu
v: kernel bus ID: 01:00.0 chip ID: 1002:6611
Display: server: **X.Org 1.20.3 driver: amdgpu** unloaded: fbdev,modesetting,vesa alternate: ati
resolution: 2560x1440~60Hz
OpenGL: renderer: AMD Radeon HD 8500 Series (OLAND DRM 3.27.0 4.12.14-lp151.28.40-default LLVM 7.0.1)
v: 4.5 Mesa 18.3.2 direct render: Yes
What yours suggests is use of an antique and functionally limited inxi version that makes it unclear which DDX is actually employed. Inxi provides a -U switch to update itself. The current version is approximately 24 hours old.
Thus you might not be running on the optimal driver your Carrizo GPU, provided by the FOSS rpm xf86-video-amdgpu. Is it installed? If yes, you may need a cmdline option in Grub to enable it. Which option that would be I do not remember how to determine.
It could be there is something in /etc/X11/xorg.conf or /etc/X11/xorg.conf.d/50-device.conf or elsewhere in that directory overriding its use. If it is not installed, installing it might be all that’s necessary to stop the freezes.
If you log into an IceWM session instead of Plasma, does all trouble disappear? How about if you log into Plasma in a newly created (virgin) user account? If no problem in either of these, it might be useful while logged out of your normal user account to delete its ~/.cache/ content and then login to your normal account (will be slow this time, since cache will be regenerated).
I’ve tried logging in to IceWM and it was still freezing all the time. Then I’ve created a new user from Plasma DE, I had to “refresh” the screen all the time to do that. I logged in to the new user and it works fine! I’ve deleted the ~/.chache folder of my main account, but nothing changed, it still freezes all the time when I use my main account. Can you figure the reason now?
I’ve logged in to the main constantly freezing user, updated inxi and run again. I got:
System: Kernel: 4.12.14-lp151.28.40-default x86_64 bits: 64 compiler: gcc v: 7.5.0
parameters: BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp151.28.40-default root=UUID=3505699e-5e0e-44ac-b294-a4954ca507ef
splash=silent resume=/dev/disk/by-uuid/54e30d74-6725-43b1-a261-cebf9f58a9d2 mitigations=auto quiet
Console: N/A dm: SDDM Distro: openSUSE Leap 15.1
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Wani [Radeon R5/R6/R7 Graphics] vendor: Hewlett-Packard driver: amdgpu
v: kernel bus ID: 00:01.0 chip ID: 1002:9874
Display: server: X.org 1.20.3 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa compositor: kwin_x11 tty: 168x39
Message: Unable to show advanced data. Required tool glxinfo missing.
Yes, it is installed, I’ve checked in zypper.
How does one can determine if these files interfere with xf86-video-amdgpu?
When true this means come sort of corruption in the user account.
One of the easier things to try is to log out, then log in as root, and reset the main user directory’s ownerships. They shouldn’t be the problem, but an errant mis-use of su or sudo is capable of causing such damage with no immediately apparent evidence. Assuming that for your main account userid is 1000 and groupid is 100:
chown -R 1000.100 /home/userid
Your actual username.groupname can be used too. The usernames and numbers are contained in /etc/passwd. They should match output from:
ls -n ~/
If the owner.group reset fails to repair the problem, deleting KDE/Plasma settings files is next to try. Very unfortunately, KDE5 has chosen to mix its settings among settings for non-KDE apps, so it’s necessary to guess which to try deleting. These are files and directories in ~/.config/. Most start with a “k” or a “pl”, so you can start by logging out of Plasma and deleting those. I think there is no actual user data among them, so all that gets lost by their deletion is settings, which can be restored the hard way - individually, after the problem has been solved. For each session of .config/ deletions I would again delete all content of .cache/ that is obviously applicable to KDE/Plasma.
How does one can determine if these files interfere with xf86-video-amdgpu?
Those that pertain only to keyboard or mouse, those that contain only comments, and those that don’t exist, certainly don’t. The rest must be examined for applicability to video operations.
It worked! When I deleted ~/.config/kwinrc the DE became functional again, thanks!
The messed up file’s contents are:
[Compositing]
OpenGLIsUnsafe=true
[Plugins]
blurEnabled=false
contrastEnabled=false
kwin4_effect_frozenappEnabled=false
After I’d deleted the file the system created the new version of it:
[Compositing]
OpenGLIsUnsafe=false
I’m just curious what it means and how I could have let the file to be changed. Do you have a hypothesis?
Not really. KDE config files speak a unique language I don’t comprehend. Here’s my only 15.1 kwinrc:
[Compositing]
AnimationSpeed=3
Backend=OpenGL
Enabled=false
GLColorCorrection=false
GLCore=false
GLPlatformInterface=glx
GLPreferBufferSwap=a
GLTextureFilter=2
HiddenPreviews=5
WindowsBlockCompositing=true
XRenderSmoothScale=false
[Desktops]
Number=3
Rows=1
[Effect-Cube]
BorderActivate=9
BorderActivateCylinder=9
BorderActivateSphere=9
[Effect-DesktopGrid]
BorderActivate=9
[Effect-PresentWindows]
BorderActivate=9
BorderActivateAll=7
BorderActivateClass=9
[ElectricBorders]
Bottom=None
BottomLeft=None
BottomRight=None
Left=None
Right=None
Top=None
TopLeft=None
TopRight=None
[Plugins]
cubeslideEnabled=false
desktopchangeosdEnabled=false
kwin4_effect_fadedesktopEnabled=false
slideEnabled=true
[Script-desktopchangeosd]
PopupHideDelay=1000
TextOnly=false
[TabBox]
BorderActivate=9
BorderAlternativeActivate=9
[Windows]
ElectricBorderCooldown=350
ElectricBorderCornerRatio=0.25
ElectricBorderDelay=150
ElectricBorderMaximize=false
ElectricBorderTiling=false
ElectricBorders=0
RollOverDesktops=true
[org.kde.kdecoration2]
BorderSize=Normal
ButtonsOnLeft=MS
ButtonsOnRight=HIAX
CloseOnDoubleClickOnMenu=false
library=org.kde.kwin.aurorae
theme=kwin4_decoration_qml_plastik
Massive difference from either of yours.
I don’t understand why the problem still pops up.
On average every two weeks my kwinrc is altered for some reason to:
[Compositing]
OpenGLIsUnsafe=true
I have to delete it every time it changes, because it causes the Xorg to glitch.
Why is it happening?
I don’t know. But I have a few ideas.
There’s two possible conclusions, and different options for each:
- OpenGL is not deemed safe, at least for a specific operation. Arguably, when trying to avoid this specific operation it fails miserably;
- There’s a bug in OpenGL detection.
For 1), you could try a different OpenGL version or XRender as rendering backend in Compositor Settings, or disabling every effect you can find. For 2) you can try a few things. 2.1) keep it set to =false, maybe it doesn’t override. 2.2) remove writable permission in the file or 2.3) sudo chattr +i ~/.config/kwinrc (which is almost the same as 2.2 only requires root to undo)
Thank you. Next time kwinrc is overriden, I will follow your advice.
I will let you all know how it goes in a couple of months.
I’ve tried switching to XRender already, it causes the freezes identical to those which I described in the beginning of this thread.
Okay, I looked into the sources to find any clues.
It always sets OpenGLIsUnsafe=true during the PreInit phase. It only sets to =false when it reaches the PostInit phase, so my option 2.1 above is of no use. Link
If it doesn’t reach that phase, is because OpenGL failed in an unexpected way. LinkOr maybe it reached and set to =false, but then a freeze was detected. Link
I suggest you try:
sudo journalctl --grep OpenGL
You may read about a freeze, or usage of non-recommended backend.