No subject

0x0314e050:      0x61010006: STATE_BASE_ADDRESS
0x0314e054:      0x00000001:    general state base address 0x00000000
0x0314e058:      0x00000001:    surface state base address 0x00000000
0x0314e05c:      0x00000001:    indirect state base address 0x00000000
0x0314e060:      0x00000001:    instruction state base address 0x00000000
0x0314e064:      0x10000001:    general state upper bound 0x10000000
0x0314e068:      0x10000001:    indirect state upper bound 0x10000000
0x0314e06c:      0x10000001:    instruction state upper bound 0x10000000

And if we look at some of the other auxiliary instructions buffers sent
along with the batch:

  0314e000    16384 0048 0000 000ab700 dirty purgeable render uncached
...
  11e30000     4096 0011 0000 000ab700 purgeable render uncached
  11e2b000     4096 0011 0000 000ab700 purgeable render uncached
  10e43000     4096 0011 0000 000ab700 render uncached
  10e44000     4096 0011 0000 000ab700 purgeable render uncached

0x10 being the instruction domain for a total of about 20 instruction
buffers referenced from that batch above the upper bound (and in
particular appears to have been the first batch to use addresses above
256M).

This batch fits the modus operandi of the bug that was fixed in
2.14.901, it would seem sensible to address the known issue first.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre