+ihf@ - We do seem to have had a lot of these lately, we should investigate this.

In another security_NetworkListeners Failure also seen chrome crash, and large number stream of similar messages:
[1:5:0824/033159:ERROR:client_native_pixmap_dmabuf.cc(52)] Failed DMA_BUF_SYNC_END: Invalid argument
[1160:1508:0824/033201:ERROR:client_native_pixmap_dmabuf.cc(52)] Failed DMA_BUF_SYNC_END: Invalid argument

See in the crash log.
https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/74265628-chromeos-test/chromeos2-row4-rack5-host7/

falco-chrome-pfq bot has been failing very frequently in recent runs.
https://uberchromegw.corp.google.com/i/chromeos/builders/falco-chrome-pfq

Although it failed for different bvt test each time, I found chrome crashed during tests, and the chrome log shows similar messages in large amount:
[1170:1170:0826/061716:VERBOSE1:gaia_screen_handler.cc(392)] OnPortalDetectionCompleted Online
[1:5:0826/061717:ERROR:client_native_pixmap_dmabuf.cc(52)] Failed DMA_BUF_SYNC_END: Invalid argument

"Failed DMA_BUF_SYNC_END" looks really familiar, I'm not sure if it's related to the crash. Tiago, can you shed some light on this error message?

Is this the same issue as 639165?

IIUC this indicates that we're actually failing to Unmap() pixmaps, which seems alarming.

> IIUC this indicates that we're actually failing to Unmap() pixmaps, which seems alarming.

Im not sure what pixmaps you're referring to here or why the Internals>Compositing label. Can you explain?

Don't think this is Internals>Compositing bug.

Also seems it's been a while, anybody has update on this?

@20: are you saying that this bug is fixed? If so what was the correlation?

Assigning to Dongseong for a reply

Dup of issue 629521?

Dongseong can you reply here?

it's temporarily fixed in issue 629521

It is not fixed, it stoped happening because we disabled GMBs.

Now you want to reenable them for video but before that, you should understand the crash. Let me state very clearly that we are not going to reenable GMBs until this crash is understood.

#26 - indeed, I'm trying to make stress test now to reproduce it, because any engineers don't have reproduced it using chrome os test image yet.

anyway, it's duplicated to issue 629521, isn't it?

Ah, issue 629521 is crash issue, and it's unmap failure issue.

I think it's fixed by https://codereview.chromium.org/2297783006
because we didn't see the same error after Sep/2016.

The CL author said sync_start and sync_end have to have same flag, and "Invalid argument" error meet his explanation.

If same err msg is reported again, please re-open it.

it is still there for Haswell. Let me fix it.

https://chromium-review.googlesource.com/c/490886/ will fix it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9224061c1db35d114d4dfb8aaf12101c914469cd

commit 9224061c1db35d114d4dfb8aaf12101c914469cd
Author: Dongseong Hwang <dongseong.hwang@intel.com>
Date: Tue May 23 10:03:15 2017

BACKPORT: drm/i915: Broaden application of set-domain(GTT)

Previously, this was restricted to only operate on bound objects - to
make pointer access through the GTT to the object coherent with writes
to and from the GPU. A second usecase is drm_intel_bo_wait_rendering()
which at present does not function unless the object also happens to
be bound into the GGTT (on current systems that is becoming increasingly
rare, especially for the typical requests from mesa). A third usecase is
a future patch wishing to extend the coverage of the GTT domain to
include objects not bound into the GGTT but still in its coherent cache
domain. For the latter pair of requests, we need to operate on the
object regardless of its bind state.

v2: After discussion with Akash, we came to the conclusion that the
get-pages was required in order for accurate domain tracking in the
corner cases (like the shrinker) and also useful for ensuring memory
coherency with earlier cached CPU mmaps in case userspace uses exotic
cache bypass (non-temporal) instructions.

v3: Fix the inactive object check.

v4: Rebase to latest drm-intel-nightly codebase

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 43566dedde54f9729113f5f9fde77d53e75e61e9)

[Conflicts] This backport doesn't care of GGTT, because v3.8 doesn't have any
code about GGTT.

BUG= chromium:641392 
TEST=./mapped_texture_test in drm-tests on peppy

Change-Id: I31e4c6b3303f8502fc0a2607ff262fe49c84162c
Reviewed-on: https://chromium-review.googlesource.com/490886
Commit-Ready: Dongseong Hwang <dongseong.hwang@intel.com>
Tested-by: Dongseong Hwang <dongseong.hwang@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Dongseong Hwang <dongseong.hwang@intel.com>

[modify] https://crrev.com/9224061c1db35d114d4dfb8aaf12101c914469cd/drivers/gpu/drm/i915/i915_gem.c

now v3.8, v3.14, v3.18, v4.4 code is consistent with regards to this issue.
However, I didn't apply it to v3.10 because we never enable native GMB on v3.10, which only baytrail used and baytrail moved v4.4.

Stéphane, do you think we need to apply it to v3.10?

Closing. Please reopen it if its not fixed. Thanks!