Login screen never appears on vmwgfx using bionic kernel 4.15

[Pat]

[Impact]

With most recent version of mutter installed.
If running kernel is in the 4.15 serie (using the vmwgfx video kernel driver) and if the login screen uses wayland, then the login prompt doesn't appears. All we see is the purple background with ubuntu in white at the bottom, nothing else.

The vmwgfx driver in kernels prior to 4.17 reported bogus timestamps using the wrong clock. This would lead us to wait forever (or at least 49 years)
before rendering the next frame. There's no decisive way to know this kernel bug is going to happen before it does so just detect timestamps which are obviously going to cause freezes and ignore them.

[Test case]

1) Use Virtualbox or VMware ESxi (if you have the infra)
 1.1) [virtualbox] Make sure in the VM setting that the display uses 'VMSVGA' which will force the OS to pick 'vmwgfx' video kernel driver. You can confirm with 'lspci -nnvv' command.
2) Deploy a VM with Ubuntu 18.04.1 (which come w/ 4.15)
4) apt-get dist-upgrade
5) Reboot

with 4.15 it will fails
with hwe kernel 4.18 it will work as expected. # workaround

[Potential regression]

Low, it should fix vmwgfx and stop using the wrong clock.

A test kernel (pre-sru) has been made available to impact users for them to test and conclude it works. It does work as expected, and no regression has been found during the pre-sru testing phase.

As per commit description:

"
This should be transparent to to user space, as long as it doesn't
compare the time against the result of gettimeofday().
"

[Other informations]

upstream fix:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc5&id=37efe80ce85f

[Original description]

I'm running Ubuntu 18.04.2 desktop in a virtual machine under VMWare Fusion Pro V11.1.0 on MacOS Mojave 10.14.5, all on a 15inch 2018 Macbook Pro.

I've been running this Ubuntu 18.04.2 VM without problem for many months without problem.
Yesterday, I did 'sudo apt update; sudo apt upgrade'. Upon rebooting, the system hangs immediately after displaying the splash screen. I never see a login screen. And I can't use Ctrl+Alt+F2 to navigate to a console/tty login.

I can SSH into the system however.

I've found that I can work around the hang/freeze if I uncomment the following line in /etc/gdm3/custom.conf;
#WaylandEnable=false

After uncommenting the WaylandEnable=false line and rebooting, then I see the login prompt as expected and I can then log in and use the system normally again.

After the 'apt upgrade' my system is running linux kernel 4.15.0-51, as shown in this 'uname -a' output;

Linux ubuntuvm1 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a output;

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
Uname: Linux 4.15.0-51-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CompositorRunning: None
Date: Sun Jun 9 12:38:37 2019
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GpuHangFrequency: This is the first time
GraphicsCard:
 VMware SVGA II Adapter [15ad:0405] (prog-if 00 [VGA controller])
   Subsystem: VMware SVGA II Adapter [15ad:0405]
InstallationDate: Installed on 2018-05-06 (399 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
MachineType: VMware, Inc. VMware Virtual Platform
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-51-generic root=/dev/mapper/ubuntu--vg-root ro splash net.ifnames=0
SourcePackage: xorg
Symptom: display
Title: Xorg freeze
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/13/2018
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: 440BX Desktop Reference Platform
dmi.board.vendor: Intel Corporation
dmi.board.version: None
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd04/13/2018:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
dmi.product.name: VMware Virtual Platform
dmi.product.version: None
dmi.sys.vendor: VMware, Inc.
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.95-1~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.8-0ubuntu0~18.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.8-0ubuntu0~18.04.2
version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

In order to debug this problem we would need you to reintroduce it. That means:

1. Comment out again:

  WaylandEnable=false

2. Reboot and ensure you don't see the login screen.

3. Log in via SSH while the problem is happening and run:

   journalctl -b0 > hungboot.txt

   and send us the resulting file 'hungboot.txt'.

[Pat (pat-h)]

Hi Daniel,
Here is the hungboot.txt file you requested.

[Daniel van Vugt (vanvugt)]

Thanks. That log is shorter than I expected.

Maybe something crashed in the startup process. Can you please try these instructions?

https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment

[Pat (pat-h)]

Hi Daniel,

It doesn't appear anything has actually crashed when this scenario happens.
/var/crash is empty

The contents of my /var/lib/whoopsie/whoopsie-id is;
d0d31e5e858096f38cba06e106ab0375a0e96fd9fda7031d320fa3966f0064bba364acdc53d42bce08a29148a49314d352455fe8b6cb716c20dbf804d8711876

There is nothing at;https://errors.ubuntu.com/user/d0d31e5e858096f38cba06e106ab0375a0e96fd9fda7031d320fa3966f0064bba364acdc53d42bce08a29148a49314d352455fe8b6cb716c20dbf804d8711876

When the system boots up, I briefly see the splash screen then the splash goes away and all I see is a completely blank purple-ish page. No login page. No indications at all that anything has gone wrong perse. And no log files.

If I ssh into the system,

Here is output of 'sudo systemctl status gdm'

----- snip -----
● gdm.service - GNOME Display Manager
   Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor preset: enabled)
   Active: active (running) since Sun 2019-06-09 21:12:34 MDT; 2min 59s ago
  Process: 1095 ExecStartPre=/usr/share/gdm/generate-config (code=exited, status=0/SUCCESS)
 Main PID: 1098 (gdm3)
    Tasks: 3 (limit: 4651)
   CGroup: /system.slice/gdm.service
           └─1098 /usr/sbin/gdm3

Jun 09 21:12:34 ubuntuvm1 systemd[1]: Starting GNOME Display Manager...
Jun 09 21:12:34 ubuntuvm1 systemd[1]: Started GNOME Display Manager.
Jun 09 21:12:34 ubuntuvm1 gdm-launch-environment][1112]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
----- snip -----

Here is output of 'sudo systemctl status session-c1.scope';

----- snip -----
● session-c1.scope - Session c1 of user gdm
   Loaded: loaded (/run/systemd/transient/session-c1.scope; transient)
Transient: yes
   Active: active (running) since Sun 2019-06-09 21:12:34 MDT; 12min ago
    Tasks: 102
   CGroup: /user.slice/user-120.slice/session-c1.scope
           ├─1112 gdm-session-worker [pam/gdm-launch-environment]
           ├─1274 /usr/lib/gdm3/gdm-wayland-session gnome-session --autostart /usr/share/gdm/greeter/autostart
           ├─1285 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
           ├─1383 /usr/bin/gnome-shell
           ├─1461 /usr/bin/Xwayland :1024 -rootless -terminate -accessx -core -listen 4 -listen 5 -displayfd 6
           ├─1528 ibus-daemon --xim --panel disable
           ├─1531 /usr/lib/ibus/ibus-dconf
           ├─1534 /usr/lib/ibus/ibus-x11 --kill-daemon
           ├─1550 /usr/lib/gnome-settings-daemon/gsd-xsettings
           ├─1554 /usr/lib/gnome-settings-daemon/gsd-a11y-settings
           ├─1556 /usr/lib/gnome-settings-daemon/gsd-clipboard
           ├─1558 /usr/lib/gnome-settings-daemon/gsd-color
           ├─1560 /usr/lib/gnome-settings-daemon/gsd-datetime
           ├─1561 /usr/lib/gnome-settings-daemon/gsd-housekeeping
           ├─1562 /usr/lib/gnome-settings-daemon/gsd-keyboard
           ├─1563 /usr/lib/gnome-settings-daemon/gsd-media-keys
           ├─1568 /usr/lib/gnome-settings-daemon/gsd-mouse
           ├─1570 /usr/lib/gnome-settings-daemon/gsd-power
           ├─1573 /usr/lib/gnome-settings-daemon/gsd-print-notifications
           ├─1578 /usr/lib/gnome-settings-daemon/gsd-rfkill
    ...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Seems like a bionic updates regression. Duplicate bug 1832320 confirms the same date.

[Daniel van Vugt (vanvugt)]

If I had to guess then I would guess the most likely cause is the changes I made in the latest update:

https://launchpad.net/ubuntu/+source/mutter/3.28.4-0ubuntu18.04.1

[Bill Coleman (bcole1701)]

CONFIRMED: Same situation running 18.04.2 on VMWare 12.5.9. After uncommenting the WaylandEnable=false line and rebooting, then I see the login prompt as expected and I can then log in and use the system normally again.

[Jussi Vänskä (jive)]

This workaround of commenting out the Wayland does not work on both my setups, W10 Enterprise running WMvare 15 Pro and remote ESXi 6.5. with 18.04.2LTS host.

I am able to login via safe mode -> login as root -> return to grub -> resume and keep VMware in windowed mode. Attempt to switch to full screen or resume in full screen mode crashes the system. The desktop size is however unusable for anything productive but this way I was able to salvage my work.

[Jussi Vänskä (jive)]

18.04.2LTS as guest of course. Here is dmesg listing after I bring up the gnome via safe mode on the local WS 15 Pro.

[Daniel van Vugt (vanvugt)]

Jussi,

That sounds like maybe a different bug. Although "commenting out the Wayland" is also not what you need to do. You need to change:

  #WaylandEnable=false

to:

  WaylandEnable=false

If that doesn't fix the problem for you then you have a different bug. In that case please open a new bug by running:

  ubuntu-bug mutter

from within the VM.

[Daniel van Vugt (vanvugt)]

I have been trying to reproduce this bug in VMware but have not been able to. Ubuntu 18.04 always starts up with a login screen successfully for me.

What it does not do successfully is offer the "Ubuntu on Wayland" option most of the time. So I expect that's the same root cause as this bug.

Ordinarily if Wayland support is attempted and fails gracefully then your journalctl log should show something like:

  Jun 14 02:28:16 ubuntu gnome-shell[790]: Failed to create backend: Could not find a primary drm kms device

If you don't see that message and still don't get Wayland support then it suggests mutter/gnome-shell is crashing during that attempt to try Wayland. In that case we would ask you to follow these instructions from within the virtual machine:

  https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment

I'll dig a bit deeper to try and find out why Wayland support seems to work so rarely, because that's the part of this bug I can reproduce.

[Daniel van Vugt (vanvugt)]

Looking at hungboot.txt I am starting to think maybe the login screen ('gnome-shell' process) is actually running in Wayland mode but failing to display. That would explain a lot...

Pat, can you please reproduce the bug again and while it is happening:

 1. SSH into the VM.

 2. Run 'pidof gnome-shell' to find out the process ID of that process. Tell us if you don't get a result.

 3. If you do get a result from step 2 then using that PID run:

    sudo kill -ABRT PID

    where PID is the process ID number.

 4. Wait 30 seconds.

 5. Hopefully a crash report will have been generated so now follow: https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment

[Neil Wilson (neil-aldur)]

For me the login screen hangs as the Ubuntu logo at the bottom of the screen fades in.

The crashes are here https://errors.ubuntu.com/user/9918ca952fad5050e5d19cd326c70f270fae7631e330cf3c0c0ee4c728f149c2412b9c7bbdbfed5f6d72b3f62f187ada199b6d5ac8043b4329d0bbe352b51487

[Jussi Vänskä (jive)]

Daniel

After uncommenting the Wayland option the login appears, I can log in but the desktop refuses to resize. This was working previously. Entering full screen however works and doesn't crash the system.

The crash with kernel option nomodeset when resizing or attempting fullscreen is probably a different bug as you said.

[Pat (pat-h)]

Hi Daniel,
Sorry for the delay.
As requested, I reproduced the bug.
- I SSH'd into the VM
- /var/crash was empty
- 'pidof gnome-shell' returned a pid of 1423
- I ran 'sudo kill -ABRT 1423'
- two crash reports/files appeared in /var/crash
-rw-r----- 1 gdm whoopsie 20574823 Jun 15 06:12 _usr_bin_gnome-shell.120.crash
-rw-r----- 1 gdm whoopsie 2496646 Jun 15 06:12 _usr_bin_Xwayland.120.crash

- I ran 'sudo ubuntu-bug' on each crash file
- There is now two crash reports at;
https://errors.ubuntu.com/user/d0d31e5e858096f38cba06e106ab0375a0e96fd9fda7031d320fa3966f0064bba364acdc53d42bce08a29148a49314d352455fe8b6cb716c20dbf804d8711876

[Eric Desrochers (slashd)]

I reported the exact same problem and was able to reproduce.

Only using v4.15, if I use the hwe kernel 4.18 on Bionic it passes.

I have strong belief this kernel fix to be a potential good candidate, but need to run a bisection to confirm my assumption :

commit 140bcaa23a1c37b694910424075a15e009120dbe
Author: Thomas Hellstrom <email address hidden>
Date: Thu Mar 8 10:07:37 2018 +0100

    drm/vmwgfx: Fix black screen and device errors when running without fbdev

    When we are running without fbdev, transitioning from the login screen to
    X or gnome-shell/wayland will cause a vt switch and the driver will disable
    svga mode, losing all modesetting resources. However, the kms atomic state
    does not reflect that and may think that a crtc is still turned on, which
    will cause device errors when we try to bind an fb to the crtc, and the
    screen will remain black.

    Fix this by turning off all kms resources before disabling svga mode.

    Cc: <email address hidden>
    Signed-off-by: Thomas Hellstrom <email address hidden>
    Reviewed-by: Sinclair Yeh <email address hidden>

[Eric Desrochers (slashd)]

my bug report :
https://bugs.launchpad.net/bugs/1832903

[Eric Desrochers (slashd)]

can someone impacted try v4.18 hwr kernel ? and let me know if it works fine (without workarounds) just like it did for me ? I will perform the kernel bisect next week to see what v4.15 is missing that 4.18 has to fix this bug.

[Eric Desrochers (slashd)]

I marked this bug affecting the kernel 'linux', but I can't 'target to series' and choose Bionic. It's not in the option list anymore (something went wrong with that bug I think, but we can figure this out later (when/if an SRU is needed)):

The only option I have available are:
 Ff-series
 Disco
 Cosmic
 Xenial
 Trusty
 Precise

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Pat (pat-h)]

Eric,
I installed the 4.18 kernel on one of my Ubuntu 18.04 VMs by doing 'sudo apt install linux-generic-hwe-18.04'

As further evidence that you may be onto something...
The system boots up fine, presents a GUI login prompt, and I am able to login and use the system as expected (without having to uncomment #WaylandEnabled=false in /etc/gdm3/custom.conf)

[Eric Desrochers (slashd)]

Thanks Pat.

Glad you had the same result as I did.
I will start the kernel bisect to find out the commit which introduce the fix and confirm my potential good candidate that I found by doing a git log inspection.

Will keep you guys posted.

[Daniel Gutierrez (dgutierr)]

I have regular snapshots of my ESXi virtual machines and so using a snapshot before updating packages, I was able to install as many packages as I could before login broke in the way everyone is describing. I got down to the following packages:

gir1.2-mutter-2/bionic-updates 3.28.4-0ubuntu18.04.1 amd64 [upgradable from: 3.28.3+git20190124-0ubuntu18.04.2]

gnome-shell/bionic-updates 3.28.4-0ubuntu18.04.1 amd64 [upgradable from: 3.28.3+git20190124-0ubuntu18.04.2]

gnome-shell-common/bionic-updates,bionic-updates 3.28.4-0ubuntu18.04.1 all [upgradable from: 3.28.3+git20190124-0ubuntu18.04.2]

libmutter-2-0/bionic-updates 3.28.4-0ubuntu18.04.1 amd64 [upgradable from: 3.28.3+git20190124-0ubuntu18.04.2]

Seems the recent troubleshooting is on the right track.

[Eric Desrochers (slashd)]

Testing upstream kernel, I can tell this situation is not a Ubuntu kernel specific issue.
I can reproduce using upstream kernel.

This is where I'm at the moment:
BAD kernel : v4.16.18
GOOD kernel : v4.17-rc1

Leaving us to the following 'vmwgfx' commits to bisect:

----------------
$ git log --oneline v4.16.18..v4.17-rc1 --grep="drm/vmwgfx:"
----------------
320b164abb32 Merge tag 'drm-for-v4.17' of git://people.freedesktop.org/~airlied/linux
2a2553cc45c8 Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next
43bfefedd028 drm/vmwgfx: Bump version patchlevel and date
37efe80ce85f drm/vmwgfx: use monotonic event timestamps
20fb5a635a0c drm/vmwgfx: Unpin the screen object backup buffer when not used
89dc15b76fd3 drm/vmwgfx: Stricter count of legacy surface device resources
6073a09210e0 drm/vmwgfx: Use kasprintf
4e3e733b45df drm/vmwgfx: Get rid of the device-private suspended member
c3b9b1657344 drm/vmwgfx: Improve on hibernation
bf833fd36f9b drm/vmwgfx: Avoid pinning fbdev framebuffers
dc366364c4ef drm/vmwgfx: Fix multiple command buffer context use
ef86cfee7d74 drm/vmwgfx: Use the cpu blit utility for framebuffer to screen target blits
79273e1b7eb0 drm/vmwgfx: Add a cpu blit utility that can be used for page-backed bos
25db875401c8 drm/vmwgfx: Cursor update fixes
904efd9e3f4c drm/vmwgfx: Send the correct nonblock option for atomic_commit
ac3069e67f56 drm/vmwgfx: Move the stdu vblank event to atomic function
aa64b3f18aeb drm/vmwgfx: Move screen object page flip to atomic function
3cbe87fcf026 drm/vmwgfx: Remove drm_crtc_arm_vblank_event from atomic flush
4e2f9fa7ffb5 drm/vmwgfx: Move surface copy cmd to atomic function
91e9f352cd1b drm/vmwgfx: Avoid iterating over display unit if crtc is available
25a28906ebee drm/vmwgfx: replace drm_*_unreference with drm_*_put
4f4becef17d6 drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
----------------

As I said, I'll start the bisection on Monday.
My first feeling about the potential good candidate assumption was wrong but with recent testing, we now know the fix is amongst the commits listed above ^

- Eric

[Daniel van Vugt (vanvugt)]

Indeed there was a kernel update to 18.04 around the same time as the mutter update which I thought was causing this bug.

[Daniel van Vugt (vanvugt)]

Interesting one of the commits mentioned above:

  37efe80ce85f drm/vmwgfx: use monotonic event timestamps
  (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc5&id=37efe80ce85f)

is related to what I changed in the latest update to mutter:

  https://gitlab.gnome.org/GNOME/mutter/commit/e9e4b2b72

The latest update to mutter requires monotonic event timestamps in the kernel driver in order to work properly. It should kind of work without them, but that fallback is untested...

So if that is the problem then you might find reverting to the previous mutter version also works around the issue(?). You can download the debs:

  https://launchpad.net/ubuntu/+source/mutter/3.28.3+git20190124-0ubuntu18.04.2/+build/16644915

and then try installing them together:

  dpkg -i *.deb

[Daniel van Vugt (vanvugt)]

Pat,

Re comment #19, your crash (hang) reports there seem to show the gnome-shell process behaving normally (in poll) and not stuck at all. That doesn't tell us much but it would support the theory in comment #31.

[Daniel van Vugt (vanvugt)]

The problem I mentioned in comment #15 is now logged as bug 1833045. It's clearly different to this one.

[Daniel van Vugt (vanvugt)]

The status for mutter will remain incomplete till someone tries the suggestion from comment #31.

Sorry, I still can't reproduce this bug myself.

[Eric Desrochers (slashd)]

Building a kernel with "37efe80ce85f drm/vmwgfx: use monotonic event timestamps" being the HEAD doesn't exhibit the issue.

I'm now building and about to test 37efe80ce85f^1 (AKA 20fb5a635a0c) to confirm.
In theory it should fails with "20fb5a635a0c" if "37efe80ce85f" is the one.

- Eric

[Eric Desrochers (slashd)]

"20fb5a635a0c" also works just fine on my side, will continue with the kernel bisect.

[Eric Desrochers (slashd)]

wbug: With Bug
wnbug: With No Bug

git bisect start '--term-old=wbug' '--term-new=wnbug' '--' 'drivers/gpu/drm/vmwgfx'
# wbug: [62e9ccfaaedffd057e921fca976f9f7f71c9b254] Linux 4.16.18
git bisect wbug 62e9ccfaaedffd057e921fca976f9f7f71c9b254
# wnbug: [37efe80ce85f76b3b30d7b4ea40550e6a5a5b71a] drm/vmwgfx: use monotonic event timestamps
git bisect wnbug 37efe80ce85f76b3b30d7b4ea40550e6a5a5b71a
# wbug: [7928b2cbe55b2a410a0f5c1f154610059c57b1b2] Linux 4.16-rc1
git bisect wbug 7928b2cbe55b2a410a0f5c1f154610059c57b1b2
# wbug: [aa64b3f18aeb2cc4b74e69115df434147f1ed96c] drm/vmwgfx: Move screen object page flip to atomic function
git bisect wbug aa64b3f18aeb2cc4b74e69115df434147f1ed96c
# wnbug: [dc366364c4ef809dccd063919314301f8ba01ac2] drm/vmwgfx: Fix multiple command buffer context use
git bisect wnbug dc366364c4ef809dccd063919314301f8ba01ac2
# wnbug: [25db875401c8aaac31a6650cb80a56cc78852694] drm/vmwgfx: Cursor update fixes
git bisect wnbug 25db875401c8aaac31a6650cb80a56cc78852694
# wnbug: [904efd9e3f4c8f288b1279a316eed8e177190c8f] drm/vmwgfx: Send the correct nonblock option for atomic_commit
git bisect wnbug 904efd9e3f4c8f288b1279a316eed8e177190c8f
# wbug: [ac3069e67f5659131d7ac5f54d966005bbc40af8] drm/vmwgfx: Move the stdu vblank event to atomic function
git bisect wbug ac3069e67f5659131d7ac5f54d966005bbc40af8
# first wnbug commit: [904efd9e3f4c8f288b1279a316eed8e177190c8f] drm/vmwgfx: Send the correct nonblock option for atomic_commit

[Eric Desrochers (slashd)]

904efd9e3f4c8f288b1279a316eed8e177190c8f^ (AKA ac3069e67f5659131d7ac5f54d966005bbc40af8) have the problem, but 904efd9e3f4c8f288b1279a316eed8e177190c8f doesn't.

So the kernel bisection is completed and found the right good commit which is: https://github.com/torvalds/linux/commit/904efd9e3f4c8f288b1279a316eed8e177190c8f

[Eric Desrochers (slashd)]

I'll do my best to provide a test kernel by tomorrow, for impacted user to test, and confirm it works before I submit it to the Ubuntu kernel team.

Stay tuned.

[Eric Desrochers (slashd)]

I have applied the good fix on top of current branch 4.15.0-53.57

---
c6d53184e8b8 drm/vmwgfx: Send the correct nonblock option for atomic_commit
c78b765c2de0 UBUNTU: Ubuntu-4.15.0-53.57
---

Build the kernel and I got the same problem still. Need to investigate why it works fine using upstream when that good commit but still get the situation with Ubuntu kernel + the same good commit.

I'll do more testing.

[Eric Desrochers (slashd)]

This commit has most likely other 'drm/vmwgfx' commit deps. I'll work at finding what other bits are missing.

[Eric Desrochers (slashd)]

It's working if I apply the whole chain of commit on top of Ubuntu-4.15

I'll need to talk with kernel team and see if this is feasible for an SRU.

52a59da2c439 drm/vmwgfx: Send the correct nonblock option for atomic_commit
cfffdaad3db9 drm/vmwgfx: Move the stdu vblank event to atomic function
b8d2ffa1798c drm/vmwgfx: Move screen object page flip to atomic function
3e67818b5a0e drm/vmwgfx: Remove drm_crtc_arm_vblank_event from atomic flush
700b155d6492 drm/vmwgfx: Move surface copy cmd to atomic function
4c7224123ecf drm/vmwgfx: Avoid iterating over display unit if crtc is available
c78b765c2de0 UBUNTU: Ubuntu-4.15.0-53.57

https://www.spinics.net/lists/dri-devel/msg162472.html

[Eric Desrochers (slashd)]

My test kernel can be found here, if one want to test:

sudo add-apt-repository ppa:slashd/kernel-builder
sudo apt-get update

version: 4.15.0-53.57+hf231164v20190618b9

[MinSoon Park (pineful)]

I successully applied your latest patch above and it was fixed!
Thank you so much!

[Pat (pat-h)]

Great work Eric!
I installed your kernel build and it seems to work.

As confirmation of the kernel build level, here is uname -a output immediately after install & reboot.

uname -a
Linux ubuntuvm1 4.15.0-53-generic #57+hf231164v20190618b9-Ubuntu SMP Tue Jun 18 20:11:42 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[Pat (pat-h)]

As a side-effect, I've noticed that display resizing doesn't work the same.
I'm unable to resize the display to anything more than 1176 x 885 (4:3)

[Eric Desrochers (slashd)]

Do you have the same display resizing situation with the hwe kernel 4.18 ?

[Pat (pat-h)]

Display resizing works as expected on the hwe 4.18 kernel

[Pat (pat-h)]

Daniel,
I didn't want to lose sight of your ask in comment #34.
I updated to the latest mainstream kernel, and then reverted the mutter packages (as per comment #31).
That also fixes the problem.

Specifically, this configuration is working for me;

uname -a

Linux ubuntuvm1 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

sudo dpkg --list | grep mutter

ii gir1.2-mutter-2:amd64 3.28.3+git20190124-0ubuntu18.04.2 amd64 GObject introspection data for Mutter
ii libmutter-2-0:amd64 3.28.3+git20190124-0ubuntu18.04.2 amd64 window manager library from the Mutter window manager
ii mutter 3.28.3+git20190124-0ubuntu18.04.2 amd64 lightweight GTK+ window manager
ii mutter-common 3.28.3+git20190124-0ubuntu18.04.2 all shared files for the Mutter window manager

And display resizing also works as expected.

[Daniel van Vugt (vanvugt)]

Thanks Pat.

That seems to confirm the 'regression-update' tag here. Although I wouldn't be able to debug and fix the mutter change because I can't reproduce the bug, using VMware. Mine just works :/

It sounds like good progress is being made in the kernel anyway. So I think a fix there would be preferable. Otherwise I would just be hunting for a way to cripple mutter to work around apparent VMware driver bugs.

[Daniel van Vugt (vanvugt)]

Card archived: https://trello.com/c/gn0J5Qgb

[Eric Desrochers (slashd)]

The patchset is significant already without knowing yet what is missing to address the side-effect.
I would need kernel team review/approval before thinking to SRU this into Ubuntu 4.15.

I can't SRU this as-is, now knowing this will introduce a regression.

I'll keep you guys posted.

- Eric

[Eric Desrochers (slashd)]

Daniel van Vugt (vanvugt),

Do you know what change could have introduced this vmwgfx/wayland interaction problem inside mutter in the first place ?

I have strong believe, that something userspace has been changed and no longer interact well with the vmware driver since then.

Just to look at our option (since a kernel fix might be not end up being trivial) does a revert of the change could be a possibility here ? or else.

Ideally, I agree I would have prefer to fix the kernel and I'm also going to pursue that direction, but just looking other avenues in case of ...

Thanks

- Eric

[Eric Desrochers (slashd)]

or if we identify the offending userspace change, then we can look at the kernel again with and try to find what bit are missing, and if we limit the kernel change then maybe the side-effect might not be present again. (assumption here)

I think the next step is really to find what userspace change started all this so we can related kernel known fix to be part of the final backport (without doing that massive 6 commits backport, which as a side-effect and who know what else).

[Eric Desrochers (slashd)]

as an fyi ...

It has been brought to my attention that this could impact other system (outside vmware context)
so I still suspect a userspace change (possibly mutter) that introduce behaviour change and break the interaction with certain part of the 4.15 kernel.

Do we know if the recent point release has been tested with different kernel series ? 4.15, 4.18, ... or only 4.18 ?

[Eric Desrochers (slashd)]

To continue on my comment #59 ... One user has been impacted on a physical machine (non-vmware) with the same symptom but can't provide public details unfortunately, but I witnessed the problem from my own eye via remote session, and again upgrading to 4.18 kernel did the trick.

So it really seems like 4.15 is possibly incompatible at some point with the current mutter package. That is my believe with the level of details that I know for now and what has been shared to me.

Daniel, any thoughts on this ?
I will try to contact you on irc tonight if we can manage to fight the TZ gap between us. ;)

[Daniel van Vugt (vanvugt)]

> Do you know what change could have introduced this vmwgfx/wayland interaction problem inside mutter in the first place ?

Technically it was a whole point release. The trigger could be any change that went into mutter 3.28.4 as well as any Ubuntu patch. As mentioned in comment #31, my suspicion is this specific change: https://gitlab.gnome.org/GNOME/mutter/commit/e9e4b2b72

> Just to look at our option (since a kernel fix might be not end up being trivial) does a revert of the change could be a possibility here ?

If the issue turns out to be commit e9e4b2b72 above then no. Because too many people benefit vs the possible number of people affected by this bug. But we also aren't completely sure that's the relevant mutter commit.

If only I could reproduce this bug I could probably write a workaround (or fix) for it in mutter.

[Eric Desrochers (slashd)]

My reproducer:

1) I used virtualbox 6.0.0 on disco (my desktop machine) # I guess it doesn't really matter but I prefer giving more details than less ;)
2) Deploy a VM with Ubuntu 18.04.1 (which come w/ 4.15)
3) Make sure in the VM setting that the display uses 'VMSVGA' which will force the OS to pick 'vmwgfx' video kernel driver. (you can confirm with 'lspci -nnvv' command.
4) apt-get dist-upgrade

Then reboot and the login screen won't be shown again using v4.15 kernel.
Switch to 4.18 will work.

Regards,
Eric

[Daniel Gutierrez (dgutierr)]

Because it was mentioned in comment #15 & #34 that this bug cannot be reproduced, I decided to create a VMWare VM from scratch which managed to be affected on my first attempt.

I started with ubuntu-18.04.1-desktop-amd64.iso (19e10acddd14af9a9150399d876b02933c0ee724) and created a snapshot with all the live packages, as of today (06/19/2019), except for the 4 I noted in comment #28. Simply start the VM, update the out of date packages via the internet or via the provided copies of the deb files on the desktop, and reboot to reproduce the bug (infinite UI hang before login).

Bug1832138VM.zip (3fd83148ebeceacd48bca7b9f02c1d714c9391ca)
Download from: https://pride-rock-labs.com/Bug1832138VM.zip
VM Credentials: vmuser | vmpassword

I made this VM under near identical conditions to the original poster (Pat). This means I now have reproduced the issue under ESXi and Fusion.

[Daniel van Vugt (vanvugt)]

It also sounds like VirtualBox might allow me to reproduce the bug...

[Daniel van Vugt (vanvugt)]

Using VirtualBox 6 and VMSVGA as recommended by Eric I still can't reproduce the bug. But I think I can see why now: Ubuntu 18.04.2 comes with kernel 4.18

Let me try 18.04.1...

[Chance Gana (gananator89)]

I can reproduce this bug by creating a guest OS using a 18.04.1 .iso I downloaded last year and attempting to update.
I created another guest OS using the 18.04.2 .iso I downloaded yesterday works fine after updating.

[Daniel van Vugt (vanvugt)]

It seems I stumbled on a workaround. Just install the kernel that comes in the 18.04.2 ISO:

https://launchpad.net/ubuntu/+source/linux-hwe

[Daniel van Vugt (vanvugt)]

I am now able to reproduce and debug the problem. Indeed it is what I said in comment #31.

The vmwgfx driver in this old kernel is telling lies. It says the next screen refresh is in 49 years from now. It should be within 16.6 milliseconds.

[Daniel van Vugt (vanvugt)]

And the problem is indeed the kernel advertising DRM_CAP_TIMESTAMP_MONOTONIC but instead of using CLOCK_MONOTONIC it is really using CLOCK_REALTIME. This confirms kernel commit 37efe80ce85f is the fix, but it may well have some prerequisite commits we haven't fully worked out...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc5&id=37efe80ce85f

I'll see if I can hack around it, but the simplicity of the mistake in the vmwgfx kernel code makes me think we should be preferring a kernel fix still.

[Daniel van Vugt (vanvugt)]

Workaround for mutter proposed here:

https://code.launchpad.net/~vanvugt/ubuntu/+source/mutter/+git/mutter/+merge/369083

[Eric Desrochers (slashd)]

Will also build a kernel 4.15 with 37efe80ce85f and see the outcome. Should be able to provide an update by EOD.

[Eric Desrochers (slashd)]

I already did that test ^ using the upstream kernel with 37efe80ce85f being the HEAD, but "37efe80ce85f" - 1 was working as well, so I didn't continue to pursue that commit, since it wasn't the first introduction of the fix.

