etnaviv: *ERROR* relocation N outside object in kernel log
Lucas Stach
l.stach at pengutronix.de
Fri Jul 21 12:49:03 UTC 2017
Am Freitag, den 21.07.2017, 14:10 +0200 schrieb Wladimir J. van der
Laan:
> While keeping ioquake3_opengl2 running on a GC2000 (i.mx6q), mesa master as of
> 322b34e, these messages are semi-randomly logged:
>
> [ 355.434762] [drm:etnaviv_ioctl_gem_submit] *ERROR* relocation 95 outside object
> [ 441.236364] [drm:etnaviv_ioctl_gem_submit] *ERROR* relocation 169 outside object
> [ 942.108318] [drm:etnaviv_ioctl_gem_submit] *ERROR* relocation 312 outside object
> [ 1014.394550] [drm:etnaviv_ioctl_gem_submit] *ERROR* relocation 53 outside object
> [ 1458.379389] [drm:etnaviv_ioctl_gem_submit] *ERROR* relocation 167 outside object
> [ 1536.887630] [drm:etnaviv_ioctl_gem_submit] *ERROR* relocation 293 outside object
>
> They don't seem to go along with visual corruption, though there seems to be a
> single-frame hiccup. It is not clearly reproducible.
The hiccup would be because the kernel rejects the cmdstream without
actually executing it on the GPU if it detects any errors.
> On GC3000, trying the same, the GPU occasionally hangs completely, with no
> apparent error in the kernel log, just a hangcheck-reset-continue. Not sure
> it's related at all, but the hangs don't occur on GC2000.
>
> I don't see these problems with different applications. I'm not sure what could
> cause a relocation outside an object to be emitted.
My guess would be some stale relocation again, possibly with only a
stale offset or something. But that's hard to track down.
For now we don't have a better way than dumping out parts of the
cmdstream before the faulty relocation cmdstream offset. This should
allow to work out which state it is trying to load with the relocation,
hopefully yielding some smoking gun in the pipe driver.
Regards,
Lucas
More information about the etnaviv
mailing list