Re: [PATCH v6] igt/gem_trtt: Exercise the TRTT hardware

["Goel, Akash" <akash.goel@intel.com>]

On 3/18/2016 4:02 PM, Chris Wilson wrote:
> On Fri, Mar 18, 2016 at 03:22:51PM +0530, Goel, Akash wrote:
>>
>>
>> On 3/18/2016 2:52 PM, Chris Wilson wrote:
>>> On Fri, Mar 18, 2016 at 02:31:23PM +0530, Goel, Akash wrote:
>>>>
>>>>> Hopefully final comments!
>>>>>
>>>>> Missed EINTR handling during evict, If you repeat the busy/hang tests
>>>>> within the igt_fork_signal_helper(); igt_stop_signal_helper() that
>>>>> should cover catching an inopportune signal.
>>>>
>>>> Fine will add, thanks for suggesting this
>>>> So the signal will interrupt the Driver, which would be waiting for
>>>> the vma unbind to complete, from the eviction path.
>>>
>>> Right, and we will report the error back to userspace as EINTR and
>>> userspace will restart the syscall and we expect it to succeed
>>> (eventually). Just useful for flushing out the error handling.
>>>
>>> Having just remembered how useful this might be, I just extended
>>> gem_softpin for similar reasons:
>>> +       igt_subtest("evict-active-interruptible") {
>>> +               struct timespec start = {};
>>> +               while (igt_seconds_elapsed(&start) < 20)
>>> +                       test_evict_active(fd);
>>> +       }
>> Thanks I just tested the interruptible versions like this :-
>>
>> +	igt_fork_signal_helper();
>> +	igt_subtest("evict_active-interruptible")
>> +		 test_evict_active();
>
> The point about looping is to try and ensure that every possible code
> path is interrupted (since we only interrupt every 2us and the code paths
> tend to be shorter than than!).

Thanks, will follow the gem_softpin.c example.

I hope you meant 2ms here & not 2us, since the signal_helper_process is 
sending signals at the ~500 Hz rate.

Best regards
Akash

> So we repeat the test in the vain hope of hitting something else.
>

>> +	igt_subtest("evict_hang-interruptible")
>> +		test_evict_hang();
>> +	igt_stop_signal_helper();
>>
>> Actually the hanging object test implicitly exercises the
>> interruption case (otherwise the test won't pass), error recovery as
>> a part of GPU reset wakes up/interrupts the waiters.
>
> But only in one spot :)
> -Chris
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx