Disable the guc.

Assigned to Rodrigo if it is related to GuC.

This test pass when we disable GuC and with last setup:

Platform: Broxton P B1 Platform 
CPU Name : Intel(R) @ 1.1 GHz (family: 6, model: 12, stepping: 9) – 4 cores
SoC : BROXTON-P B1
CRB : Apollo Lake RVPa1 Fab2
Bios:APLKRVPA.X64.0138.B25.1606130640 date: 06/13/2016
KSC: 1.15
Microcode revesion: c
Rework:R19 R20

drm:
  url: git://git.freedesktop.org/git/mesa/drm
  tag: libdrm-2.4.68-11-g7996a87
  committed_date: Wed Jun 29 17:23:37 2016 +0000
mesa:
  url: git://git.freedesktop.org/git/mesa/mesa
  tag: mesa-11.2.2
cairo:
  url: git://anongit.freedesktop.org/cairo
  tag: 1.15.2
xorg-server-macros:
  url: git://git.freedesktop.org/git/xorg/util/macros
  branch: master
  tag: util-macros-1.19.0-2-gd7acec2
xserver:
  url: git://git.freedesktop.org/git/xorg/xserver
  tag: xorg-server-1.18.0-443-g3762edd
xf86-video-intel:
  url: git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
  tag: 2.99.917-674-g9154dff
libva:
  url: git://git.freedesktop.org/git/vaapi/libva
  tag: libva-1.7.0-26-gc36971c
vaapi-intel-driver:
  url: git://git.freedesktop.org/git/vaapi/intel-driver
  tag: 1.7.0-53-gbcde10d
intel-gpu-tool:
  branch: master
  tag: intel-gpu-tools-1.15-54-g88c1f7c
  authored_date: Thu Jun 23 21:53:23 2016 +0000

(In reply to Humberto Israel Perez Rodriguez from comment #0)

> Maximum execution latency on render, 55.486us, total 73.134us per cycle
> All (4 engines): 364,544 cycles, average 27.624us per cycle
> Subtest basic: SUCCESS (14.123s)
> 
> Maximum execution latency on render, 5.633us, total 14.183us per cycle
> All (4 engines): 655,360 cycles, average 15.280us per cycle
> Average time (15.280us) exceeds expecation for parallel execution (min 2.825us, max 5.633us; limit set at 8.772us)
> Subtest basic: FAIL (14.033s)

So the failing test executed more cycles with a lower average time per cycle than the one that passed? Why is that a failure?

It's a severe regression in dispatch latency.

Just to be clear, it implies we cannot dispatch simultaneously on each ring as we could in the past. (Yes, the guc can do concurrent but it imposes severe latency for no gain.)

(In reply to Chris Wilson from comment #6)
> Just to be clear, it implies we cannot dispatch simultaneously on each ring
> as we could in the past. (Yes, the guc can do concurrent but it imposes
> severe latency for no gain.)

Can you give the reasoning behind the limit in this test, i.e. time < max + 10*min/9

The requirement expresses that we should be able to execute independent tasks in parallel, as that is a desired property of the code.

(In reply to Chris Wilson from comment #8)
> The requirement expresses that we should be able to execute independent
> tasks in parallel, as that is a desired property of the code.

Why is 10*min/9 included in the comparison, i.e. why isn't the comparison just "time <= max"?

(In reply to Chris Harris from comment #9)
> (In reply to Chris Wilson from comment #8)
> > The requirement expresses that we should be able to execute independent
> > tasks in parallel, as that is a desired property of the code.
> 
> Why is 10*min/9 included in the comparison, i.e. why isn't the comparison
> just "time <= max"?

The conditions (lockdep, memdebug) under which the test is run are not ideal, and compromises had to be made.

(In reply to Chris Wilson from comment #10)
> (In reply to Chris Harris from comment #9)
> > (In reply to Chris Wilson from comment #8)
> > > The requirement expresses that we should be able to execute independent
> > > tasks in parallel, as that is a desired property of the code.
> > 
> > Why is 10*min/9 included in the comparison, i.e. why isn't the comparison
> > just "time <= max"?
> 
> The conditions (lockdep, memdebug) under which the test is run are not
> ideal, and compromises had to be made.

Understood, is the inclusion of 10*min/9 based on empirical testing or was it based on some logic?

Here's a summary of the issues:

1. The timing results from this subtest are variable.
2. The subtest is based on a comparison 'time < max + 10*min/9'  where there's currently no logical explanation for the the '10*min/9' component.

So this subtest should be updated to make the timing results consistent and with a logically explained comparison or the subtest should be removed from the list of BAT tests.

Test is Pass with fresh kernel and GuC not loaded.

Platform: APL system
CPU Name : Intel(R) Genuine Processor @ 1.1 GHz (family: 6, model: 12, stepping: 9) 4 cores
QDF : Q6HE
SoC : B1
CRB : Apollo Lake DDR3L RVP1A FAB2
Reworks : R19, R20

Software 
Bios: 144_B10 APLK_B0_IFWI_X64_R_2016_06_27_0956_SPI_RVP1.bin from \\gar\ec\proj\ba\CCG\APL BIOS\External\BIOS_Release\Daily\v144_10_2016_WW27.1\IFWI\IFWI_RVP1_Release\IFWI
KSC: 1.15
Linux distribution: Ubuntu 16.04 64 bits
Kernel: 4.7.0-rc7 895a714 from http://cgit.freedesktop.org/drm-intel/ with https://patchwork.freedesktop.org/patch/99445/ applied
   commit 895a714b0b596cfcbe82065f99376ad02d369125
   Author: Daniel Vetter <daniel.vetter@ffwll.ch>
   Date:   Mon Jul 18 14:35:39 2016 +0200
   drm-intel-nightly: 2016y-07m-18d-12h-35m-15s UTC integration manifest
drm: libdrm-2.4.68-15 2212a64 from git://anongit.freedesktop.org/mesa/drm
mesa: mesa-11.2.2 3a9f628from git://anongit.freedesktop.org/mesa/mesa
cairo: 1.15.2 db8a7f1 from git://anongit.freedesktop.org/cairo
xserver: xorg-server-1.18.0-460 e8e3675 from git://git.freedesktop.org/git/xorg/xserver
xf86-video-intel: 2.99.917-676 26f8ab5 from git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
libva: libva-1.7.0-26 c36971c from git://git.freedesktop.org/git/vaapi/libva
vaapi-intel-driver: 1.7.0-53 bcde10d from git://git.freedesktop.org/git/vaapi/intel-driver
DMC 1.07 from https://01.org/linuxgraphics/downloads/broxton-dmc-1.07
Intel-Gpu-Tools 1.15-127 ee5d5c4 from http://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools.git

Updating priority based on the fact that w/o GuC this basic pass

GuC enabling patches were reverted for now so this case should now pass again.

(In reply to Kimmo Nikkanen from comment #15)
> GuC enabling patches were reverted for now so this case should now pass
> again.

this is correct and stated in comment #13

(In reply to yann from comment #16)
> (In reply to Kimmo Nikkanen from comment #15)
> > GuC enabling patches were reverted for now so this case should now pass
> > again.
> 
> this is correct and stated in comment #13

Please could you run the full test, i.e. './gem_exec_nop --debug' with both GuC on and GuC off.  Please add the results to this bug report.

It's now working for me with the following configuration:

Software Config
==========================================
drm: libdrm-2.4.70-0caa84c from git://anongit.freedesktop.org/mesa/drm 
mesa: 11.2.2 3a9f628 from git://anongit.freedesktop.org/mesa/mesa 
cairo: 1.15.2 db8a7f1 from git://anongit.freedesktop.org/cairo   
xserver: xorg-server-1.18.0-497-g0b2f308 from git://git.freedesktop.org/git/xorg/xserver 
xf86-video-intel:2.99.917-684-g6988b87 from git://anongit.freedesktop.org/xorg/driver/xf86-video-intel 
libva: 1.7.0-26-gc36971c from git://git.freedesktop.org/git/vaapi/libva 
vaapi-intel-driver:1.7.0-58-ge554446 from git://anongit.freedesktop.org/vaapi/intel-driver
kernel: Branch: drm-intel-nightly, commit id:  7eeb04a101316645916d4d9df058a9341797f1af

IGT -basic tests really shouldn't be doing performance testing.

BASIC functionality is stuff like 'can we submit batches' and 'does this display work', not timings of complicated and arbitrary patterns of usage.

This also doesn't belong in the gem_exec_nop test at all; it should be in a dedicated performance/latency test instead, preferably one which explains what it's measuring and why any particular test is considered to have failed.

As it stands, it doesn't prove *anything* about any "latency introduced by the GuC". It could just as easily be due to the pattern of batch completion on multiple engines leading to more contention for the struct_mutex (for example).

Created attachment 125364 [details]
Results with GuC submission disabled

Comment on attachment 125364 [details]
Results with GuC submission disabled

I've added the results from Luis with GuC submission disabled.  According to these results the test is passing with GuC submission disabled because the latency is worse with GuC submission disabled.  In particular the latency on non-render rings is much worse than the results with GuC submission enabled.

This test also fails in execlist mode:

IGT-Version: 1.15-g3747a59 (x86_64) (Linux: 4.7.0-dsg-02697-g8393b21-dsg-work-122 x86_64)
Using Execlists submission
Maximum execution latency on render, 2.915us, total 6.420us per cycle
All (4 engines): 2,338,816 cycles, average 4.276us per cycle
(gem_exec_nop:4435) CRITICAL: Test assertion failure function all, file gem_exec_nop.c:197:
(gem_exec_nop:4435) CRITICAL: Failed assertion: time < max + 10*min/9
(gem_exec_nop:4435) CRITICAL: Average time (4.276us) exceeds expecation for parallel execution (min 1.167us, max 2.915us; limit set at 4.212us)
Stack trace:
  #0 [__igt_fail_assert+0xf1]
  #1 [all+0x46a]
  #2 [__real_main229+0x165]
  #3 [main+0x29]
  #4 [__libc_start_main+0xf0]
  #5 [_start+0x29]
  #6 [<unknown>+0x29]
Subtest basic failed.
**** DEBUG ****
(gem_exec_nop:4435) DEBUG: Test requirement passed: nengine
(gem_exec_nop:4435) INFO: Maximum execution latency on render, 2.915us, total 6.420us per cycle
(gem_exec_nop:4435) INFO: All (4 engines): 2,338,816 cycles, average 4.276us per cycle
(gem_exec_nop:4435) CRITICAL: Test assertion failure function all, file gem_exec_nop.c:197:
(gem_exec_nop:4435) CRITICAL: Failed assertion: time < max + 10*min/9
(gem_exec_nop:4435) CRITICAL: Average time (4.276us) exceeds expecation for parallel execution (min 1.167us, max 2.915us; limit set at 4.212us)
****  END  ****
Subtest basic: FAIL (14.010s)

With GuC not loaded, gem_exec_nop basic subtests are Pass.

# ./gem_exec_nop --r basic-series
IGT-Version: 1.16-gf565b6c (x86_64) (Linux: 4.8.0-rc5-nightly+ x86_64)
Using Execlists submission
Maximum execution latency on render, 5.784us, min 2.773us, total 14.125us per cycle, average 3.531us
All (4 engines): 2,031,616 cycles, average 4.927us per cycle [expected 3.526us]
Subtest basic-series: SUCCESS (14.026s)

# ./gem_exec_nop --r basic-parallel
IGT-Version: 1.16-gf565b6c (x86_64) (Linux: 4.8.0-rc5-nightly+ x86_64)
Using Execlists submission
average (individually): 3.532us
render: 886784 cycles, 11.286us
bsd: 483328 cycles, 20.706us
blt: 551936 cycles, 18.133us
vebox: 598016 cycles, 16.733us
Subtest basic-parallel: SUCCESS (14.027s)

Testexd with:

Platform: APL system
CPU Name : Intel(R) Genuine Processor @ 1.1 GHz (family: 6, model: 12, stepping: 9) 4 cores
QDF : Q6HE
SoC : B1
CRB : Apollo Lake DDR3L RVP1A FAB2

Software 
Bios: 144_B10 APLK_B0_IFWI_X64_R_2016_06_27_0956_SPI_RVP1.bin from \\gar\ec\proj\ba\CCG\APL BIOS\External\BIOS_Release\Daily\v144_10_2016_WW27.1\IFWI\IFWI_RVP1_Release\IFWI
KSC: 1.15
Linux distribution: Ubuntu 16.04 64 bits
DMC 1.07
GuC 8.7
Kernel: 4.8.0-rc5 bef9c1f from http://cgit.freedesktop.org/drm-intel/
  commit bef9c1f4afe24cfff578d386bde349add65673eb
  Author: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
  Date:   Mon Sep 12 11:35:34 2016 +0300
  drm-intel-nightly: 2016y-09m-12d-08h-35m-02s UTC integration manifest
libdrm-2.4.70-12 2d00869 from git://anongit.freedesktop.org/mesa/drm
mesa: mesa-11.2.2 3a9f628 from git://anongit.freedesktop.org/mesa/mesa
cairo 1.15.2 db8a7f1 from git://anongit.freedesktop.org/cairo
xorg-server-1.18.0-549 527c6ba from git://git.freedesktop.org/git/xorg/xserver
xf86-video-intel 2.99.917-703 15c5ff1 from git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
libva-1.7.0-47 2ebf897 from git://git.freedesktop.org/git/vaapi/libva 
vaapi-intel-driver: 1.7.0-117 8c11f51 from git://git.freedesktop.org/git/vaapi/intel-driver
Intel-Gpu-Tools 1.16 f565b6c from http://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools.git

I will check with GuC loaded

I've applied the GuC/HuC loading patch series:

https://patchwork.freedesktop.org/series/11926/
https://patchwork.freedesktop.org/series/11158/

on top of this kernel commit

commit 4ca90e7c3b6e429e033b93fc56fc156da8f222ef
Author: Sumit Semwal <sumit.semwal@linaro.org>
Date:   Tue Sep 20 18:13:58 2016 +0530

    drm-intel-nightly: 2016y-09m-20d-12h-43m-32s UTC integration manifest


The latest changes to gem_exec_nop.c relaxes the assertion for parallel execution, and with that the test is now passing:

IGT-Version: 1.16-g237cb89 (x86_64) (Linux: 4.8.0-rc7guc-huc-patch-series+ x86_64)
Using GuC submission
Maximum execution latency on render, 6.693us, min 2.876us, total 15.365us per cycle, average 3.841us
All (4 engines): 565,248 cycles, average 17.778us per cycle [expected 3.830us]
Subtest basic-series: SUCCESS (14.075s)
average (individually): 3.829us
blt: 105472 cycles, 94.925us
vebox: 103424 cycles, 96.829us
bsd: 104448 cycles, 95.939us
render: 219136 cycles, 45.767us
Subtest basic-parallel: SUCCESS (14.048s)
default: 2,926,592 cycles: 6.834us
Subtest default: SUCCESS (20.003s)
render: 3,050,496 cycles: 6.560us
Subtest render: SUCCESS (20.015s)
bsd: 6,914,048 cycles: 2.893us
Subtest bsd: SUCCESS (20.003s)
Test requirement not met in function gem_require_ring, file ioctl_wrappers.c:1450:
Test requirement: gem_has_ring(fd, ring)
Subtest bsd1: SKIP (0.000s)
Test requirement not met in function gem_require_ring, file ioctl_wrappers.c:1450:
Test requirement: gem_has_ring(fd, ring)
Subtest bsd2: SKIP (0.000s)
blt: 6,952,960 cycles: 2.877us
Subtest blt: SUCCESS (20.003s)
vebox: 6,894,592 cycles: 2.901us
Subtest vebox: SUCCESS (20.004s)
Maximum execution latency on render, 6.433us, min 2.880us, total 15.111us per cycle, average 3.778us
All (4 engines): 9,031,680 cycles, average 16.610us per cycle [expected 3.768us]
Subtest series: SUCCESS (154.046s)
average (individually): 3.845us
render: 3315712 cycles, 45.241us
blt: 1601536 cycles, 93.665us
vebox: 1582080 cycles, 94.819us
bsd: 1572864 cycles, 95.376us
Subtest parallel: SUCCESS (154.031s)

------------------------------------------

 Software information 
============================================ 
Kernel version              	: 4.8.0-rc7guc-huc-patch-series+ 
Linux distribution          	: Ubuntu 16.04.1 LTS 
Architecture                	: 64-bit 
Kernel driver in use        	: i915 
Bios revision               	: 144.10 
Bios release date               : 06/27/2016 
KSC revision                	: 1.15 

 Hardware information 
============================================ 
Platform                     	: BXT-P 
Motherboard model            	: Broxton P 
Motherboard type             	: NOTEBOOK Hand Held 
Motherboard manufacturer     	: Intel Corp. 
CPU family                   	: Other 
CPU information              	: 06/5c 
GPU Card                     	: Intel Corporation Device 5a84 (rev 0a) (prog-if 00 [VGA controller]) 
Memory ram                   	: 16 GB 
Maximum memory ram allowed   	: 16 GB 
Display resolution       	:  
CPU thread                      : 4 
CPU core                        : 4 
Socket                          : Other 
Signature                       :  
Hard drive capacity             : 74GiB (80GB) 

 Firmwares information 
============================================ 
DMC fw loaded                	: yes 
DMC version                	: 1.7 
GUC fw loaded                	: SUCCESS 
GUC version wanted           	: 8.7 
GUC version found            	: 8.7

Assigned to Elio to double confirm.

Elio,
Could you apply the patches pointed by Carlos and double confirm gem_exec_nop basic subtests are Pass with HuC and GuC loaded.
You may need to launch them in a loop, example with a simple shell script:
#!/bin/bash
for i in {1..100}
do
   sudo ./gem_exec_nop --r basic-parallel
   sleep 5s
   sudo ./gem_exec_nop --r basic-series
   sleep 5s
done

Created attachment 127072 [details]
attachment-19244-0.html

Hi,

Thank you for your mail !!

Harman is on vacation starting WW40.4( 29th Sept)  to  WW42.5(14th Oct) with no access to e-mails.Below is my CPM backup coverage during this time period

1.     CORE Windows 15.45 ( SKL/APL/KBL)  : -  Archana Gopalan
2.     CORE Android BXT-P( Kernel4.4 Migration, IOTG IVI, Embedded, Grosse Tete) :- Shashidhar Hiremath
3.     CORE IOTG YOCTO IVI/Linux : Jeff Mcgee
4.     For Anything else :  Gene Pong

Thanks & Regards
Harmanpreet Singh

After installing guc and dmc, it seems that it is not loading guc no matter the grub parameters.

(01:45 PM) [gfx@gfx-Kabylake-Client-platform] [tests]$ : sudo ./gem_exec_nop --r basic-parallel
IGT-Version: 1.16-g48a9e1e (x86_64) (Linux: 4.8.0guccarlos+ x86_64)
Using Execlists submission
(gem_exec_nop:1110) ioctl-wrappers-CRITICAL: Test assertion failure function gem_execbuf, file ioctl_wrappers.c:589:
(gem_exec_nop:1110) ioctl-wrappers-CRITICAL: Failed assertion: __gem_execbuf(fd, execbuf) == 0
(gem_exec_nop:1110) ioctl-wrappers-CRITICAL: error: -5 != 0
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [gem_execbuf+0x44]
  #2 [nop_on_ring+0x8f]
  #3 [parallel+0xb7]
  #4 [__real_main299+0x235]
  #5 [main+0x23]
  #6 [__libc_start_main+0xf0]
  #7 [_start+0x29]
  #8 [<unknown>+0x29]
Subtest basic-parallel failed.
**** DEBUG ****
(gem_exec_nop:1110) ioctl-wrappers-CRITICAL: Test assertion failure function gem_execbuf, file ioctl_wrappers.c:589:
(gem_exec_nop:1110) ioctl-wrappers-CRITICAL: Failed assertion: __gem_execbuf(fd, execbuf) == 0
(gem_exec_nop:1110) ioctl-wrappers-CRITICAL: error: -5 != 0
****  END  ****
Subtest basic-parallel: FAIL (0.002s)
(01:45 PM) [gfx@gfx-Kabylake-Client-platform] [tests]$ : sudo ./gem_exec_nop --r basic-series
IGT-Version: 1.16-g48a9e1e (x86_64) (Linux: 4.8.0guccarlos+ x86_64)
Using Execlists submission
(gem_exec_nop:1113) ioctl-wrappers-CRITICAL: Test assertion failure function gem_execbuf, file ioctl_wrappers.c:589:
(gem_exec_nop:1113) ioctl-wrappers-CRITICAL: Failed assertion: __gem_execbuf(fd, execbuf) == 0
(gem_exec_nop:1113) ioctl-wrappers-CRITICAL: error: -5 != 0
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [gem_execbuf+0x44]
  #2 [nop_on_ring+0x8f]
  #3 [series+0xb4]
  #4 [__real_main299+0x3c3]
  #5 [main+0x23]
  #6 [__libc_start_main+0xf0]
  #7 [_start+0x29]
  #8 [<unknown>+0x29]
Subtest basic-series failed.
**** DEBUG ****
(gem_exec_nop:1113) ioctl-wrappers-CRITICAL: Test assertion failure function gem_execbuf, file ioctl_wrappers.c:589:
(gem_exec_nop:1113) ioctl-wrappers-CRITICAL: Failed assertion: __gem_execbuf(fd, execbuf) == 0
(gem_exec_nop:1113) ioctl-wrappers-CRITICAL: error: -5 != 0
****  END  ****
Subtest basic-series: FAIL (0.002s)


*********************************************************************

Dmesg showing guc is not being loaded

Please consider that initrd.img and vmlinuz are copied just after installing the firmwares.


[    0.000000] Command line: vmlinuz root=/dev/sda2 initrd=initrd.img idle=halt log_buf_len=4M i915.enable_rc6=1 i915.preliminary_hw_support=1 drm.debug=0xe i915.enable_guc_enable=2 i915.enable_guc_submission=2 resume=/dev/sda3
[    0.000000] Kernel command line: vmlinuz root=/dev/sda2 initrd=initrd.img idle=halt log_buf_len=4M i915.enable_rc6=1 i915.preliminary_hw_support=1 drm.debug=0xe i915.enable_guc_enable=2 i915.enable_guc_submission=2 resume=/dev/sda3
[    3.489294] usb usb1: Manufacturer: Linux 4.8.0guccarlos+ xhci-hcd
[    3.511896] usb usb2: Manufacturer: Linux 4.8.0guccarlos+ xhci-hcd
[    4.264850] i915: unknown parameter 'enable_guc_enable' ignored
[    4.270563] Setting dangerous option enable_guc_submission - tainting kernel
[    4.273606] [drm:intel_device_info_dump [i915]] i915 device info: has_guc: yes
[    4.324637] [drm:intel_guc_setup [i915]] GuC fw status: path i915/bxt_guc_ver8_7.bin, fetch NONE, load NONE
[    4.324684] [drm:intel_guc_setup [i915]] *ERROR* GuC init failed: -5


I will try with Rodrigo's patches and share my findings so far.

Created attachment 127129 [details]
attachment-1346-0.html

Hi,

Thank you for your mail !!

Harman is on vacation starting WW40.4( 29th Sept)  to  WW42.5(14th Oct) with no access to e-mails.Below is my CPM backup coverage during this time period

1.     CORE Windows 15.45 ( SKL/APL/KBL)  : -  Archana Gopalan
2.     CORE Android BXT-P( Kernel4.4 Migration, IOTG IVI, Embedded, Grosse Tete) :- Shashidhar Hiremath
3.     CORE IOTG YOCTO IVI/Linux : Jeff Mcgee
4.     For Anything else :  Gene Pong

Thanks & Regards
Harmanpreet Singh

(In reply to Elio from comment #27)

> [    4.324637] [drm:intel_guc_setup [i915]] GuC fw status: path
> i915/bxt_guc_ver8_7.bin, fetch NONE, load NONE
> [    4.324684] [drm:intel_guc_setup [i915]] *ERROR* GuC init failed: -5
Check if the .bin is available in this folder:
ls /lib/firmware/i915/ |grep guc

> I will try with Rodrigo's patches and share my findings so far.
Thanks

Created attachment 127160 [details]
attachment-24413-0.html

Hi,

Thank you for your mail !!

Harman is on vacation starting WW40.4( 29th Sept)  to  WW42.5(14th Oct) with no access to e-mails.Below is my CPM backup coverage during this time period

1.     CORE Windows 15.45 ( SKL/APL/KBL)  : -  Archana Gopalan
2.     CORE Android BXT-P( Kernel4.4 Migration, IOTG IVI, Embedded, Grosse Tete) :- Shashidhar Hiremath
3.     CORE IOTG YOCTO IVI/Linux : Jeff Mcgee
4.     For Anything else :  Gene Pong

Thanks & Regards
Harmanpreet Singh

Confirmed, the patches work fine and tests are success, 

(09:05 AM) [gfx@gfx-bxt] [tests]$ : sudo ./gem_exec_nop --r basic-parallel
[sudo] password for gfx:
IGT-Version: 1.16-gf7408bf (x86_64) (Linux: 4.8.0-nightly-patch-anusha+ x86_64)
Using GuC submission
average (individually): 3.719us
bsd: 74752 cycles, 66.899us
blt: 69632 cycles, 71.823us
vebox: 71680 cycles, 69.816us
render: 172032 cycles, 29.126us
Subtest basic-parallel: SUCCESS (9.025s)
(09:07 AM) [gfx@gfx-bxt] [tests]$ : sudo ./gem_exec_nop --r basic-series
IGT-Version: 1.16-gf7408bf (x86_64) (Linux: 4.8.0-nightly-patch-anusha+ x86_64)
Using GuC submission
Maximum execution latency on render, 6.367us, min 2.824us, total 14.888us per cycle, average 3.722us
All (4 engines): 356,352 cycles, average 14.168us per cycle [expected 3.709us]
Subtest basic-series: SUCCESS (9.073s)

Even with GUC loaded

 dmesg | grep intel_guc_setup
[    3.120324] [drm:intel_guc_setup [i915]] GuC fw status: path i915/bxt_guc_ver8_7.bin, fetch SUCCESS, load NONE
[    3.120359] [drm:intel_guc_setup [i915]] GuC fw status: fetch SUCCESS, load PENDING
[    3.129205] [drm:intel_guc_setup [i915]] GuC fw status: fetch SUCCESS, load SUCCESS



Configuration:

Kernel:  drm-intel-next-2016-09-19-15336-gcb978ac

IGT: intel-gpu-tools-1.16-90-gf7408bf
Component         : drm
	url       : http://cgit.freedesktop.org/mesa/drm
	tag       : libdrm-2.4.68
	commit    : fc09c5ab84240e9b6bd0bed01685ef004f56c4fa


Component         : mesa
	url       : http://cgit.freedesktop.org/mesa/mesa
	tag       : mesa-12.0.1
	commit    : 04277f058d00238937e664cf546c43b16cea7b2b

Component         : xf86-video-intel
	url       : http://cgit.freedesktop.org/xorg/driver/xf86-video-intel
	tag       : 2.99.917-701-g205146b
	commit    : 205146b0fdc8db016e5cfeeae5a6b25df3470ebc

Component         : libva
	url       : http://cgit.freedesktop.org/libva
	tag       : libva-1.7.2.pre1
	commit    : 9927bd2fbbb1d923fd6a8932a3cdbb5c9185ee22

Component         : intel-driver
	url       : http://cgit.freedesktop.org/vaapi/intel-driver
	tag       : 1.7.2.pre1
	commit    : ce444fb412966ca6afbb1331b7cae8ab621c1108

Component         : cairo
	url       : http://cgit.freedesktop.org/cairo
	tag       : 1.15.2
	commit    : db8a7f1697c49ae4942d2aa49eed52dd73dd9c7a

Component         : xserver
	url       : http://cgit.freedesktop.org/xorg/xserver
	tag       : xorg-server-1.18.3
	commit    : 9454cd51da9b38b974cff7c8b7125901f6403848

Component         : macros
	url       : https://cgit.freedesktop.org/xorg/util/macros
	tag       : util-macros-1.19.0-2-gd7acec2


Attaching dmesg as evidence

Created attachment 127431 [details]
Evidence log