Project

General

Profile

Bug #3171

mesa-libs 18.3.2 not working

Added by tuxillo 4 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Driver
Target version:
Start date:
02/10/2019
Due date:
% Done:

100%

Estimated time:
10.00 h

Description

mesa-libs 18.3.2 from dports is not working as expected. This is the latest mesa-libs package in dports as of today.
The latest known version to be working is mesa-libs 18.1.9_4.

User is in 'video' group as to be expected.

# uid=2000(antonioh) gid=2000(antonioh) groups=2000(antonioh), 0(wheel), 44(video), 85(vknet)

The error can be triggered by running 'glxgears', 'glxinfo', ...

# glxinfo
name of display: :2
i965: Failed to submit batchbuffer: Invalid argument

Further debugging:

To enable FIOCTL and IOCTL debugging messages in DRM:

# sysctl hw.drm.debug=0x0f0f
hw.drm.debug: 3855

---- dmesg exceprt ----
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=0, DRM_IOCTL_GET_MAGIC
[drm:pid117659:drm_getmagic] 67
[drm:pid1474:drm_ioctl] pid=1474, dev=0xfffff80076311bc8, auth=1, DRM_IOCTL_AUTH_MAGIC
[drm:pid1474:drm_authmagic] 67
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, DRM_IOCTL_VERSION
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, DRM_IOCTL_VERSION
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GEM_CONTEXT_GETPARAM
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:i915_getparam] Unknown parameter 30
[drm:pid117659:drm_ioctl] ret = 22
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:i915_getparam] Unknown parameter 40
[drm:pid117659:drm_ioctl] ret = 22
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GEM_GET_APERTURE
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GEM_CREATE
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GEM_SET_TILING
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GEM_SET_DOMAIN
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, DRM_IOCTL_GEM_CLOSE
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_REG_READ
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:i915_getparam] Unknown parameter 45
[drm:pid117659:drm_ioctl] ret = 22
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:i915_getparam] Unknown parameter 48
[drm:pid117659:drm_ioctl] ret = 22
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:i915_getparam] Unknown parameter 50
[drm:pid117659:drm_ioctl] ret = 22
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GET_RESET_STATS
[drm:pid117659:drm_ioctl] ret = 1
[drm:pid1474:drm_ioctl] pid=1474, dev=0xfffff80076311bc8, auth=1, I915_GEM_THROTTLE
[drm:pid117659:drm_ioctl] pid=117659, dev=0xfffff80076311bc8, auth=1, I915_GETPARAM
[drm:pid117659:i915_getparam] Unknown parameter 44
[drm:pid117659:drm_ioctl] ret = 22

Also attached the glxinfo.log which is the output of:

# env INTEL_DEBUG=bat glxinfo
[...]

glxinfo.log (13.3 KB) glxinfo.log glxinfo batch debug info tuxillo, 02/10/2019 09:12 AM

History

#1 Updated by tuxillo 4 months ago

  • Status changed from New to In Progress

After some kprintf'ing, the EINVAL comes from:

sys/dev/drm/i915/i915_gem_execbuffer.c:1025


1021 /* Offset can be used as input (EXEC_OBJECT_PINNED), reject
1022 * any non-page-aligned or non-canonical addresses.
1023 */
1024 if (exec[i].flags & EXEC_OBJECT_PINNED) {
1025 if (exec[i].offset !=
1026 gen8_canonical_addr(exec[i].offset & PAGE_MASK))
1027 return -EINVAL;

#2 Updated by ftigeot 4 months ago

The new behavior is caused by this mesa commit present between mesa-18.1.9 and mesa-18.2.0 :

commit a363bb2cd0e2a141f2c60be005009703bffcbe4e (HEAD, refs/bisect/bad)
Author: Kenneth Graunke <>
Date: Tue Apr 10 01:18:25 2018 -0700

i965: Allocate VMA in userspace for full-PPGTT systems.

This patch enables soft-pinning of all buffers, allowing us to skip
relocation processing entirely. All systems with full PPGTT and > 4GB
of VMA should gain these benefits. This should be most Gen8+.

Unfortunately, this excludes a few systems:
- Cherryview (only has 32-bit addressing, despite 48-bit pointers)
- Broadwell with a 32-bit kernel
- Anybody running pre-4.5 kernel.

We may enable it for Cherryview in the future, but it would require
some tweaks to the memory zone.

Reviewed-by: Jordan Justen <>

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 121e952b9ed..b5e3eb6bff9 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -1724,7 +1724,7 @@ brw_bufmgr_init(struct gen_device_info *devinfo, int fd)
bufmgr->initial_kflags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;

/* Allocate VMA in userspace if we have softpin and full PPGTT. */
- if (false && gem_param(fd, I915_PARAM_HAS_EXEC_SOFTPIN) > 0 &&
+ if (gem_param(fd, I915_PARAM_HAS_EXEC_SOFTPIN) > 0 &&
gem_param(fd, I915_PARAM_HAS_ALIASING_PPGTT) > 1) {
bufmgr->initial_kflags |= EXEC_OBJECT_PINNED;

#3 Updated by tuxillo 4 months ago

Hi,

In Mesa commit a363bb2cd they enable unconditionally the soft-pinning feature[1] for all buffers in systems that report having support for both soft-pinning and full PPGTT [2].
DragonFly BSD reports supporting I915_PARAM_HAS_EXEC_SOFTPIN. For Graphics Gen 7 or higher, I915_PARAM_HAS_ALIASING_PPGTT is reported as supported.

With this feature enabled, the condition in 'sys/dev/drm/i915/i915_gem_execbuffer.c:1025' is now checked and fails, that's why the EINVAL is returned to userland.

According to ftigeot's comments in the IRC, PAGE_MASK is defined differently in Linux and in DragonFly:

Linux: #define PAGE_MASK (~(PAGE_SIZE-1))
DragonFly: #define PAGE_MASK (PAGE_SIZE-1)

----
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
[2] https://bwidawsk.net/blog/index.php/2014/07/true-ppgtt-part-3/

#4 Updated by tuxillo 4 months ago

  • Status changed from In Progress to Closed
  • Assignee set to ftigeot
  • % Done changed from 0 to 100
  • Estimated time set to 10.00 h

This commit to Deltaports disables soft-pinning all together from graphics/mesa-dri:

commit 630507ebacd566668d1cb8507b86fccec01f4f9b
Author: Fran├žois Tigeot <>
Date: Mon Feb 11 19:45:31 2019 +0100

graphics/mesa-dri: Disable soft-spinning of all buffers

This commit to DragonFly provides a fix for when soft-pinning is enabled again:

commit d653c72734cf5be86d3cd2b4208c1e4ec68ade00
Author: Fran├žois Tigeot <>
Date: Sun Feb 17 09:06:17 2019 +0100

drm: Fix Linux/DragonFly PAGE_MASK confusion

Also available in: Atom PDF