Xorg/screen/Nvidia freezing

山猿 · 2024-02-04 23:54:59

Hi there,

I am having some trouble with my computer freezing periodically. I am able to get back to the dm using ctrl + alt + delete which then shows an error message but does not allow me to use the tty; in that, I can type but tty2 does not respond (switching to tty3 allows me to reboot, switching to tty1 does not permit me to type). I am not quite sure how to access this error message to reproduce here, but the final line states the following;

GPU invalid after WaitForGetOffsetInRange

I tried to run

# journalctl | grep WaitForGetOffsetInRange

but this did not return any results. I am also not exactly sure what is causing the issue but I do know that this has not been an issue until the last few weeks or so, during which, the computer will (seemingly) randomly freeze, forcing me to return to the tty.

If it helps, I run the 64 bit version of arch, using the 6.7.3-arch1-1 kernel. My wm is bspwm, and I also use picom. I do have an Nvidia graphics card (3060) as well, if that is at all relevant.

Help would be very much appreciated. Thank you.

Last edited by 山猿 (2024-02-04 23:58:12)

seth · 2024-02-05 09:51:12

If you can access a console (tty3?) after a freeze, please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

On a limb: did you enable nvidia_drm.fbdev=1 ? DON'T!

山猿 · 2024-02-05 19:27:35

seth wrote:

If you can access a console (tty3?) after a freeze, please post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st
On a limb: did you enable nvidia_drm.fbdev=1 ? DON'T!

Hello, thank you for your help with this and apologies for the delay; I was waiting for the computer to freeze again.

A few extra pieces of information from this freeze which may be useful;

My polybar module for the keyboard still displays when I turn on or off the caps lock or num lock, despite the screen being frozen (script for this is included below)
My mouse disappears
A video that was playing continued to play
Sound from the aforementioned video was audible
I could press F3 on Firefox (the focused window) and the Quick Search bar would appear

The ibus script to hook into polybar;

#!/bin/sh
IBUS_RAW=`ibus engine`
# read currently used engine(xkb, m17n, rime, etc...)
IBUS_ENGINE=`echo $IBUS_RAW | awk -F ':' '{print $1}'`
# read currently used layout(ca, jp, fr, etc...)
IBUS_LAYOUT=`echo $IBUS_RAW | awk -F ':' '{print $2}'`
# read currently used layout variant(de, dvorak, etc...)
IBUS_LAYOUT_VARIANT=`echo $IBUS_RAW | awk -F ':' '{print $3}'`
# read currently used language(eng, ger, unicode, etc...)
IBUS_LANG=`echo $IBUS_RAW | awk -F ':' '{print $4}'`

COLOURICON_EXP=`cat .cache/wal/colors | sed -n '3 p'`
COLOURTEXT_EXP=`cat .cache/wal/colors | sed -n '8 p'`

ENGINE_ICON=%{F$COLOURICON_EXP}%{F-}
LAYOUT_ICON=%{F$COLOURICON_EXP}%{F-}
LANG_ICON=%{F$COLOURICON_EXP}%{F-}
LOCK_ICON=%{F$COLOURICON_EXP}%{F-}

if [ -z "${IBUS_LAYOUT}" ] || [ "${IBUS_LAYOUT}" = "\n" ]
then
    IBUS_LAYOUT=sys
fi

OUTPUT="${ENGINE_ICON} %{F$COLOURTEXT_EXP}${IBUS_ENGINE}%{F-}"
if [ -n "${IBUS_LAYOUT_VARIANT}" ] && [ "${IBUS_LAYOUT_VARIANT}" != "\n" ]
then
    OUTPUT="${OUTPUT} ${LAYOUT_ICON} %{F$COLOURTEXT_EXP}${IBUS_LAYOUT} - ${IBUS_LAYOUT_VARIANT}%{F-}"
else
    OUTPUT="${OUTPUT} ${LAYOUT_ICON} %{F$COLOURTEXT_EXP}${IBUS_LAYOUT}%{F-}"
fi

if [ -n "${IBUS_LANG}" ] && [ "${IBUS_LANG}" != "\n" ]
then
    OUTPUT="${OUTPUT} ${LANG_ICON} %{F$COLOURTEXT_EXP}${IBUS_LANG}%{F-}"
fi

# toggle caps and num lock
CAPSLOCK=`xset -q | grep "Caps Lock: *on"`
NUMLOCK=`xset -q | grep "Num Lock: *on"`
OUTPUT_LOCK=""
if [ -n "${CAPSLOCK}" ]
then
    OUTPUT_LOCK="${LOCK_ICON} %{F$COLOURTEXT_EXP}caps%{F-}"
fi
if [ -n "${NUMLOCK}" ]
then
    if [ -n "${OUTPUT_LOCK}" ]
    then
        OUTPUT_LOCK="${OUTPUT_LOCK}%{F$COLOURTEXT_EXP}, num%{F-}"
    else
        OUTPUT_LOCK="${LOCK_ICON}%{F$COLOURTEXT_EXP} num%{F-}"
    fi
fi

echo ${OUTPUT} ${OUTPUT_LOCK}
exit 0

As for the tty;

I did try to log in to tty1 again (everything I use is on tty2) but as soon as I do, it displays an error message and immediately goes to a black screen
When switching to tty3, I believe it said something akin to 'could not unset xset' at the top

For 0x0.st, please see the following log here.

I have not enabled nvidia_drm.fbdev=1, unless unwittingly, if that is possible.

Thank you again for this.

Last edited by 山猿 (2024-02-05 19:29:45)

seth · 2024-02-05 21:18:58

polybar module … still displays when … the screen being frozen … A video that was playing continued to play … F3 on Firefox (the focused window) and the Quick Search bar would appear

Ie. the screen isn't frozen at all.
With

My mouse disappears

I suspect something grabs at least the pointer, maybe focus.

immediately goes to a black screen

As long as you can get to *some* console, you're good.

Install xdotool and the next time this happens, switch to another TTY (3), login

export DISPLAY=:0 # that's a guess, make it the display of your X11 session)
xdotool key "XF86LogGrabInfo"

this will print all grabs into your xorg log, then post that (you can cat it into 0x0.st)
It's location depends on how the server is started: https://wiki.archlinux.org/title/Xorg#General

Edit: I btw. suspect the cause to be ibus…
Edit #2: there's a massive amount of

Feb 05 18:13:55 sys systemd[1]: displaylink.service: Failed with result 'exit-code'.
Feb 05 18:13:55 sys systemd[1]: Failed to start DisplayLink Manager Service.
Feb 05 18:14:01 sys systemd[1]: displaylink.service: Scheduled restart job, restart counter is at 1408.
Feb 05 18:14:01 sys systemd[1]: Starting DisplayLink Manager Service...
Feb 05 18:14:01 sys modprobe[3824444]: modprobe: FATAL: Module evdi not found in directory /lib/modules/6.7.3-arch1-1
Feb 05 18:14:01 sys systemd[1]: displaylink.service: Control process exited, code=exited, status=1/FAILURE

in the journal, you either forgot to rebuild the module or the dkms rebuild failed because of GPL restrictions in 6.7.3
If you can't build the module, you should better disable the service for the time being.

---
This is probably unrelated since the output seems ok, but enable https://wiki.archlinux.org/title/NVIDIA … de_setting, use the "nvidia_drm.modeset=1" parameter (modprobe.conf won't suffice) and do NOT enable fbdev=1 (until nvidia fixed that)

Last edited by seth (2024-02-05 21:24:45)

山猿 · 2024-02-05 23:09:56

seth wrote:

polybar module … still displays when … the screen being frozen … A video that was playing continued to play … F3 on Firefox (the focused window) and the Quick Search bar would appear
Ie. the screen isn't frozen at all.

Yes, sorry I forgot to state that.

With
My mouse disappears
I suspect something grabs at least the pointer, maybe focus.

I believe this may be something to do with my bluetooth receiver as I have had this problem without the issues with the screen too. Though as I am unable to reliably reproduce this, I will just continue monitoring this issue.

immediately goes to a black screen
As long as you can get to *some* console, you're good.
Install xdotool and the next time this happens, switch to another TTY (3), login
export DISPLAY=:0 # that's a guess, make it the display of your X11 session)
xdotool key "XF86LogGrabInfo"
this will print all grabs into your xorg log, then post that (you can cat it into 0x0.st)
It's location depends on how the server is started: https://wiki.archlinux.org/title/Xorg#General

Thank you for this. As with the mouse, I will make sure to do this next time the problem arises.

Edit: I btw. suspect the cause to be ibus…

Thank you. I have disabled that module in polybar for now, to replace at a later date.

Edit #2: there's a massive amount of
Feb 05 18:13:55 sys systemd[1]: displaylink.service: Failed with result 'exit-code'.
Feb 05 18:13:55 sys systemd[1]: Failed to start DisplayLink Manager Service.
Feb 05 18:14:01 sys systemd[1]: displaylink.service: Scheduled restart job, restart counter is at 1408.
Feb 05 18:14:01 sys systemd[1]: Starting DisplayLink Manager Service...
Feb 05 18:14:01 sys modprobe[3824444]: modprobe: FATAL: Module evdi not found in directory /lib/modules/6.7.3-arch1-1
Feb 05 18:14:01 sys systemd[1]: displaylink.service: Control process exited, code=exited, status=1/FAILURE
in the journal, you either forgot to rebuild the module or the dkms rebuild failed because of GPL restrictions in 6.7.3
If you can't build the module, you should better disable the service for the time being.

I have tried both

sudo dkms autoinstall

and

su
Password:
[root@sys user]# dkms autoinstall

but unless this is intended behaviour, all this does is print a newline with no other feedback. The same output (or lack thereof) occurs when running

# dkms status

For now, I have disabled displaylink.service via systemctl, as you suggested.

---
This is probably unrelated since the output seems ok, but enable https://wiki.archlinux.org/title/NVIDIA … de_setting, use the "nvidia_drm.modeset=1" parameter (modprobe.conf won't suffice) and do NOT enable fbdev=1 (until nvidia fixed that)

I just wanted to check I did this correctly. Following the direction on the wiki, I typed;

sudo modprobe nvidia_drm nvidia_drm.modeset=1

Would this be correct? I assumed because of this sentence;

For nvidia driver version < 545 or when not also using fbdev=1, the nvidia_drm.modeset=1 option must be set through kernel parameters, in order to disable simpledrm.

That the parameter would be nvidia_drm.modeset=1 over modeset=1 following the format here.

Thank you once again.

seth · 2024-02-05 23:14:45

The module is likely already loaded, you want to change the https://wiki.archlinux.org/title/Kernel_parameters
As for evdi:

dkms status

I have disabled that module in polybar for now

I don't think that polybar is the problem, it's - iff - that you're using ibus at all. But we'll hopefully see with the active grabs in the log.

I believe this may be something to do with my bluetooth receiver as I have had this problem without the issues with the screen too.

What "problem without the issues with the screen"?
Do you have a $5 office supply mouse with a tail?

山猿 · 2024-02-06 00:28:45

seth wrote:

The module is likely already loaded, you want to change the https://wiki.archlinux.org/title/Kernel_parameters

Thank you. So I now did;

sudo nano /etc/default/grub

And as per the wiki, edited GRUB_CMDLINE_LINUX_DEFAULT by appending nvidia_drm.modeset=1 and then running the command;

sudo grub-mkconfig -o /boot/grub/grub.cfg

As for evdi:
dkms status

As per above, unfortunately this does not yield a result but simply prints a blank newline.

I have disabled that module in polybar for now
I don't think that polybar is the problem, it's - iff - that you're using ibus at all. But we'll hopefully see with the active grabs in the log.

I did try to solve my issue some time ago using setxkbmap but I did not find the particular input method I was looking for with Japanese as, so far as I can tell, you cannot use the Latin input to generate kanji. This was all I intended to use ibus for. In that case, would something like Fcitx5 with mozc seem to be fine, or at least not cause the issue described in this thread?

I believe this may be something to do with my bluetooth receiver as I have had this problem without the issues with the screen too.
What "problem without the issues with the screen"?
Do you have a $5 office supply mouse with a tail?

Sorry, I meant the same problem where the mouse disappears and I am unable to move the mouse to 'wake' it or get the pointer to reappear. My keyboard also periodically loses a bluetooth connection to the system.

