On Thu, May 15, 2014 at 02:46:32PM +0200, Daniel Vetter wrote: > On Thu, May 15, 2014 at 01:17:12PM +0100, Chris Wilson wrote: > > This is pure evil. Userspace, I'm looking at you SNA, repacks batch > > buffers on the fly after generation as they are being passed to the > > kernel for execution. These batches also contain self-referenced > > relocations as a single buffer encompasses the state commands, kernels, > > vertices and sampler. During generation the buffers are placed at known > > offsets within the full batch, and then the relocation deltas (as passed > > to the kernel) are tweaked as the batch is repacked into a smaller buffer. > > This means that userspace is passing negative relocations deltas, which > > subsequently wrap to large values if the batch is at a low address. The > > GPU hangs when it then tries to use the large value as a base for its > > address offsets, rather than wrapping back to the real value (as one > > would hope). As the GPU uses positive offsets from the base, we can > > treat the relocation address as the minimum address read by the GPU. > > For the upper bound, we trust that userspace will not read beyond the > > end of the buffer. > > > > This fixes a GPU hang when it tries to use an address (relocation + > > offset) greater than the GTT size. The issue would occur quite easily > > with full-ppgtt as each fd gets its own VM space, so low offsets would > > often be handed out. However, with the rearrangement of the low GTT due > > to capturing the BIOS framebuffer, it is already affecting kernels 3.14 > > onwards. I think only IVB+ is susceptible to this bug, but the workaround > > should only kick in rarely, so it seems sensible to always apply it. > > > > v2: Apply the workaround for LUT-based execbuffers as well and only for > > IVB+ as my SNB machine seems to be unaffected. > > > > Testcase: igt/gem_bad_reloc > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: stable@xxxxxxxxxxxxxxx > > Do we need to fix this in the kernel? Userspace supplying relocs that > kinda don't work smells fishy ... What? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
