On Wed, Jul 23, 2014 at 9:37 AM, Christian König <christian.koenig@xxxxxxx> wrote: > Am 23.07.2014 09:31, schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 9:26 AM, Christian König >> <deathsimple@xxxxxxxxxxx> wrote: >>> >>> It's not a locking problem I'm talking about here. Radeons lockup >>> handling >>> kicks in when anything calls into the driver from the outside, if you >>> have a >>> fence wait function that's called from the outside but doesn't handle >>> lockups you essentially rely on somebody else calling another radeon >>> function for the lockup to be resolved. >> >> So you don't have a timer in radeon that periodically checks whether >> progress is still being made? That's the approach we're using in i915, >> together with some tricks to kick any stuck waiters so that we can >> reliably step in and grab locks for the reset. > > > We tried this approach, but it didn't worked at all. > > I already considered trying it again because of the upcoming fence > implementation, but reconsidering that when a driver is forced to change > it's handling because of the fence implementation that's just another hint > that there is something wrong here. Out of curiosity: What's the blocker for using a timer/scheduled work to reset radeon? Getting this right on i915 has been fairly tricky and we now have an elaborate multi-stage state machine to get the driver through a reset. So always interested in different solutions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
