From: "Sharma, Swati2" <swati2.sharma@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
"Ser, Simon" <simon.ser@intel.com>,
"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Subject: Re: [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Add assert for drm_intel_bufmgr and intel_batchbuffer before usage
Date: Fri, 6 Sep 2019 01:30:45 +0530 [thread overview]
Message-ID: <6e19ede2-9adf-d940-4830-3ff5c0a3e6c7@intel.com> (raw)
In-Reply-To: <20190904093524.GG4019@platvala-desk.ger.corp.intel.com>
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?
--
~Swati Sharma
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-09-05 20:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 12:34 [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Add assert for drm_intel_bufmgr and intel_batchbuffer before usage Swati Sharma
2019-08-08 14:04 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2019-08-08 22:59 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2019-08-13 10:28 ` [igt-dev] [PATCH i-g-t] " Ser, Simon
2019-08-13 10:38 ` Chris Wilson
2019-09-03 20:10 ` Sharma, Swati2
2019-09-04 9:35 ` Petri Latvala
2019-09-05 20:00 ` Sharma, Swati2 [this message]
2019-09-06 10:02 ` Petri Latvala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6e19ede2-9adf-d940-4830-3ff5c0a3e6c7@intel.com \
--to=swati2.sharma@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=igt-dev@lists.freedesktop.org \
--cc=simon.ser@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox