Until now, the following Intel_gpu_tool cases has issue:

Hung case:
  gem_bad_batch 

Failure:
gem_bad_length: gem_bad_length.c:103: create0: Assertion `retval == 22' failed.

gem_mmap_gtt:   gem_mmap_gtt.c:87: gem_read: Assertion `ret == 0' failed.

> --- Comment #1 from sunyi <yi.sun@intel.com> 2011-09-22 02:04:16 PDT ---
> Hung case:
>   gem_bad_batch 

This one should not run when using
$ make check
(it's in HANG in tests/Makefile.am instead of TESTS). Please ensure that
you run all these tests (idally with make check). Otherwise you might not
automatically pick up new tests I'm adding (on snb, a few more tests
should fail). I also suggest you upgrade your intel-gpu-tools repo at
least weekly.

> Failure:
> gem_bad_length: gem_bad_length.c:103: create0: Assertion `retval == 22' failed.
> 
> gem_mmap_gtt:   gem_mmap_gtt.c:87: gem_read: Assertion `ret == 0' failed.

Both known failures, fixes are in the works/under review.

Thanks for integrating this stuff with the qa workflow.

The case 'gem_linear_blits' time out(not finish about 1 hour) on IronLake mobile platform. But the issue doesn't appear on IronLake desktop. You man check if it occurs on your side.

> --- Comment #3 from sunyi <yi.sun@intel.com> 2011-10-14 17:24:13 PDT ---
> The case 'gem_linear_blits' time out(not finish about 1 hour) on IronLake
> mobile platform. But the issue doesn't appear on IronLake desktop. You man
> check if it occurs on your side.

Has that machine just 2GB of ram? In that case it's a bit expected
that this test takes forever, because it will heavily hit on swap.
I'll luck into tuning the test a bit better.

Yeah, the machines on which run this case time out are of 2G RAM. And I have tried the case again with a parameter which is smaller than the default one. It completed normally. So, I think, maybe we could update the test case.

(In reply to comment #4)
> > --- Comment #3 from sunyi <yi.sun@intel.com> 2011-10-14 17:24:13 PDT ---
> > The case 'gem_linear_blits' time out(not finish about 1 hour) on IronLake
> > mobile platform. But the issue doesn't appear on IronLake desktop. You man
> > check if it occurs on your side.
> Has that machine just 2GB of ram? In that case it's a bit expected
> that this test takes forever, because it will heavily hit on swap.
> I'll luck into tuning the test a bit better.

> --- Comment #5 from sunyi <yi.sun@intel.com> 2011-10-16 18:00:36 PDT ---
> Yeah, the machines on which run this case time out are of 2G RAM. And I have
> tried the case again with a parameter which is smaller than the default one. It
> completed normally. So, I think, maybe we could update the test case.

I've updated the test to automatically limit the memory used to the
total available. If it's still taking too long, please complain.
Generally I aim for these tests to run a few minutes at most, i.e. I
think you could reduce your timeout to about 15 minutes.

A new Intel_gpu_tool cases has issue when run it at IvyBridge platform.

gem_tiled_pread:  Bad read [0]: 512 instead of 528 at 0x00000200 for read from 0x00000000 to 0x00100000, swizzle=bit9^10
Aborted (core dumped)

> --- Comment #7 from yangguang <guang.a.yang@intel.com> 2011-11-22 00:04:30 PST ---
> A new Intel_gpu_tool cases has issue when run it at IvyBridge platform.
> 
> gem_tiled_pread:  Bad read [0]: 512 instead of 528 at 0x00000200 for read from
> 0x00000000 to 0x00100000, swizzle=bit9^10
> Aborted (core dumped)

This should be fixed with

commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 12 20:49:16 2011 +0200

    drm/i915: fix swizzling on gen6+

Please check whether you have that patch in your tree.

(In reply to comment #8)
> > --- Comment #7 from yangguang <guang.a.yang@intel.com> 2011-11-22 00:04:30 PST ---
> > A new Intel_gpu_tool cases has issue when run it at IvyBridge platform.
> > 
> > gem_tiled_pread:  Bad read [0]: 512 instead of 528 at 0x00000200 for read from
> > 0x00000000 to 0x00100000, swizzle=bit9^10
> > Aborted (core dumped)
> This should be fixed with
> commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Mon Sep 12 20:49:16 2011 +0200
>     drm/i915: fix swizzling on gen6+
> Please check whether you have that patch in your tree.

I find this issue with LINUX 3.1.1 kernel,which environment:
Kernel: (master)b48635635c1a696aea6423ec6c547c8c7bbf7aab
now this case can pass with the newest drm-intel-next.

Daniel,I have report a new i-g-t bug: Bug 43178

   A new Intel_gpu_tool cases has issue when run it at IVB/SNB/ILK platform.
   when run gem_exec_bad_domains ,we can find some error at dmesg, we test with the drm-intel-testing.
 Kernel: (drm-intel-testing)60f1358afca2d7778138c6dc187a3198f1a2425f

ERROR:
[drm:i915_gem_execbuffer_relocate_entry] *ERROR* reloc with read/write non-GPU domains: obj f4187f00 target 3 offset 4 read 00000001 write 00000000
[drm:i915_gem_execbuffer_relocate_entry] *ERROR* reloc with read/write non-GPU domains: obj f4187f00 target 3 offset 4 read 00000001 write 00000001
[drm:i915_gem_execbuffer_relocate_entry] *ERROR* reloc with read/write non-GPU domains: obj f4187f00 target 3 offset 4 read 00000040 write 00000000
[drm:i915_gem_execbuffer_relocate_entry] *ERROR* reloc with read/write non-GPU domains: obj f4187f00 target 3 offset 4 read 00000040 write 00000040

gem_exec_bad_domains resulting in errors is a know issue, I'll merge patch to fix this to -queued soon.

We don't do a stellar job of keeping this up-to-date, and now that i-g-t testing is well integrated into our QA workflow, this has outlived it's usefulness.