Re: [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Add assert for drm_intel_bufmgr and intel_batchbuffer before usage

[Petri Latvala <petri.latvala@intel.com>]

On Fri, Sep 06, 2019 at 01:30:45AM +0530, Sharma, Swati2 wrote:
> On 04-Sep-19 3:05 PM, Petri Latvala wrote:
> > On Wed, Sep 04, 2019 at 01:40:36AM +0530, Sharma, Swati2 wrote:
> > > On 13-Aug-19 4:08 PM, Chris Wilson wrote:
> > > > 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
> > > Shouldn't we add igt_assert() and instead add wrapper func to check bufmgr?
> > 
> > That would lead to fails. The thumb rule is that fails happen from
> > kernel bugs, skips happen from untestable configurations (hardware &
> > software). igt_require is more suitable for this.
> > 
> > 
> I have one query, why there isn't the generic rule for this. For IGTs
> such as gem_write_read_ring_switch, gem_unref_active_buffers, etc we have
> igt_assert() whereas you will find few IGTs like gem_unfence_active_buffers,
> gem_tiled_partial_pwrite_pread, etc which doesn't even have igt_assert().
> What should be done?


They should be unified in some manner. We either drop libdrm_intel
usage and write a helper, or make all usage of it uniform with a
helper, so in any case it looks like a wrapper helper is in order.


-- 
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev