| View previous topic :: View next topic |
| Author |
Message |
mjbjr
Guru
Joined: 02 Mar 2003
Posts: 301
|
 Posted: Sun Mar 01, 2020 7:13 am Post subject: xfwm4 locks up |
 |
|
A couple of days ago I did a new gentoo build installing xfce4. Everything was looking good on the desktop,
but a few minutes into it I noticed that the desktop appeared to be locked up.
The cpu graphs in gkrellm weren't moving, though when I moved the mouse over it the graphs would
sometimes update.
The mouse moved about normally, though when I moved it to the next workspace, say moving it all the way
to the right and off the screen it would immediately appear coming back onto that same desktop from the left.
Clicking on any buttons didn't make anything happen.
The keyboard continued to work, I could key-combo to a full screen console.
Looking at 'top', it showed that xfwm4 was using 30% cpu.
I rebooted a number of times and for a few minutes everything would be normal, then it would lock up again.
I ran another gentoo install I had on the computer and it worked fine, so it would appear that it's not hardware.
| Code: |
localhost ~ # xfwm4_00 --version
This is xfwm4 version 4.14.0 (revision ed87ef663) for Xfce 4.14
Released under the terms of the GNU General Public License.
Compiled against GTK+-3.24.13, using GTK+-3.24.13.
Build configuration and supported features:
- Startup notification support: No
- XSync support: Yes
- Render support: Yes
- Xrandr support: Yes
- Xpresent support: Yes
- Embedded compositor: Yes
- Epoxy support: No
- KDE systray proxy (deprecated): No
|
I was able to change the window manager from xfwm4 to openbox, but openbox
is relatively limited, unfortunately. There have been no lockups since I made the
change and it's been nearly five hrs since the last boot.
Any ideas?
. |
|
| Back to top |
|
 |
