a08bff1e98b8e630f8bdf341af1491cd99e7d104 caused a regression (assert) on g965 for this piglit test.
This is the assert:
texsubimage: ../../../../../../src/mesa/drivers/dri/i965/brw_wm_surface_state.c:691: brw_update_renderbuffer_surface: Assertion `brw->has_surface_tile_offset || (tile_x == 0 && tile_y == 0)' failed.
Without that patch the texsubimage test doesn't use the PBO path because it uses GL_UNPACK_IMAGE_HEIGHT. However I think you can make it hit that assert without using the image height property so the patch doesn't cause the regression but makes the test case detect the existing bug.
I can't find any 965 hardware but I can replicate it with a GM45 device if I force Mesa to set brw->has_surface_tile_offset to false. It looks like the problem is that the array slices aren't aligned to a tile and it needs to use a tile offset but it can't. The fbo-array test fails in a similar way. In that case maybe it's just a hardware limitation that 965 can't really render to array slices other than 0. We should probably have a way to mark the framebuffer as incomplete in that case.
Or I guess an alternative solution would be to make that intel_renderbuffer_move_to_temp mechanism select only a single slice of the array texture instead of creating a temporary mt that has the same depth. The comment just above the call to that implies that it is meant to handle the array_index but I guess it doesn't.