But based on last duflu update, I as I said I will now give a try again but this time using Ubuntu kernel as follow:

9c5f23a4a699 drm/vmwgfx: use monotonic event timestamps
c78b765c2de0 UBUNTU: Ubuntu-4.15.0-53.57

Let's see what will be the outcome in a couple of hours.

[Eric Desrochers (slashd)]

After building and testing:

"
9c5f23a4a699 drm/vmwgfx: use monotonic event timestamps
c78b765c2de0 UBUNTU: Ubuntu-4.15.0-53.57
"

the above seems to do the trick ^ which will make the SRU easier (only one commit).
I just don't know why the kernel git bisect testing found another commit, but anyway.

Anybody impacted want to test this testpkg to double-check before I submit the patch to the kernel team ?

sudo add-apt-repository ppa:slashd/kernel-builder
sudo apt-get update

Version: 4.15.0-53.57+hf231164v20190620b11

[Daniel Gutierrez (dgutierr)]

Here is the last of the output after running the first test repo update command in comment #73 on the Bug1832138VM.zip VM I built.

I'm guessing either there is an integrity issue upstream or more likely there is a missing step so that a system that has been using the default repo settings is superseded by the test repo for the updated package(s). If I ignore these errors and upgrade after update I get the 49 year hang on reboot.

E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/bionic-updates/main/binary-i386/Packages.xz File has unexpected size (543836 != 543620). Mirror sync in progress? [IP: 91.189.91.23 80]
   Hashes of expected file:
    - Filesize:543620 [weak]
    - SHA256:3b6cc1e3be5322bc0c88e8dbeecee75d75ed68460ef281d94e9d59ed432224bb
    - SHA1:022b402b91b0d22d1e2c321c2417c875a2ee8428 [weak]
    - MD5Sum:a3e4b55f39d2645601f31ea6835092ad [weak]
   Release file created at: Thu, 20 Jun 2019 17:41:04 +0000
E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/bionic-updates/universe/binary-amd64/Packages.xz
E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/bionic-updates/universe/dep11/icons-64x64.tar.gz
E: Some index files failed to download. They have been ignored, or old ones used instead.

[Eric Desrochers (slashd)]

Detailled instructions on how to use my ppa :

$ sudo add-apt-repository ppa:slashd/kernel-builder
$ sudo apt-get update
$ sudo apt install linux-image-unsigned-4.15.0-53-generic linux-modules-4.15.0-53-generic linux-modules-extra-4.15.0-53-generic

then reboot, and once login you can confirm if you run my test kernel with "uname -a" which should report "4.15.0-53.57+hf231164v20190620b11"

[Pat (pat-h)]

Eric,
your new test kernel works for... and screen-resizing works this time too.

To confirm, I am running the correct kernel build;

uname -a

Linux ubuntuvm1 4.15.0-53-generic #57+hf231164v20190620b11-Ubuntu SMP Thu Jun 20 13:18:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[Eric Desrochers (slashd)]

Great for the quick feedback.

I have until June 26th to submit the patch for the next cycle[0]

It's giving me a couple of more days to get other impacted users feedback.

[0] - https://kernel.ubuntu.com/

- Eric

[Gary Filipski (gfilipski)]

Additional confirmation...

Working under VMware Workstation v12.5.7 running kernel 4.15.0.52:

Having performed the workaround of uncommenting the WaylandEnable=false...

   - Re-commented the line & rebooted to experience the hang with the Ubuntu logo before the login screen

   - Using your ppa, installed the test kernel.

   - Rebooted.

Login proceeded normally: Linux linuxTest 4.15.0-53-generic #57+hf231164v20190620b11-Ubuntu SMP Thu Jun 20 13:18:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Thank you!

[Daniel Gutierrez (dgutierr)]

Additional confirmation...

Looks like this updated kernel fixes the issue on the affected test VM I created.

Using the detailed directions in comment #75, I was able to install the new test kernel and reboot.

Verified the expected version value with uname and then installed the packages that were previously hanging from the copies I archived with the test VM and rebooted.

Login showed up and functioned as normal. This appears to be the ideal fix.

[Eric Desrochers (slashd)]

Ok, including my own testing we got 4 positive feedback.
With that being said, I have just submitted the patch to our kernel team a few minutes ago.

This will be part of the next cycle 01-July through 21-July.

Thanks for the pre-SRU testing, we will need you guys one more time during the testing phase of bionic-proposed in a couple of weeks.

- Eric

[Eric Desrochers (slashd)]

kernel-team archive ML:
https://lists.ubuntu.com/archives/kernel-team/2019-June/101489.html

[Todd Short (tmshort)]

I am running into the same situation:

Running Ubuntu 18.04 in VMWare Fusion 10.1.6 on macOS 10.14.5

After I updated I received the 4.15.0-52-geeneric kernel, and the login screen no longer shows. I was able to successfully use the workaround "WaylandEnable=false" to get it to show.

[Eric Desrochers (slashd)]

Todd, The fix will land in the next kernel cycle.

[Eric Desrochers (slashd)]

Just got the 2 required ACK from kernel team for the patch I have submitted.
Everything looks good for the patch to be part of the next kernel cycle as described in previous comment.

- Eric

[Eric Desrochers (slashd)]

The testing phase where the kernel will land in bionic-proposed pocket is due around :
08-Jul - 19-Jul Bug verification & Regression testing

This is where I'll need you guys to test the proposed kernel and confirm it still work as expected for you.

- Eric

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Daniel Gutierrez (dgutierr)]

