[BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!

Lucas Stach l.stach at pengutronix.de
Wed Jun 27 14:38:11 UTC 2018


Hi Russell,

Am Dienstag, den 26.06.2018, 17:48 +0200 schrieb Lucas Stach:
> Hi Russell,
> 
> Am Dienstag, den 26.06.2018, 16:36 +0100 schrieb Russell King - ARM
> Linux:
> > On Tue, Jun 26, 2018 at 09:17:26AM +0100, Russell King - ARM Linux
> > wrote:
> > > On Tue, Jun 19, 2018 at 02:28:46PM +0200, Lucas Stach wrote:
> > > > Agreed. I'll look into bringing back the process detection for
> > > > 4.17
> > > > stable.
> > > > 
> > > > I'm still curious why the GC600 on the Dove is that slow. With
> > > > performance like this moving a big(ish) window on the screen
> > > > must
> > > > be a
> > > > horrible user experience.
> > > 
> > > This doesn't seem to be the cause - it seems that there's
> > > something
> > > going on with 4.17 that really is causing the Dove GC600 to get
> > > stuck.
> > > Reverting all the drivers/gpu/drm/etnaviv changes back to the
> > > 4.16
> > > state while keeping everything else the same results in no hangs,
> > > whereas increasing the timeout with 4.17 still results in hangs.
> > > 
> > > I'll try to find some time to bisect.
> > 
> > Sorry, it seems that my attempts to change what was running on the
> > system were ineffective (due to the etnaviv module loaded from the
> > initramfs, not from the fs copy I was updating.)  Extending the
> > timeout to 5 seconds does indeed stop the issue.
> 
> Thanks for confirming that the issue is caused by the removed
> progress
> check.
> 
> > More importantly, it stops some memory corruption I've observed as
> > well, caused by etnaviv freeing buffers when it thinks the GPU has
> > timed out while the GPU is still writing to them.
> 
> Urgh, that is really bad. I'll get a fix out of the door tomorrow.

I've just sent a patch do to this. Can you please confirm that this
fixes your issue on GC600?

Thanks,
Lucas


More information about the dri-devel mailing list