Quoting Ser, Simon (2019-08-13 11:28:54)
On Thu, 2019-08-08 at 18:04 +0530, Swati Sharma wrote:
if drm_intel_bufmgr_gem_init() or intel_batchbuffer_alloc()
returns NULL, it leads to seg fault as below:
root@testrunner:/home/testrunner/swati/otc_gen_graphics-intel-gpu-tools#
./tests/kms_big_fb
IGT-Version: 1.24-g976db91 (x86_64) (Linux: 5.1.0-rc6+ x86_64)
Max driver framebuffer size 8192x8192
RAM: 2749 MiB, GPU address space: 134217728 MiB, GGTT mappable size: 256
MiB
Received signal SIGSEGV.
Stack trace:
#0 [fatal_sig_handler+0x77]
#1 [killpg+0x40]
#2 [drm_intel_bo_alloc+0x0]
#3 [intel_batchbuffer_reset+0x33]
#4 [intel_batchbuffer_alloc+0x34]
#5 [__real_main603+0x3e9]
#6 [main+0x23]
#7 [__libc_start_main+0xf0]
#8 [_start+0x29]
#9 [<unknown>+0x29]
Segmentation fault (core dumped)
To prevent this igt_assert() is added for both the functions.
I'm not sure I understand why this segfault happens. Seems like
drm_intel_bufmgr_gem_init can return NULL in the following cases:
* No compiled with libdrm_intel support, in which case the tests should
be skipped
* Allocation failure or pthread mutex failure, which are unlikely to
happen (but it would be nice to log something when those fail)
* DRM_IOCTL_I915_GEM_APERTURE fails (but something is printed to
stderr, it doesn't seem like this is the case here)
Am I missing something?
Usual cause is unrecognised GPU by libdrm. In which case it should be an
igt_require_f(data.bufmgr, "Update libdrm for %s support\n", intel_chipset_get_name(devid))
Roll that up into an <somename>_wrapper and spread far and wide.
(Although I prefer the option of not using libdrm_intel in the first
place.)
-Chris