Also repro'd same issue on Samus after suspend/resume

https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/631268

sdantuluri@ can you confirm it repros on today's build 8530.30.0?

Issue repros on today's build 8530.30.0 samus

abodeti@ does the cursor stay in this bad state forever or does it come back to normal?

Its come back to normal after reboot the device.

ok in that case this is def not an RBB. Marking this RBS.

@ketakid -This issue always reproduced with suspend Resume. The user have to reboot to fix the cursor issue.  Its bad user experience .

+Rohit

This is bad. Should this be a beta blocker?

Yeah. Darnit. If it's that easy to repro and requires a reboot to fix I think we need to hold beta. :-(

Since we're in the middle of trying to get beta out that makes this a Pri-0. :-(

Start looking into it now.

Not able to repro on TOT. Does the issue only exist in M53?

Yes,Its on M53 build

Great. So there's some fix that made it into 54 that we need to find and merge to 53.

 Issue 631796  has been merged into this issue.

What version? seeing this on:

Version 54.0.2806.0 canary (64-bit)
Platform 8636.0.0 

xiaoyinh@ what device did you try on? So far this has only been reported on samus and auron_paine.  So maybe just broadwell devices?

Adding a few other people for thoughts.

RE20: I'm using toshiba chromebook 2(gandof), maybe I didn't do it correctly, Let me try one more time on TOT.

Issue also repro'd on minnie, cyan, peppy 8530.30.0

Happened on samus after I got 53.0.2785.29 dev.  I wonder if this is caused by a CL merged for  crbug.com/618597 ?

kanliu@ zelidrag@ and tbuckley@ all reported this to me since last night.

It also occurs to me that with these symptoms we may be looking at a buffer overrun or other security affecting pointer misbehavior. :-(

@20: the original report is on peppy, so it's not only broadwell...

I'm able to repro it on TOT now. Probably I didn't configure something right yesterday...

+ozone follks

Seeing these logs in ui.LATESET, is it related to driver?

minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1) error -1
[19268:19274:0727/093018:ERROR:crtc_controller.cc(156)] drmModeSetCursor: device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc 20 handle 7 size 256x256: No such file or directory
[19268:19274:0727/093018:ERROR:crtc_controller.cc(156)] drmModeSetCursor: device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc 20 handle 7 size 256x256: No such file or directory
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=3) error -1
[19268:19274:0727/093018:ERROR:crtc_controller.cc(156)] drmModeSetCursor: device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc 20 handle 7 size 256x256: No such file or directory
[19268:19274:0727/093018:ERROR:crtc_controller.cc(156)] drmModeSetCursor: device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc 20 handle 7 size 256x256: No such file or directory
[19268:19274:0727/093018:ERROR:crtc_controller.cc(156)] drmModeSetCursor: device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc 20 handle 7 size 256x256: No such file or directory
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=20) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=3) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=2) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=8) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=a) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=5) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=6) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=4) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=7) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=b) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=c) error -1
[19268:19274:0727/093021:ERROR:crtc_controller.cc(156)] drmModeSetCursor: device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc 20 handle 7 size 256x256: No such file or directory
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=d) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=2) error -1
[19268:19274:0727/093022:ERROR:crtc_controller.cc(156)] drmModeSetCursor: device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc 20 handle 7 size 256x256: No such file or directory
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=7) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=f) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=10) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=7) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=5) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=c) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=a) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=2) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=d) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1e) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=2) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=2) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1f) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1d) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=8) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=6) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1c) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=19) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=16) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=13) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1a) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=4) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=3) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=17) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1b) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=20) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=8) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=1) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=2) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=5) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=6) error -1
minigbm: DRM_IOCTL_GEM_CLOSE failed (handle=7) error -1

@28: this is the kernel complaining that user space is doing something funny...

can be this ? https://codereview.chromium.org/2178563002

+reveman@

Could be, usually this means there is an issue on the Chrome side around the lifetime of buffers...

The drmModeSetCursor errors definitely look related. Maybe the DrmBuffers used for cursor overlays are somehow closed too early. That would explain the DRM_IOCTL_GEM_CLOSE errors too.

Ozone HW cursors should not be affected by https://codereview.chromium.org/2178563002 and buffer import changes as the allocation of buffers for HW cursors doesn't exercise that code.

Is this easy enough to reproduce that we can do a bisect?

Re 30: I can still see the issue after I reverted the CL in question.
To rule out the problem on OS side, I'm installing the working 53 image, and then deploy 54 chrome code to see if you can still repro.

Those error messages remind me of the subtle semantics of the kernel API for buffer import - if one dmabuf is imported twice, the 2nd import will just return the existing handle. So destroying either imported buffer will destroy both of them, and operation on the "other" becomes a use-after-close.
 
So, do we ever import the same buffer twice? We didn't used to, but since recently we're passing buffers by handle extensively and I would not be surprised if we missed this subtlety (again).

If we can import the same buffer twice, does gbm_bo_import() keep userspace refcounts for DRM handles? Otherwise it is probably broken.

The issue seems to go away after I revert 4621081d1ffdc8a9048430f7c3d2e60cc0e309cd


reveman@, Could you take a look? https://codereview.chromium.org/2171213003

Ah, makes sense. That's causing us to close GEM handles twice. Once for the buffer allocated and once for the import.

 Issue 632145  has been merged into this issue.

Here's a potential fix: https://codereview.chromium.org/2188893002

I'm not seeing those DRM_IOCTL_GEM_CLOSE errors with that change and the cursor seems fine so far.

Still not sure why this caused these cursor issues. These GEM handles being closed too early should only be a problem if a UI compositor context was destroyed without the GPU process being restarted and should be affecting scanout buffers and not the buffers used for cursors.

Could we merge this to 53 as soon as it lands?

We're trying to get a beta RC right now. This is the last bit holding it up.

The risk of course is that if this doesn't really fix the problem or breaks something else we risk further delaying beta, but that risk is pretty much the same either way at this point.

Thoughts?

Save to remove Restrict-View on this?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/770b48e9e2c1e9d47b0c2a02c767a370b0adb3da

commit 770b48e9e2c1e9d47b0c2a02c767a370b0adb3da
Author: reveman <reveman@chromium.org>
Date: Wed Jul 27 23:17:36 2016

gpu: Avoid creating two native pixmaps for the same buffer.

For buffers allocated using CreateGpuMemoryBuffer, avoid
creating a second native pixmap for the same buffer as that
results in the associated GEM handle being closed twice.

BUG= 631268 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2188893002
Cr-Commit-Position: refs/heads/master@{#408268}

[modify] https://crrev.com/770b48e9e2c1e9d47b0c2a02c767a370b0adb3da/gpu/ipc/service/gpu_memory_buffer_factory_ozone_native_pixmap.cc

 Issue 632134  has been merged into this issue.

govind@ can you please approve? This change has not been vetted on ToT but is critical enough that we cannot ship beta without it. 

Approving merge to M53 cros.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/884189216f6a41a4bd49c43fe569a01b800150df

commit 884189216f6a41a4bd49c43fe569a01b800150df
Author: David Reveman <reveman@chromium.org>
Date: Wed Jul 27 23:44:36 2016

gpu: Avoid creating two native pixmaps for the same buffer.

For buffers allocated using CreateGpuMemoryBuffer, avoid
creating a second native pixmap for the same buffer as that
results in the associated GEM handle being closed twice.

BUG= 631268 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2188893002
Cr-Commit-Position: refs/heads/master@{#408268}
(cherry picked from commit 770b48e9e2c1e9d47b0c2a02c767a370b0adb3da)

Review URL: https://codereview.chromium.org/2185153003 .

Cr-Commit-Position: refs/branch-heads/2785@{#380}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/884189216f6a41a4bd49c43fe569a01b800150df/gpu/ipc/service/gpu_memory_buffer_factory_ozone_native_pixmap.cc

 Issue 632240  has been merged into this issue.

I see this on Pixel 2 as well.

FYI, the fix that landed caused another problem: crbug.com/632375

Oooof. :-( thanks for the heads up.

Verified on ChromeOS 8530.35.0/53.0.2785.36 samus.

Thanks for verifying abodeti@.

 Issue 632847  has been merged into this issue.