Respectively, the mouse is a ROG Gladius III, and the keyboard is a Majestouch Convertible 2.

EDIT:

I thought to add greater context as I experienced a freeze again; I believe this was induced by using the caps lock key whilst running the ibus-engine shell script in polybar, which was pasted here. Running

export DISPLAY=:0
xdotool key "XF86LogGrabInfo"

produced the following output for tty1 (the tty which, after logging in, goes immediately to a black screen) and tty2 (the primary display for the X11 session, where the freeze occurred).

As before, during previous 'freezes', the active window could still be interacted with the keyboard (and only the keyboard) and no other windows, workspaces, or screens could be interacted with through either the keyboard or mouse.

Last edited by 山猿 (2024-02-06 04:20:00)

seth · 2024-02-06 09:21:35

As per above, unfortunately this does not yield a result but simply prints a blank newline.

Means you don't have the evdi dkms, do you have any evdi pacakges? You you use displaylink?

pacman -Qs evdi

Ibus is off the hook

[ 10981.301]       client pid 893 bspwm -s /tmp/bspwm_0_0-state -o 4
[ 10981.301]       at 9990782 (from passive grab) (device frozen, state 6)
[ 10981.301]         core event mask 0x4
[ 10981.301]       passive grab type 4, detail 0x1, activating key 0
[ 10981.301]       owner-events false, kb 1 ptr 0, confine 0, cursor 0x0
[ 10981.301] (II) End list of active device grabs

It's bspwm…
/etc/X11/xorg.conf.d/10-server.conf

Section "ServerFlags"
       Option             "AllowDeactivateGrabs" "true" # also run setxkbmap -option grab:break_actions
#       Option             "AllowClosedownGrabs" "true"
EndSection

Add that file, and run the setxkbmap option.
Afterwards Ctrl+Alt+Keypad-Divide will allow you to break active grabs - you can test this by eg. running "xprop", the cursor will turn into a cross and clicking something will print information about the window, but if you break the grab before, it won't and the mouse work as usual.
You can also use "xdotool key XF86XK_Ungrab" from a console like before.

nb. that the grab breaking feature is a security risk this is only good for testing whether the mouse is actually still there. You deactivate it right after this is fixed!!
In a hostile environment you should also run "setxkbmap -option grab:break_actions" from a console login only before you actually have to break the grab - don't forget to export the DISPLAY on the console.

Furthermore please post your entire Xorg log after the freeze, it'll show whether an input device disappeared at the time.

山猿 · 2024-02-07 07:01:48

seth wrote:

As per above, unfortunately this does not yield a result but simply prints a blank newline.
Means you don't have the evdi dkms, do you have any evdi pacakges? You you use displaylink?
pacman -Qs evdi

My apologies; it took a little longer to see a 'freeze' today. I do have evdi packages and the displaylink service was initially enabled when first checking during the course of this thread's troubleshooting. I am not sure how it was being used in the past, but it has changed nothing so far as I can tell after disabling the service.

Ibus is off the hook
[ 10981.301]       client pid 893 bspwm -s /tmp/bspwm_0_0-state -o 4
[ 10981.301]       at 9990782 (from passive grab) (device frozen, state 6)
[ 10981.301]         core event mask 0x4
[ 10981.301]       passive grab type 4, detail 0x1, activating key 0
[ 10981.301]       owner-events false, kb 1 ptr 0, confine 0, cursor 0x0
[ 10981.301] (II) End list of active device grabs
It's bspwm…
/etc/X11/xorg.conf.d/10-server.conf
Section "ServerFlags"
       Option             "AllowDeactivateGrabs" "true" # also run setxkbmap -option grab:break_actions
#       Option             "AllowClosedownGrabs" "true"
EndSection
Add that file, and run the setxkbmap option.
Afterwards Ctrl+Alt+Keypad-Divide will allow you to break active grabs - you can test this by eg. running "xprop", the cursor will turn into a cross and clicking something will print information about the window, but if you break the grab before, it won't and the mouse work as usual.
You can also use "xdotool key XF86XK_Ungrab" from a console like before.
nb. that the grab breaking feature is a security risk this is only good for testing whether the mouse is actually still there. You deactivate it right after this is fixed!!
In a hostile environment you should also run "setxkbmap -option grab:break_actions" from a console login only before you actually have to break the grab - don't forget to export the DISPLAY on the console.
Furthermore please post your entire Xorg log after the freeze, it'll show whether an input device disappeared at the time.