turtles
Veteran
Joined: 31 Dec 2004
Posts: 1664
|
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2727
|
| Posted: Mon Mar 02, 2020 4:27 pm Post subject: |
|
|
Compositor itself is "maybe" fine, but the vsync implementations used with it can be doubtful depending on the card/drivers. Some bad timing on vsync could result in potential random lockups.
Personally I disable xpresent/opengl(epoxy) on xfwm4 (see USE flags) and let nvidia drivers prevent tearing instead with ForceFullCompositionPipeline (I always leave the compositor enabled and typically disable vsync on everything I use tear-free). Although if using xpresent, you're likely not on nvidia  No idea what's best for you, or why there's a problem in the first place. If you aren't getting tearing with neither of those then they're likely just redundant and causing problems, if getting tearing could try epoxy instead and see if it helps. |
|
| Back to top |
|
|
mjbjr
Guru
Joined: 02 Mar 2003
Posts: 301
|
| Posted: Mon Mar 02, 2020 6:54 pm Post subject: |
|
|
| Ionen wrote: | Compositor itself is "maybe" fine, but the vsync implementations used with it can be doubtful depending on the card/drivers. Some bad timing on vsync could result in potential random lockups.
Personally I disable xpresent/opengl(epoxy) on xfwm4 (see USE flags) and let nvidia drivers prevent tearing instead with ForceFullCompositionPipeline (I always leave the compositor enabled and typically disable vsync on everything I use tear-free). Although if using xpresent, you're likely not on nvidia No idea what's best for you, or why there's a problem in the first place. If you aren't getting tearing with neither of those then they're likely just redundant and causing problems, if getting tearing could try epoxy instead and see if it helps. |
Thank you for responding...
By 'tearing', do you mean a visual problem with the desktop imoge being rendered on the screen? The desktop and app windows were working perfectly fine for a minute or so and then it would just grind to a "halt", though technically it was still running, as I mentioned.
I'm not currently on nvidia, but am using nouveau. Possibly, nouveau is the problem, I don't know. Would you _know_ if nouveau is likely the problem in this instance?
I did try using openbox for an hour or so, but it lacks a lot of the configurations I like and was generally just kind of sucky. Don't ask, I don't remember. lol
So, I ended up going to the way back machine and using sawfish (latest is from 2017), which is deeply configurable using lisp, which I really don't know, though with the exception of one config I want it's working fine out of the box. Gonna have to dig deeper to get that last config, though I probably have my configs from way back archived somewhere.
Thanks for the help..
- Martin - |
|
| Back to top |
|
|
mjbjr
Guru
Joined: 02 Mar 2003
Posts: 301
|
| Posted: Mon Mar 02, 2020 7:07 pm Post subject: |
|
|
Thank you for responding...
Is there some reason compositing would have changed from previous versions that worked fine?
I was thinking that I might just downgrade to a previous version of xfwm4 and see if that might be ok.
- Martin - |
|
| Back to top |
|
|
turtles
Veteran
Joined: 31 Dec 2004
Posts: 1664
|
| Posted: Mon Mar 02, 2020 7:31 pm Post subject: |
|
|
It was just a troubleshooting suggestion.
If we turn compositng off and the problem goes away that tells us where to dig deeper.
You have been using gentoo longer than me so i assume you checked the the usual error logs like
| Code: | grep 'error' .xsession-errors
grep 'EE' /var/log/Xorg.0.log
dmesg | grep 'error' |
Cheers
_________________
Donate to Gentoo |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2727
|
| Posted: Mon Mar 02, 2020 7:32 pm Post subject: |
|
|
| mjbjr wrote: | | By 'tearing', do you mean a visual problem with the desktop image being rendered on the screen? The desktop and app windows were working perfectly fine for a minute or so and then it would just grind to a "halt", though technically it was still running, as I mentioned. |
Yes, mostly noticeable when moving windows around, but "xpresent" is in use and such you wouldn't experience any tearing. However, I'm putting my "guess" on this being related to your problems (combined with nouveau). You could build without xpresent to check but then you may start experiencing said tearing (maybe opengl/epoxy would work better and then you could keep using nouveau if you wish).
This is only active while the compositor is enabled.
xpresent is also relatively new, xfwm4 used to use opengl only before, or not do vsync at all.
| Quote: | | I'm not currently on nvidia, but am using nouveau. Possibly, nouveau is the problem, I don't know. Would you _know_ if nouveau is likely the problem in this instance? |
I don't know, but I personally don't trust nouveau much. The developers do what they can but they have limited means to do so and several features are either lacking or not working as expected. nouveau is still handy if you have a rather old card though (can be a pain to deal with nvidia's legacy/long-term-support drivers).
If decide to drop nouveau and keep using xfwm4, I'd personally suggest to go with a setup similar to mine if you can: proprietary nvidia drivers, xfwm4 built with USE="-opengl -xpresent", compositor left enabled, and enable "ForceFullCompositionPipeline". Can be done the simple way through nvidia-settings executable (X Server Display Information -> Advanced) but personally I have it in my xorg.conf like: | Code: | Section "Device"
Identifier "GeForce GTX 1070"
Driver "nvidia"
Option "ForceFullCompositionPipeline" "true"
EndSection |
Also with nvidia-drivers, in case modified it, delete your .config/xfce4/xfconf/xfce-perchannel-xml/displays.xml to reset to default settings since it can cause issues/conflict and give a black screen. |
|
| Back to top |
|
|
mjbjr
Guru
Joined: 02 Mar 2003
Posts: 301
|
| Posted: Mon Mar 02, 2020 8:42 pm Post subject: |
|
|
| turtles wrote: | It was just a troubleshooting suggestion.
If we turn compositng off and the problem goes away that tells us where to dig deeper.
You have been using gentoo longer than me so i assume you checked the the usual error logs like
| Code: | grep 'error' .xsession-errors
grep 'EE' /var/log/Xorg.0.log
dmesg | grep 'error' |
Cheers |
Well, for this latest install, following the AMD64 Handbook, I didn't set all the FB stuff, which iirc is the now suggested way in the Handbook. Which is fine by me as figuring out the correct fb to use was a pita. All I ever want the fb for is to get a lot of lines in the boot and console (I boot to runlevel 3) screens so I can see a lot of info. And that has worked out well as far as that goes. And for this build and the previos one I haven't had an xorg.conf, just let it do its thing and it's been fine.
so this is the way it is currently...
I have VIDEO_CARDS="nouveau" in make.conf.
[code]
localhost ~ # ls -l /var/log/Xorg.0.log
-rw-r--r-- 1 root mjbjr 56494 Mar 2 12:01 /var/log/Xorg.0.log
localhost ~ # grep 'EE' /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 46.235] (EE) Failed to load module "nv" (module does not exist, 0)
[ 46.237] (EE) Failed to load module "fbdev" (module does not exist, 0)
[ 46.237] (EE) Failed to load module "vesa" (module does not exist, 0)
[ 46.420] (II) Initializing extension MIT-SCREEN-SAVER
localhost ~ # ls -l /etc/X11/xorg.conf
ls: cannot access '/etc/X11/xorg.conf': No such file or directory
localhost ~ # grep -i fbdev /usr/src/linux/.config
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
localhost ~ # grep -i vesa /usr/src/linux/.config
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
localhost ~ # grep -i nv /usr/src/linux/.config
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_TCP_CONG_NV is not set
# CONFIG_OPENVSWITCH is not set
# NVME Support
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_NVME_FC is not set
# CONFIG_SATA_NV is not set
CONFIG_NET_VENDOR_NVIDIA=y
# CONFIG_NVM is not set
CONFIG_NVRAM=y
# CONFIG_NV_TCO is not set
# CONFIG_FB_NVIDIA is not set
CONFIG_RTC_NVMEM=y
# CONFIG_LIBNVDIMM is not set
CONFIG_NVMEM=y
[\code]
I've got to head out the door and get some things done, but I will be looking at your suggestions, and those from others, later this evening.
Thanks
- Martin -
. |
|
| Back to top |
|
|
turtles
Veteran
Joined: 31 Dec 2004
Posts: 1664
|
| Posted: Mon Mar 02, 2020 10:03 pm Post subject: |
|
|
Did you try turing composting off?
| Code: | | xfconf-query -c xfwm4 -p /general/use_compositing -s false |
Whats happens when you do that?
_________________
Donate to Gentoo |
|
| Back to top |
|
|
mjbjr
Guru
Joined: 02 Mar 2003
Posts: 301
|
| Posted: Tue Mar 03, 2020 3:06 am Post subject: |
|
|
| turtles wrote: | Did you try turing composting off?
| Code: | | xfconf-query -c xfwm4 -p /general/use_compositing -s false |
Whats happens when you do that? |
when running that command from console before startxfce4
| Code: |
Failed to init libxfconf: Caannot autolaunch D-Bus without X11
|
when running the command from an xterm after startxfce4
| Code: |
localhost ~ # xfconf-query -c xfwm4 -p /general/use_compositing -s false
Failed to init libxfconf: Error spawning command line “dbus-launch --autolaunch=6e70dfa37f341e4e2744fd465e56f4d1 --binary-syntax --close-stderr”: Child process exited with code 1.
|
|
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1407
Location: Germany
|
|
| Back to top |
|
|
mjbjr
Guru
Joined: 02 Mar 2003
Posts: 301
|
| Posted: Wed Mar 04, 2020 2:12 am Post subject: |
|
|
| Banana wrote: | | @mjbjr How do you login into your xfce4 session? startx oder login manager? |
'startxfce4' from console.
'startx' will start whatever is in your .xinitrc file. |
|
| Back to top |
|
|
|
Desktop Environments
