Bug #3171
closedmesa-libs 18.3.2 not working
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
[...]
Files
Updated by tuxillo almost 6 years 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;
Updated by ftigeot almost 6 years 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 <kenneth@whitecape.org>
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 <jordan.l.justen@intel.com>
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;
Updated by tuxillo almost 6 years ago
Hi,
In Mesa commit a363bb2cd they enable unconditionally the soft-pinning feature1 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/
Updated by tuxillo almost 6 years 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 <ftigeot@wolfpond.org>
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 <ftigeot@wolfpond.org>
Date: Sun Feb 17 09:06:17 2019 +0100
drm: Fix Linux/DragonFly PAGE_MASK confusion