[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