All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 4/5] drm/nv50: let applications hanging on vm flush to be killed
@ 2012-04-22 22:18 Marcin Slusarz
       [not found] ` <1335133112-8008-4-git-send-email-marcin.slusarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Marcin Slusarz @ 2012-04-22 22:18 UTC (permalink / raw)
  To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Ben Skeggs
  Cc: Daniel Vetter

Signed-off-by: Marcin Slusarz <marcin.slusarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/gpu/drm/nouveau/nv50_graph.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau/nv50_graph.c
+++ b/drivers/gpu/drm/nouveau/nv50_graph.c
@@ -435,6 +435,11 @@ nv84_graph_tlb_flush(struct drm_device *dev, int engine)
 			if ((tmp & 7) == 1)
 				idle = false;
 		}
+
+		if (fatal_signal_pending(current)) {
+			ret = -ERESTARTSYS;
+			break;
+		}
 	} while (!idle && !(timeout = ptimer->read(dev) - start > 2000000000));
 
 	if (timeout) {
-- 
1.7.8.5

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH 4/5] drm/nv50: let applications hanging on vm flush to be killed
       [not found] ` <1335133112-8008-4-git-send-email-marcin.slusarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2012-04-23 17:09   ` Martin Peres
  2012-04-23 17:30     ` [Nouveau] " Marcin Slusarz
  0 siblings, 1 reply; 3+ messages in thread
From: Martin Peres @ 2012-04-23 17:09 UTC (permalink / raw)
  To: Marcin Slusarz
  Cc: Daniel Vetter, nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	Ben Skeggs, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

Le 23/04/2012 00:18, Marcin Slusarz a écrit :
> Signed-off-by: Marcin Slusarz<marcin.slusarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>   drivers/gpu/drm/nouveau/nv50_graph.c |    5 +++++
>   1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c b/drivers/gpu/drm/nouveau/nv50_graph.c
> index 6899547..a61853f 100644
> --- a/drivers/gpu/drm/nouveau/nv50_graph.c
> +++ b/drivers/gpu/drm/nouveau/nv50_graph.c
> @@ -435,6 +435,11 @@ nv84_graph_tlb_flush(struct drm_device *dev, int engine)
>   			if ((tmp&  7) == 1)
>   				idle = false;
>   		}
> +
> +		if (fatal_signal_pending(current)) {
> +			ret = -ERESTARTSYS;
> +			break;
> +		}
>   	} while (!idle&&  !(timeout = ptimer->read(dev) - start>  2000000000));
>
>   	if (timeout) {
Good, but who should send the kill signal in the first place?

Shouldn't nouveau drm terminate the process(es) associated with the 
channel that generated the lockup ?

Can you provide more info on how the lockup recovery works?

Thanks in advance,
Martin

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Nouveau] [PATCH 4/5] drm/nv50: let applications hanging on vm flush to be killed
  2012-04-23 17:09   ` Martin Peres
@ 2012-04-23 17:30     ` Marcin Slusarz
  0 siblings, 0 replies; 3+ messages in thread
From: Marcin Slusarz @ 2012-04-23 17:30 UTC (permalink / raw)
  To: Martin Peres; +Cc: nouveau, Ben Skeggs, dri-devel

On Mon, Apr 23, 2012 at 07:09:57PM +0200, Martin Peres wrote:
> Le 23/04/2012 00:18, Marcin Slusarz a écrit :
> > Signed-off-by: Marcin Slusarz<marcin.slusarz@gmail.com>
> > ---
> >   drivers/gpu/drm/nouveau/nv50_graph.c |    5 +++++
> >   1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c b/drivers/gpu/drm/nouveau/nv50_graph.c
> > index 6899547..a61853f 100644
> > --- a/drivers/gpu/drm/nouveau/nv50_graph.c
> > +++ b/drivers/gpu/drm/nouveau/nv50_graph.c
> > @@ -435,6 +435,11 @@ nv84_graph_tlb_flush(struct drm_device *dev, int engine)
> >   			if ((tmp&  7) == 1)
> >   				idle = false;
> >   		}
> > +
> > +		if (fatal_signal_pending(current)) {
> > +			ret = -ERESTARTSYS;
> > +			break;
> > +		}
> >   	} while (!idle&&  !(timeout = ptimer->read(dev) - start>  2000000000));
> >
> >   	if (timeout) {
> Good, but who should send the kill signal in the first place?
> 
> Shouldn't nouveau drm terminate the process(es) associated with the 
> channel that generated the lockup ?

Well, this patch is not necessary for gpu reset - it's just "let's be nice" change.
Currently application is unkillable when hanging on vm flush 

Marcin
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-04-23 17:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-22 22:18 [PATCH 4/5] drm/nv50: let applications hanging on vm flush to be killed Marcin Slusarz
     [not found] ` <1335133112-8008-4-git-send-email-marcin.slusarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-04-23 17:09   ` Martin Peres
2012-04-23 17:30     ` [Nouveau] " Marcin Slusarz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.