Bug 47085

*** This bug has been marked as a duplicate of bug 44748 ***

Wrong bug, sorry for the noise.

After a failure is there anything in dmesg?

(In reply to comment #3)
> After a failure is there anything in dmesg?
No,I only get a empty dmesg after the failure.

System Environment:
--------------------------
Platform:        ILK
Kernel: (drm-intel-fixes)5d031e5b633d910f35e6e0abce94d9d842390006

Bug detailed description:
-------------------------
   On ILK platform ,running gem_tiled_fence_blits of the Intel-gpu-tools
with "make test" command will sometimes fail,but run it seperate can always
pass.

 the error on the console is like this:
 gem_tiled_fence_blits: intel_batchbuffer.c:110: intel_batchbuffer_flush_on_ring: Assertion `ret == 0\' failed.

Created attachment 58419 [details]
dmesg

Created attachment 58638 [details] [review]
print error value

Please apply this patch to i-g-t and check what the error value is when these tests fail. Please also check whether it's always the same or sometimes different, by running the tests until you've observed a few failures with both.

(In reply to comment #7)
> Created attachment 58638 [details] [review] [review]
> print error value
> Please apply this patch to i-g-t and check what the error value is when these
> tests fail. Please also check whether it's always the same or sometimes
> different, by running the tests until you've observed a few failures withboth.
The error is:
 exec_batch failed with -13, Permission denied
 gem_pipe_control_store_loop:     intel_batchbuffer.c:113:intel_batchbuffer_flush_on_ring: Assertion `0\' failed.

Just to check: All these sporadically failing tests fail with "-13, Permission denied"?

Also please check that when you're runnning i-g-t tests that:
- you are running these tests as root.
- no other drm client (e.g. X) is running. This is _very_ important, because a few tests can only exercise a specific bug if nothing else is using the kernel drm driver.

(In reply to comment #9)
> Just to check: All these sporadically failing tests fail with "-13, Permission
> denied"?
> Also please check that when you're runnning i-g-t tests that:
> - you are running these tests as root.
> - no other drm client (e.g. X) is running. This is _very_ important, because a
> few tests can only exercise a specific bug if nothing else is using the kernel
> drm driver.
  It seems like other I-G-T case which running first will influence the fail case.
  With your patch:
  The error of gem_pipe_control_store_loop is:
  exec_batch failed with -13, Permission denied
 gem_pipe_control_store_loop: intel_batchbuffer.c:113:       intel_batchbuffer_flush_on_ring: Assertion `0\' failed. 

  The error of gem_tiled_fence_blits now is:
  not enough RAM to run test, reducing buffer count.
 So,Daniel,I want to confirm with you:If one case run seperate can return a PASS result,can we think the result is credible? Or we should check the single and the continuous running result?

> --- Comment #10 from yangguang <guang.a.yang@intel.com> 2012-03-22 01:41:35 PDT ---
> (In reply to comment #9)
> > Just to check: All these sporadically failing tests fail with "-13, Permission
> > denied"?
> > Also please check that when you're runnning i-g-t tests that:
> > - you are running these tests as root.
> > - no other drm client (e.g. X) is running. This is _very_ important, because a
> > few tests can only exercise a specific bug if nothing else is using the kernel
> > drm driver.
>   It seems like other I-G-T case which running first will influence the fail
> case.
>   With your patch:
>   The error of gem_pipe_control_store_loop is:
>   exec_batch failed with -13, Permission denied
>  gem_pipe_control_store_loop: intel_batchbuffer.c:113:      
> intel_batchbuffer_flush_on_ring: Assertion `0\' failed. 

I've crawled through the kernel and the only place we return this error
code is when checking for is when checking for drm authentication and
is_master. The former will never fail if you run these tests as root. The
later will never fail if these tests are run separately, when there's no
other drm client running. So again, please check this. And especially
check whether your test rig launches tests in parallel or might not
properly wait until a test has completed. In both cases I expect spurious
errors.

>   The error of gem_tiled_fence_blits now is:
>   not enough RAM to run test, reducing buffer count.
>  So,Daniel,I want to confirm with you:If one case run seperate can return a
> PASS result,can we think the result is credible? Or we should check the single
> and the continuous running result?

Well, that's not actually an error of any sort. The script is just
complaining that there's not enough memory to run it fully. And then it
exits with return code 77, which means skip. I guess your testing rig gets
confused because the test dumps the error into stderr. I've fixed that up.
But that test failure should happen _always_ on a given machine, so if
this fails unstably, it's rather strange.

This should be fixed by the following patch from -fixes:

commit 5d031e5b633d910f35e6e0abce94d9d842390006
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Feb 8 13:34:13 2012 +0000

    drm/i915: Remove use of the autoreported ringbuffer HEAD position

 confirmed, the bug has been fixed with -fixes branch.

Closing old verified.