Thanks for this. I added the file in /etc/X11/xorg.conf.d/10-server.conf. During the freeze, the mouse did not disappear and I could move it freely, but this was without inducing the breaker. I did test the breaker much earlier, using xprop, as you suggested.

I believe bspwm was hanging after I pressed super + alt + r (the key combination in sxhkd to restart bspwm; bspc wm -r).

During the freeze, incidentally, I thought that there was something wrong with Firefox and was going to use xprop to find the PID. As such, urxvt printed to the window that it could not find the mouse, and so xprop did not work. I tried, subsequently, typing the setxkbmap option into urxvt but this did not work to get the mouse recognised by xprop, nor did pressing ctrl + alt + keypad-divide.

Additionally, please find the entire log from the journal here.

Thank you very much for your help on this.

Last edited by 山猿 (2024-02-07 07:54:05)

seth · 2024-02-07 08:28:20

Your xorg log after losing the mouse would be more interesting.

The "DigiHug USB Audio" quite acts up - and it comes with an input device. You might want to test removing that.

Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/ldac
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/aptx_hd
Feb 07 06:40:12 sys systemd[1]: Started Getty on tty3.
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_hd
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/aptx
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/aac
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aac
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/sbc
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/sbc
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/sbc_xq
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/sbc_xq
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_ll_1
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_ll_0
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/faststream
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/faststream_duplex
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/opus_05
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/opus_05
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/opus_05_duplex
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/opus_05_duplex
Feb 07 06:40:21 sys login[509922]: pam_unix(login:session): session opened for user user(uid=1000) by user(uid=0)
Feb 07 06:40:21 sys systemd-logind[680]: New session 3 of user user.
Feb 07 06:40:21 sys systemd[1]: Started Session 3 of User user.
Feb 07 06:40:21 sys login[509922]: LOGIN ON tty3 BY user
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/ldac
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/aptx_hd
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_hd
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/aptx
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/aac
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aac
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/sbc
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/sbc
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/sbc_xq
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/sbc_xq
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_ll_1
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_ll_0
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/faststream
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/faststream_duplex
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/opus_05
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/opus_05
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/opus_05_duplex
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/opus_05_duplex

seth wrote:

Do you have a $5 office supply mouse with a tail?

Your wifi is on 5GHz, so that's not the problem.

山猿 · 2024-02-09 22:02:49

seth wrote:

Your xorg log after losing the mouse would be more interesting.

My apologies this has taken a bit longer than I had hoped; I was unable to induce bspwm to freeze and so I was waiting until it had occurred. I did try the following commands;

export DISPLAY=:0
xdotool key "XF86LogGrabInfo"

After using ctrl + alt + bksp to get to the dm but unfortunately received an error stating

Failed creating new xdo instance

Nonetheless, please find the entire Xorg.0.log here. I also subsequently logged into tty1, and the entire Xorg.0.log following that action is available here.

The "DigiHug USB Audio" quite acts up - and it comes with an input device. You might want to test removing that.

Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/ldac
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/aptx_hd
Feb 07 06:40:12 sys systemd[1]: Started Getty on tty3.
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_hd
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/aptx
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/aac
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aac
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/sbc
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/sbc
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/sbc_xq
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/sbc_xq
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_ll_1
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_ll_0
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/faststream
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/faststream_duplex
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/opus_05
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/opus_05
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSink/opus_05_duplex
Feb 07 06:40:12 sys bluetoothd[677]: Endpoint unregistered: sender=:1.23 path=/MediaEndpoint/A2DPSource/opus_05_duplex
Feb 07 06:40:21 sys login[509922]: pam_unix(login:session): session opened for user user(uid=1000) by user(uid=0)
Feb 07 06:40:21 sys systemd-logind[680]: New session 3 of user user.
Feb 07 06:40:21 sys systemd[1]: Started Session 3 of User user.
Feb 07 06:40:21 sys login[509922]: LOGIN ON tty3 BY user
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/ldac
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/aptx_hd
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_hd
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/aptx
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/aac
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aac
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/sbc
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/sbc
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/sbc_xq
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/sbc_xq
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_ll_1
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_ll_0
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_1
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/aptx_ll_duplex_0
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/faststream
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/faststream_duplex
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/opus_05
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/opus_05
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSink/opus_05_duplex
Feb 07 06:40:22 sys bluetoothd[677]: Endpoint registered: sender=:1.369469 path=/MediaEndpoint/A2DPSource/opus_05_duplex

Thank you. Though I did not reply in the intervening period, I did remove this device (which is an amp for headphones) but unfortunately, the freeze as linked above still occurred.

seth wrote:
Do you have a $5 office supply mouse with a tail?
Your wifi is on 5GHz, so that's not the problem.

I am not quite sure what you mean, sorry for my misunderstanding. My mouse is connected to the computer via bluetooth, using bluetoothctl. It is the mouse here, if that helps.

Thank you very much for your help.

Last edited by 山猿 (2024-02-09 22:04:29)

seth · 2024-02-09 23:04:22

After using ctrl + alt + bksp

That killed the X11 server ("zapping")

Bluetooth operates on 2.4GHz and might interfere with wifi channels in that band, but you're using a 5GHz band.
You could still test a mouse that attaches via a USB cable, just to be sure.

The list of grabs in the second log is suspiciously empty

[ 16121.236] (II) Printing all currently active device grabs:
[ 16121.237] (II) End list of active device grabs
[ 16121.237] Printing all currently registered grabs
[ 16121.237]   Printing all registered grabs of client pid 1737423 xinit /home/user/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.WMBnwx6O3D
[ 16121.237]   Printing all registered grabs of client pid 1738287 xdotool key XF86LogGrabInfo
[ 16121.237] End list of registered passive grabs

Was there no WM running at that time?

山猿 · 2024-02-09 23:23:08

seth wrote:

After using ctrl + alt + bksp
That killed the X11 server ("zapping")

I will try capturing the xorg log without doing this and going straight to tty3 next time. From memory, I think it provided the error;

Failed creating new xdo instance

but I will check again for this.

Bluetooth operates on 2.4GHz and might interfere with wifi channels in that band, but you're using a 5GHz band.
You could still test a mouse that attaches via a USB cable, just to be sure.

Thank you, I did not know this. In that case, I will try running with a USB cable for some time to see if that correlates with any freezes within the same frequency (around one every few days, at present).

The list of grabs in the second log is suspiciously empty

[ 16121.236] (II) Printing all currently active device grabs:
[ 16121.237] (II) End list of active device grabs
[ 16121.237] Printing all currently registered grabs
[ 16121.237]   Printing all registered grabs of client pid 1737423 xinit /home/user/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.WMBnwx6O3D
[ 16121.237]   Printing all registered grabs of client pid 1738287 xdotool key XF86LogGrabInfo
[ 16121.237] End list of registered passive grabs

Was there no WM running at that time?

That is correct, there was no WM from the second log. After capturing the first log (where bspwm on tty2 froze) via tty3, I switched over from tty3 to tty1 and logged in via the console prompt. Once logged in, I was shown the neofetch summary, after which the screen went entirely blank. I could still switch over to tty3, and did so; running

export DISPLAY=:0
xdotool key "XF86LogGrabInfo"

yielded the second log.

Last edited by 山猿 (2024-02-09 23:23:42)

seth · 2024-02-10 10:17:54

The most likely cause for "Failed creating new xdo instance" is that no connection to the server could be established, either because there was no server or you forgot to export the DISPLAY or you exported the wrong value or typo'd it.
There's typically a "Error: Can't open display" along it.

山猿 · 2024-02-10 20:44:35

seth wrote:

The most likely cause for "Failed creating new xdo instance" is that no connection to the server could be established, either because there was no server or you forgot to export the DISPLAY or you exported the wrong value or typo'd it.
There's typically a "Error: Can't open display" along it.

