Public bug reported:

It appears that using Xorg instead of Wayland is the only way to fix
this problem on Ubuntu 17.10. For some odd reason, whenever I wake my
computer from suspend (especially after an extended period of time
asleep) using Gnome in a Wayland session (gnome-session and stock
ubuntu-session alike), my screen freezes completely on whatever was last
there before suspending and I can't get any IO response at all. Nothing,
the screen is totally frozen. I am also unable to exit into a recovery
shell or kill GDM or gnome-session/ubuntu-session locally. I also can't
seem to find any traces or indications for the freeze in the syslog, or
maybe I'm just not sure where to look. I believe this is a problem with
GDM on Wayland, not kernel related, as it happens on a totally stock
install and when I use an upgraded/downgraded kernel. It literally
necessitates restarting my computer. This problem is nonexistent when
using Xorg instead of Wayland with GDM. Anyone else have this issue on
Ubuntu 17.10 or figure out a solution better than simply switching to
Xorg? I should clarify that I am not using nvidia drivers, I'm using
Intel integrated graphics on a core-i7 5500U.

Ubuntu 17.10 uses gnome-session v3.26.1.
Expected behavior: When waking computer from suspend, expect GDM lock prompt 
and log back in.
What happened instead: When waking computer from suspend, screen and IO is 
completely frozen, necessitating a force-shutdown.

** Affects: gdm (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: gnome-session (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: wayland (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: gdm gnome-17.10 gnome-session suspend-resume

** Also affects: gnome-session (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: wayland (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gdm in Ubuntu.
https://bugs.launchpad.net/bugs/1728143

Title:
  Screen freezes after waking from suspend with Gnome on Wayland

Status in gdm package in Ubuntu:
  New
Status in gnome-session package in Ubuntu:
  New
Status in wayland package in Ubuntu:
  New

Bug description:
  It appears that using Xorg instead of Wayland is the only way to fix
  this problem on Ubuntu 17.10. For some odd reason, whenever I wake my
  computer from suspend (especially after an extended period of time
  asleep) using Gnome in a Wayland session (gnome-session and stock
  ubuntu-session alike), my screen freezes completely on whatever was
  last there before suspending and I can't get any IO response at all.
  Nothing, the screen is totally frozen. I am also unable to exit into a
  recovery shell or kill GDM or gnome-session/ubuntu-session locally. I
  also can't seem to find any traces or indications for the freeze in
  the syslog, or maybe I'm just not sure where to look. I believe this
  is a problem with GDM on Wayland, not kernel related, as it happens on
  a totally stock install and when I use an upgraded/downgraded kernel.
  It literally necessitates restarting my computer. This problem is
  nonexistent when using Xorg instead of Wayland with GDM. Anyone else
  have this issue on Ubuntu 17.10 or figure out a solution better than
  simply switching to Xorg? I should clarify that I am not using nvidia
  drivers, I'm using Intel integrated graphics on a core-i7 5500U.

  Ubuntu 17.10 uses gnome-session v3.26.1.
  Expected behavior: When waking computer from suspend, expect GDM lock prompt 
and log back in.
  What happened instead: When waking computer from suspend, screen and IO is 
completely frozen, necessitating a force-shutdown.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1728143/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to