I'm also running into this bug (or at least something that looks like it). Typically what happens for me is that I resume from suspend, get an unlock prompt (the system is locked on suspend) and when I log in, the unlock prompt stays visible (the password dots disappear, but I cannot type anything or click any buttons). When I then kill X to recover (ctrl-alt-backspace), I get a new login prompt. Sometimes, logging in again no longer works then, seeing such messages in the console:
jun 21 17:01:50 grubby at-spi-bus-launcher[30649]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":1024"
jun 21 17:01:50 grubby at-spi-bus-launcher[30649]: after 21 requests (21 known processed) with 0 events remaining.
jun 21 17:01:50 grubby gsd-power[30703]: gsd-power: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby gsd-keyboard[30715]: gsd-keyboard: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby gsd-xsettings[30696]: gsd-xsettings: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby gsd-media-keys[30731]: gsd-media-keys: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby systemd-logind[1100]: Session c9 logged out. Waiting for processes to exit.
jun 21 17:01:50 grubby gsd-clipboard[30695]: gsd-clipboard: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby gsd-color[30713]: gsd-color: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby gnome-shell[30633]: Connection to xwayland lost
From the messages, I suspect this might be the same problem as the original poster.
However, I'm not entirely sure if at-spi-bus-launcher is actually the culprit here. Could it be that that the xserver or xwayland (I'm not sure which - I'm using the GNOME xorg session since the wayland session doesn't work for me, but the log does talk about xwayland) crashes and that at-spi-bus-launcher is just the first process to find out (because it does so many requests maybe?). I've also seen some instances where at-spi-bus-launcher is not the first one in the log, and I've tried disabling at-spi-bus-launcher by masking it in systemd (not entirely sure if that really worked), but then I also think I saw a crash where at-spi-bus-launcher would not show up in the log at all.
One additional observation: At some point during testing, while login would not work, I found a logged in session in some virtual terminal. After logging out that session, logins would work again as normal. I'm not entirely sure if there's a causal relationship there, nor where that logged in session came from (but I was testing with two different users to see if there was something in my homedir that triggered it, so perhaps it came from one of those tests...). Vague, but I wanted to mention this just in case it triggers an idea somewhere :-)
As for reporting an upstream issue, that is probably a good idea, though I'm not entirely sure where the cause is. It's probably safe to say it is something in gnome, though.
I'm also running into this bug (or at least something that looks like it). Typically what happens for me is that I resume from suspend, get an unlock prompt (the system is locked on suspend) and when I log in, the unlock prompt stays visible (the password dots disappear, but I cannot type anything or click any buttons). When I then kill X to recover (ctrl-alt- backspace) , I get a new login prompt. Sometimes, logging in again no longer works then, seeing such messages in the console:
jun 21 17:01:50 grubby at-spi- bus-launcher[ 30649]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":1024" bus-launcher[ 30649]: after 21 requests (21 known processed) with 0 events remaining. 30715]: gsd-keyboard: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024. 30696]: gsd-xsettings: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024. keys[30731] : gsd-media-keys: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024. logind[ 1100]: Session c9 logged out. Waiting for processes to exit. 30695]: gsd-clipboard: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby at-spi-
jun 21 17:01:50 grubby gsd-power[30703]: gsd-power: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby gsd-keyboard[
jun 21 17:01:50 grubby gsd-xsettings[
jun 21 17:01:50 grubby gsd-media-
jun 21 17:01:50 grubby systemd-
jun 21 17:01:50 grubby gsd-clipboard[
jun 21 17:01:50 grubby gsd-color[30713]: gsd-color: Fatal IO error 11 (Resource temporarily unavailable) on X server :1024.
jun 21 17:01:50 grubby gnome-shell[30633]: Connection to xwayland lost
From the messages, I suspect this might be the same problem as the original poster.
However, I'm not entirely sure if at-spi-bus-launcher is actually the culprit here. Could it be that that the xserver or xwayland (I'm not sure which - I'm using the GNOME xorg session since the wayland session doesn't work for me, but the log does talk about xwayland) crashes and that at-spi-bus-launcher is just the first process to find out (because it does so many requests maybe?). I've also seen some instances where at-spi-bus-launcher is not the first one in the log, and I've tried disabling at-spi-bus-launcher by masking it in systemd (not entirely sure if that really worked), but then I also think I saw a crash where at-spi-bus-launcher would not show up in the log at all.
One additional observation: At some point during testing, while login would not work, I found a logged in session in some virtual terminal. After logging out that session, logins would work again as normal. I'm not entirely sure if there's a causal relationship there, nor where that logged in session came from (but I was testing with two different users to see if there was something in my homedir that triggered it, so perhaps it came from one of those tests...). Vague, but I wanted to mention this just in case it triggers an idea somewhere :-)
As for reporting an upstream issue, that is probably a good idea, though I'm not entirely sure where the cause is. It's probably safe to say it is something in gnome, though.