I am not quite sure why it was doing this. I did double check my spelling, which matched the command provided above; could it be that no server was recognised in that case? I would need to check again to ensure I did everything correctly.

Nonetheless, as I was experimenting today, I did not leave the mouse connected via USB cable to the computer. bspwm did freeze (though I am not sure if the mouse being connected via bluetooth was the cause as of yet), following my inputting a number of shortcuts (to open rofi and change workspace) in fairly quick succession.

The entire Xorg log (without zapping tty2) is available here.

I should add, also, each time I reboot, I get a message stating;

[FAILED] Failed unmounting Temporary Directory /tmp

Thank you very much for your help.

Last edited by 山猿 (2024-02-10 20:48:36)

seth · 2024-02-10 21:20:41

[    22.051] Current Operating System: Linux sys 6.7.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000 x86_64

Server starts

[  5901.477] (--) NVIDIA(GPU-0): 
[ 10584.700] (**) Option "fd" "37"

There's a massive gap in the log, was the system sleeping?

[ 10584.701] (II) event22 - ROG GLADIUS III WL Mouse: device removed
[ 10585.218] (II) systemd-logind: got pause for 13:71

Did you switch to a different VT here?

[ 10624.609] (II) systemd-logind: got resume for 13:71
[ 10624.652] (--) NVIDIA(GPU-0): HP Inc. HP V27i (DFP-0): connected
…
[ 10625.273] (II) event22 - ROG GLADIUS III WL Mouse: is tagged by udev as: Mouse
[ 10625.273] (II) event22 - ROG GLADIUS III WL Mouse: device is a pointer

~40s later you're returning to the X11 server

[ 10935.168] (**) Option "fd" "46"
[ 10935.168] (II) event1  - Power Button: device removed

~5 minutes later you're switching the VT again

[ 10959.279] (II) Printing all currently active device grabs:

And 25s later you're printing the grabs.

But there's nothing that looks like the mouse disappeared in isolation, I assume this is a plain bspwm bug.
There're https://github.com/baskerville/bspwm/issues/1154 and https://github.com/baskerville/bspwm/issues/619 but they're entirely inconclusive.
You should certainly try to repeat the bug w/ a wired mouse.

Did you try to "AllowDeactivateGrabs" and break the grab to see how the system behaves afterwards?

Unmounting /tmp might/will fail if a file inside is still being kept open at the time.
eg. /tmp/bspwm_0_0-state - but I'd suspect that bspwm terminated at the time.
You'll have to check the system logs on whether there's a hint, but as long as /tmp is a tmpfs this is - hopefully - without consequences as it's volatile storage and gone with the reboot anyway.

山猿 · 2024-02-10 21:37:47

Hi,

Thank you for this; it is really helpful.

seth wrote:

[    22.051] Current Operating System: Linux sys 6.7.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000 x86_64

Server starts

[  5901.477] (--) NVIDIA(GPU-0): 
[ 10584.700] (**) Option "fd" "37"

There's a massive gap in the log, was the system sleeping?

Unless these Xorg logs are recorded over multiple days (apologies, I am not sure if this is the case), the system was not sleeping. Today, for instance, I have been using the computer continuously with a break of maybe a few minutes total.

[ 10584.701] (II) event22 - ROG GLADIUS III WL Mouse: device removed
[ 10585.218] (II) systemd-logind: got pause for 13:71

Did you switch to a different VT here?

[ 10624.609] (II) systemd-logind: got resume for 13:71
[ 10624.652] (--) NVIDIA(GPU-0): HP Inc. HP V27i (DFP-0): connected
…
[ 10625.273] (II) event22 - ROG GLADIUS III WL Mouse: is tagged by udev as: Mouse
[ 10625.273] (II) event22 - ROG GLADIUS III WL Mouse: device is a pointer

~40s later you're returning to the X11 server

[ 10935.168] (**) Option "fd" "46"
[ 10935.168] (II) event1  - Power Button: device removed

~5 minutes later you're switching the VT again

[ 10959.279] (II) Printing all currently active device grabs:

And 25s later you're printing the grabs.

That is correct; I was switching between tty2 and tty3 in this instance. On previous occasions, I would do ctrl + alt + bksp to get back to the dm (ly) which would zap the server and hence not get the full Xorg log. This time, I simply switched to tty3, exported DISPLAY, and ran the xdotool command. Intermittently, I would switch back to tty2 to see if I could get any of my inputs registered or cause bspwm to do anything, but this did not work, unfortunately.

But there's nothing that looks like the mouse disappeared in isolation, I assume this is a plain bspwm bug.
There're https://github.com/baskerville/bspwm/issues/1154 and https://github.com/baskerville/bspwm/issues/619 but they're entirely inconclusive.
You should certainly try to repeat the bug w/ a wired mouse.

Thank you for those links. I will attempt to run the system with a wired mouse for a few days and, assuming that bspwm does not freeze, send all of this information as a bug report to bspwm to hopefully derive a fix.

Did you try to "AllowDeactivateGrabs" and break the grab to see how the system behaves afterwards?

I did try ctrl + alt + keypad-divide, but this did not do anything. Or at least, nothing had perceptibly changed on the system. If this occurs during the period in which I am using a wired mouse, I will do this again, and record the Xorg log. If not, I will separately test this functionality with the mouse in its bluetooth mode (after testing it in wired mode).

Unmounting /tmp might/will fail if a file inside is still being kept open at the time.
eg. /tmp/bspwm_0_0-state - but I'd suspect that bspwm terminated at the time.
You'll have to check the system logs on whether there's a hint, but as long as /tmp is a tmpfs this is - hopefully - without consequences as it's volatile storage and gone with the reboot anyway.

The only thing I could find related to that is;

[ 10959.279]       client pid 855 bspwm -s /tmp/bspwm_0_0-state -o 4
[ 10959.279]       at 10560235 (from passive grab) (device frozen, state 6)
[ 10959.279]         core event mask 0x4
[ 10959.279]       passive grab type 4, detail 0x1, activating key 0
[ 10959.279]       owner-events false, kb 1 ptr 0, confine 0, cursor 0x0

But yes, /tmp is a tmpfs I believe; nothing else in non volatile storage appears to be missing or otherwise, and this error message has printed every time upon rebooting or shutting down the system.

seth · 2024-02-10 22:39:34

Or at least, nothing had perceptibly changed on the system.

Fyi the log doesn't suggest the feature is enabled and you'll have to allow the shortcut via setxkbmap as well.

I would switch back to tty2 to see if I could get any of my inputs registered or cause bspwm to do anything, but this did not work, unfortunately.

xdotool mouseup # assuming the pointer is grabbed b/c bspwm thinks it's down after missing an up event

Arch Linux

#1 2024-02-04 23:54:59

Xorg/screen/Nvidia freezing

#2 2024-02-05 09:51:12

Re: Xorg/screen/Nvidia freezing

#3 2024-02-05 19:27:35

Re: Xorg/screen/Nvidia freezing

#4 2024-02-05 21:18:58

Re: Xorg/screen/Nvidia freezing

#5 2024-02-05 23:09:56

Re: Xorg/screen/Nvidia freezing

#6 2024-02-05 23:14:45

Re: Xorg/screen/Nvidia freezing

#7 2024-02-06 00:28:45

Re: Xorg/screen/Nvidia freezing

#8 2024-02-06 09:21:35

Re: Xorg/screen/Nvidia freezing

#9 2024-02-07 07:01:48

Re: Xorg/screen/Nvidia freezing

#10 2024-02-07 08:28:20

Re: Xorg/screen/Nvidia freezing

#11 2024-02-09 22:02:49

Re: Xorg/screen/Nvidia freezing

#12 2024-02-09 23:04:22

Re: Xorg/screen/Nvidia freezing

#13 2024-02-09 23:23:08

Re: Xorg/screen/Nvidia freezing

#14 2024-02-10 10:17:54

Re: Xorg/screen/Nvidia freezing

#15 2024-02-10 20:44:35

Re: Xorg/screen/Nvidia freezing

#16 2024-02-10 21:20:41

Re: Xorg/screen/Nvidia freezing

#17 2024-02-10 21:37:47

Re: Xorg/screen/Nvidia freezing

#18 2024-02-10 22:39:34

Re: Xorg/screen/Nvidia freezing

Board footer