bionic-proposed confirmation:

I have tested the updates in bionic-proposed with the VM I created for this bug as described in comment #63 and can confirm this, like the test in comment #75, also resolves the issue.

The login screen appears as expected after reboot (with kernel and updated packages for gir1.2-mutter-2, gnome-shell, gnome-shell-common, & libmutter-2-0).

uname -a before:
Linux test-vm 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

uname -a after:
Linux test-vm 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[Pat (pat-h)]

I have also tested the updated kernel from bionic-proposed using the VM in which the original problem was first experienced.

'uname -a' after adding bionic-proposed to /etc/apt/sources.list and doing 'sudo apt update; sudo apt upgrade'

Linux ubuntuvm1 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Like Daniel, the changes incorporated into 4.15.0-55 are working for me as well.

[Gary Filipski (gfilipski)]

Tested bionic-proposed with both original VM that exhibited the problem on upgrade and a separate VM used to test the work-around (uncommenting WaylandEnable=false in /etc/gdm3/custom.conf).

Both VMs upgraded and ran successfully using https://wiki.ubuntu.com/Testing/EnableProposed.

-----------------------------------------------------------------------------

# First test w/older VM that first exhibited the problem...

# [ No network card present ]
# Booted from old, saved VM where update first screwed up:

    $ uname -a
    Linux linuxTest 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# Added bionic-proposed repository in update / developer options
# [ Enabled network card for VM ]
# Updated to current; restarted
# Booted & logged in normally

    $ uname -a
    Linux linuxTest 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

# Yea!

-----------------------------------------------------------------------------

# Second test with VM used for later testing of the problem...

# [ No network card present ]
# Re-tested with more recent problem VM...
# Removed fix in /etc/gdm3/custom.conf (re-commented WaylandEnable=false)
# Booted to watch login hang
# {Shift} boot w/Grub in recovery mode to recovery mode menu; resumed startup.
# Logged in (desktop @800x600); re-set desktop width

    $ uname -a
    Linux Linux linuxTest 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

# Added bionic-proposed repository in update / developer options
# [ Enabled network card for VM ]
# Updated to current; restarted
# Booted & logged in normally

    $ uname -a
    Linux linuxTest 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

# Yea!

-----------------------------------------------------------------------------

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.15.0-55.60

---------------
linux (4.15.0-55.60) bionic; urgency=medium

  * linux: 4.15.0-55.60 -proposed tracker (LP: #1834954)

  * Request backport of ceph commits into bionic (LP: #1834235)
    - ceph: use atomic_t for ceph_inode_info::i_shared_gen
    - ceph: define argument structure for handle_cap_grant
    - ceph: flush pending works before shutdown super
    - ceph: send cap releases more aggressively
    - ceph: single workqueue for inode related works
    - ceph: avoid dereferencing invalid pointer during cached readdir
    - ceph: quota: add initial infrastructure to support cephfs quotas
    - ceph: quota: support for ceph.quota.max_files
    - ceph: quota: don't allow cross-quota renames
    - ceph: fix root quota realm check
    - ceph: quota: support for ceph.quota.max_bytes
    - ceph: quota: update MDS when max_bytes is approaching
    - ceph: quota: add counter for snaprealms with quota
    - ceph: avoid iput_final() while holding mutex or in dispatch thread

  * QCA9377 isn't being recognized sometimes (LP: #1757218)
    - SAUCE: USB: Disable USB2 LPM at shutdown

  * hns: fix ICMP6 neighbor solicitation messages discard problem (LP: #1833140)
    - net: hns: fix ICMP6 neighbor solicitation messages discard problem
    - net: hns: fix unsigned comparison to less than zero

  * Fix occasional boot time crash in hns driver (LP: #1833138)
    - net: hns: Fix probabilistic memory overwrite when HNS driver initialized

  * use-after-free in hns_nic_net_xmit_hw (LP: #1833136)
    - net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw()

  * hns: attempt to restart autoneg when disabled should report error
    (LP: #1833147)
    - net: hns: Restart autoneg need return failed when autoneg off

  * systemd 237-3ubuntu10.14 ADT test failure on Bionic ppc64el (test-seccomp)
    (LP: #1821625)
    - powerpc: sys_pkey_alloc() and sys_pkey_free() system calls
    - powerpc: sys_pkey_mprotect() system call

  * [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different
    (LP: #1832625)
    - pkey: Indicate old mkvp only if old and current mkvp are different

  * [UBUNTU] kernel: Fix gcm-aes-s390 wrong scatter-gather list processing
    (LP: #1832623)
    - s390/crypto: fix gcm-aes-s390 selftest failures

  * System crashes on hot adding a core with drmgr command (4.15.0-48-generic)
    (LP: #1833716)
    - powerpc/numa: improve control of topology updates
    - powerpc/numa: document topology_updates_enabled, disable by default

  * Kernel modules generated incorrectly when system is localized to a non-
    English language (LP: #1828084)
    - scripts: override locale from environment when running recordmcount.pl

  * [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
    (LP: #1832624)
    - s390/zcrypt: Fix wrong dispatching for control domain CPRBs

  * CVE-2019-11815
    - net: rds: force to destroy connection if t_sock is NULL in
      rds_tcp_kill_sock().

  * Sound device not detected after resume from hibernate (LP: #1826868)
    - drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
    - drm/i915: Save the old CDCLK atomic state
...

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Daniel van Vugt (vanvugt)]

1. It appears nobody requested this fix for xenial so I wouldn't expect anyone interested in testing it.

2. I can't see the bug ID documented in any proposed xenial kernel.