[PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Karol Herbst]

It is a bit unlcear to us why that's helping, but it does and unbreaks
suspend/resume on a lot of GPUs without any known drawbacks.

Cc: stable@vger.kernel.org # v5.15+
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
Signed-off-by: Karol Herbst <kherbst@redhat.com>
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 35bb0bb3fe61..126b3c6e12f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
 		if (ret == 0) {
 			ret = nouveau_fence_new(chan, false, &fence);
 			if (ret == 0) {
+				/* TODO: figure out a better solution here
+				 *
+				 * wait on the fence here explicitly as going through
+				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
+				 *
+				 * Without this the operation can timeout and we'll fallback to a
+				 * software copy, which might take several minutes to finish.
+				 */
+				nouveau_fence_wait(fence, false, false);
 				ret = ttm_bo_move_accel_cleanup(bo,
 								&fence->base,
 								evict, false,
-- 
2.37.1

[Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Karol Herbst]

It is a bit unlcear to us why that's helping, but it does and unbreaks
suspend/resume on a lot of GPUs without any known drawbacks.

Cc: stable@vger.kernel.org # v5.15+
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
Signed-off-by: Karol Herbst <kherbst@redhat.com>
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 35bb0bb3fe61..126b3c6e12f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
 		if (ret == 0) {
 			ret = nouveau_fence_new(chan, false, &fence);
 			if (ret == 0) {
+				/* TODO: figure out a better solution here
+				 *
+				 * wait on the fence here explicitly as going through
+				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
+				 *
+				 * Without this the operation can timeout and we'll fallback to a
+				 * software copy, which might take several minutes to finish.
+				 */
+				nouveau_fence_wait(fence, false, false);
 				ret = ttm_bo_move_accel_cleanup(bo,
 								&fence->base,
 								evict, false,
-- 
2.37.1

[PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Karol Herbst]

It is a bit unlcear to us why that's helping, but it does and unbreaks
suspend/resume on a lot of GPUs without any known drawbacks.

Cc: stable@vger.kernel.org # v5.15+
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
Signed-off-by: Karol Herbst <kherbst@redhat.com>
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 35bb0bb3fe61..126b3c6e12f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
 		if (ret == 0) {
 			ret = nouveau_fence_new(chan, false, &fence);
 			if (ret == 0) {
+				/* TODO: figure out a better solution here
+				 *
+				 * wait on the fence here explicitly as going through
+				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
+				 *
+				 * Without this the operation can timeout and we'll fallback to a
+				 * software copy, which might take several minutes to finish.
+				 */
+				nouveau_fence_wait(fence, false, false);
 				ret = ttm_bo_move_accel_cleanup(bo,
 								&fence->base,
 								evict, false,
-- 
2.37.1

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Lyude Paul]

Reviewed-by: Lyude Paul <lyude@redhat.com>

On Fri, 2022-08-19 at 22:09 +0200, Karol Herbst wrote:
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
> 
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>  		if (ret == 0) {
>  			ret = nouveau_fence_new(chan, false, &fence);
>  			if (ret == 0) {
> +				/* TODO: figure out a better solution here
> +				 *
> +				 * wait on the fence here explicitly as going through
> +				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +				 *
> +				 * Without this the operation can timeout and we'll fallback to a
> +				 * software copy, which might take several minutes to finish.
> +				 */
> +				nouveau_fence_wait(fence, false, false);
>  				ret = ttm_bo_move_accel_cleanup(bo,
>  								&fence->base,
>  								evict, false,

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Lyude Paul]

Reviewed-by: Lyude Paul <lyude@redhat.com>

On Fri, 2022-08-19 at 22:09 +0200, Karol Herbst wrote:
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
> 
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>  		if (ret == 0) {
>  			ret = nouveau_fence_new(chan, false, &fence);
>  			if (ret == 0) {
> +				/* TODO: figure out a better solution here
> +				 *
> +				 * wait on the fence here explicitly as going through
> +				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +				 *
> +				 * Without this the operation can timeout and we'll fallback to a
> +				 * software copy, which might take several minutes to finish.
> +				 */
> +				nouveau_fence_wait(fence, false, false);
>  				ret = ttm_bo_move_accel_cleanup(bo,
>  								&fence->base,
>  								evict, false,

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Lyude Paul]

Reviewed-by: Lyude Paul <lyude@redhat.com>

On Fri, 2022-08-19 at 22:09 +0200, Karol Herbst wrote:
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
> 
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>  		if (ret == 0) {
>  			ret = nouveau_fence_new(chan, false, &fence);
>  			if (ret == 0) {
> +				/* TODO: figure out a better solution here
> +				 *
> +				 * wait on the fence here explicitly as going through
> +				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +				 *
> +				 * Without this the operation can timeout and we'll fallback to a
> +				 * software copy, which might take several minutes to finish.
> +				 */
> +				nouveau_fence_wait(fence, false, false);
>  				ret = ttm_bo_move_accel_cleanup(bo,
>  								&fence->base,
>  								evict, false,

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Salvatore Bonaccorso]

Hi,

On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
> 
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>  		if (ret == 0) {
>  			ret = nouveau_fence_new(chan, false, &fence);
>  			if (ret == 0) {
> +				/* TODO: figure out a better solution here
> +				 *
> +				 * wait on the fence here explicitly as going through
> +				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +				 *
> +				 * Without this the operation can timeout and we'll fallback to a
> +				 * software copy, which might take several minutes to finish.
> +				 */
> +				nouveau_fence_wait(fence, false, false);
>  				ret = ttm_bo_move_accel_cleanup(bo,
>  								&fence->base,
>  								evict, false,
> -- 
> 2.37.1
> 
> 

While this is marked for 5.15+ only, a user in Debian was seeing the
suspend issue as well on 5.10.y and did confirm the commit fixes the
issue as well in the 5.10.y series:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69

Karol, Lyude, should that as well be picked for 5.10.y?

Regards,
Salvatore

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Salvatore Bonaccorso]

Hi,

On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
> 
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>  		if (ret == 0) {
>  			ret = nouveau_fence_new(chan, false, &fence);
>  			if (ret == 0) {
> +				/* TODO: figure out a better solution here
> +				 *
> +				 * wait on the fence here explicitly as going through
> +				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +				 *
> +				 * Without this the operation can timeout and we'll fallback to a
> +				 * software copy, which might take several minutes to finish.
> +				 */
> +				nouveau_fence_wait(fence, false, false);
>  				ret = ttm_bo_move_accel_cleanup(bo,
>  								&fence->base,
>  								evict, false,
> -- 
> 2.37.1
> 
> 

While this is marked for 5.15+ only, a user in Debian was seeing the
suspend issue as well on 5.10.y and did confirm the commit fixes the
issue as well in the 5.10.y series:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69

Karol, Lyude, should that as well be picked for 5.10.y?

Regards,
Salvatore

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Salvatore Bonaccorso]

Hi,

On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
> 
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>  		if (ret == 0) {
>  			ret = nouveau_fence_new(chan, false, &fence);
>  			if (ret == 0) {
> +				/* TODO: figure out a better solution here
> +				 *
> +				 * wait on the fence here explicitly as going through
> +				 * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +				 *
> +				 * Without this the operation can timeout and we'll fallback to a
> +				 * software copy, which might take several minutes to finish.
> +				 */
> +				nouveau_fence_wait(fence, false, false);
>  				ret = ttm_bo_move_accel_cleanup(bo,
>  								&fence->base,
>  								evict, false,
> -- 
> 2.37.1
> 
> 

While this is marked for 5.15+ only, a user in Debian was seeing the
suspend issue as well on 5.10.y and did confirm the commit fixes the
issue as well in the 5.10.y series:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69

Karol, Lyude, should that as well be picked for 5.10.y?

Regards,
Salvatore

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Karol Herbst]

On Tue, Sep 20, 2022 at 12:42 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Hi,
>
> On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> > It is a bit unlcear to us why that's helping, but it does and unbreaks
> > suspend/resume on a lot of GPUs without any known drawbacks.
> >
> > Cc: stable@vger.kernel.org # v5.15+
> > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> > Signed-off-by: Karol Herbst <kherbst@redhat.com>
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 35bb0bb3fe61..126b3c6e12f9 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
> >               if (ret == 0) {
> >                       ret = nouveau_fence_new(chan, false, &fence);
> >                       if (ret == 0) {
> > +                             /* TODO: figure out a better solution here
> > +                              *
> > +                              * wait on the fence here explicitly as going through
> > +                              * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> > +                              *
> > +                              * Without this the operation can timeout and we'll fallback to a
> > +                              * software copy, which might take several minutes to finish.
> > +                              */
> > +                             nouveau_fence_wait(fence, false, false);
> >                               ret = ttm_bo_move_accel_cleanup(bo,
> >                                                               &fence->base,
> >                                                               evict, false,
> > --
> > 2.37.1
> >
> >
>
> While this is marked for 5.15+ only, a user in Debian was seeing the
> suspend issue as well on 5.10.y and did confirm the commit fixes the
> issue as well in the 5.10.y series:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69
>
> Karol, Lyude, should that as well be picked for 5.10.y?
>

mhh from the original report 5.10 was fine, but maybe something got
backported and it broke it? I'll try to do some testing on my machine
and see what I can figure out, but it could also be a debian only
issue at this point.

> Regards,
> Salvatore
>

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Karol Herbst]

On Tue, Sep 20, 2022 at 12:42 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Hi,
>
> On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> > It is a bit unlcear to us why that's helping, but it does and unbreaks
> > suspend/resume on a lot of GPUs without any known drawbacks.
> >
> > Cc: stable@vger.kernel.org # v5.15+
> > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> > Signed-off-by: Karol Herbst <kherbst@redhat.com>
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 35bb0bb3fe61..126b3c6e12f9 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
> >               if (ret == 0) {
> >                       ret = nouveau_fence_new(chan, false, &fence);
> >                       if (ret == 0) {
> > +                             /* TODO: figure out a better solution here
> > +                              *
> > +                              * wait on the fence here explicitly as going through
> > +                              * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> > +                              *
> > +                              * Without this the operation can timeout and we'll fallback to a
> > +                              * software copy, which might take several minutes to finish.
> > +                              */
> > +                             nouveau_fence_wait(fence, false, false);
> >                               ret = ttm_bo_move_accel_cleanup(bo,
> >                                                               &fence->base,
> >                                                               evict, false,
> > --
> > 2.37.1
> >
> >
>
> While this is marked for 5.15+ only, a user in Debian was seeing the
> suspend issue as well on 5.10.y and did confirm the commit fixes the
> issue as well in the 5.10.y series:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69
>
> Karol, Lyude, should that as well be picked for 5.10.y?
>

mhh from the original report 5.10 was fine, but maybe something got
backported and it broke it? I'll try to do some testing on my machine
and see what I can figure out, but it could also be a debian only
issue at this point.

> Regards,
> Salvatore
>

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Karol Herbst]

On Tue, Sep 20, 2022 at 12:42 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Hi,
>
> On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> > It is a bit unlcear to us why that's helping, but it does and unbreaks
> > suspend/resume on a lot of GPUs without any known drawbacks.
> >
> > Cc: stable@vger.kernel.org # v5.15+
> > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> > Signed-off-by: Karol Herbst <kherbst@redhat.com>
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 35bb0bb3fe61..126b3c6e12f9 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
> >               if (ret == 0) {
> >                       ret = nouveau_fence_new(chan, false, &fence);
> >                       if (ret == 0) {
> > +                             /* TODO: figure out a better solution here
> > +                              *
> > +                              * wait on the fence here explicitly as going through
> > +                              * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> > +                              *
> > +                              * Without this the operation can timeout and we'll fallback to a
> > +                              * software copy, which might take several minutes to finish.
> > +                              */
> > +                             nouveau_fence_wait(fence, false, false);
> >                               ret = ttm_bo_move_accel_cleanup(bo,
> >                                                               &fence->base,
> >                                                               evict, false,
> > --
> > 2.37.1
> >
> >
>
> While this is marked for 5.15+ only, a user in Debian was seeing the
> suspend issue as well on 5.10.y and did confirm the commit fixes the
> issue as well in the 5.10.y series:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69
>
> Karol, Lyude, should that as well be picked for 5.10.y?
>

mhh from the original report 5.10 was fine, but maybe something got
backported and it broke it? I'll try to do some testing on my machine
and see what I can figure out, but it could also be a debian only
issue at this point.

> Regards,
> Salvatore
>

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Salvatore Bonaccorso]

Hi,

On Tue, Sep 20, 2022 at 01:36:32PM +0200, Karol Herbst wrote:
> On Tue, Sep 20, 2022 at 12:42 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
> >
> > Hi,
> >
> > On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> > > It is a bit unlcear to us why that's helping, but it does and unbreaks
> > > suspend/resume on a lot of GPUs without any known drawbacks.
> > >
> > > Cc: stable@vger.kernel.org # v5.15+
> > > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> > > Signed-off-by: Karol Herbst <kherbst@redhat.com>
> > > ---
> > >  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index 35bb0bb3fe61..126b3c6e12f9 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
> > >               if (ret == 0) {
> > >                       ret = nouveau_fence_new(chan, false, &fence);
> > >                       if (ret == 0) {
> > > +                             /* TODO: figure out a better solution here
> > > +                              *
> > > +                              * wait on the fence here explicitly as going through
> > > +                              * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> > > +                              *
> > > +                              * Without this the operation can timeout and we'll fallback to a
> > > +                              * software copy, which might take several minutes to finish.
> > > +                              */
> > > +                             nouveau_fence_wait(fence, false, false);
> > >                               ret = ttm_bo_move_accel_cleanup(bo,
> > >                                                               &fence->base,
> > >                                                               evict, false,
> > > --
> > > 2.37.1
> > >
> > >
> >
> > While this is marked for 5.15+ only, a user in Debian was seeing the
> > suspend issue as well on 5.10.y and did confirm the commit fixes the
> > issue as well in the 5.10.y series:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69
> >
> > Karol, Lyude, should that as well be picked for 5.10.y?
> >
> 
> mhh from the original report 5.10 was fine, but maybe something got
> backported and it broke it? I'll try to do some testing on my machine
> and see what I can figure out, but it could also be a debian only
> issue at this point.

Right, this is a possiblity, thanks for looking into it!

Computer Enthusiastic, can you verify the problem as well in a
non-Debian patched upstream kernel directly from the 5.10.y series
(latest 5.10.144) and verify the fix there?

Regards,
Salvatore

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Salvatore Bonaccorso]

Hi,

On Tue, Sep 20, 2022 at 01:36:32PM +0200, Karol Herbst wrote:
> On Tue, Sep 20, 2022 at 12:42 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
> >
> > Hi,
> >
> > On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> > > It is a bit unlcear to us why that's helping, but it does and unbreaks
> > > suspend/resume on a lot of GPUs without any known drawbacks.
> > >
> > > Cc: stable@vger.kernel.org # v5.15+
> > > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> > > Signed-off-by: Karol Herbst <kherbst@redhat.com>
> > > ---
> > >  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index 35bb0bb3fe61..126b3c6e12f9 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
> > >               if (ret == 0) {
> > >                       ret = nouveau_fence_new(chan, false, &fence);
> > >                       if (ret == 0) {
> > > +                             /* TODO: figure out a better solution here
> > > +                              *
> > > +                              * wait on the fence here explicitly as going through
> > > +                              * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> > > +                              *
> > > +                              * Without this the operation can timeout and we'll fallback to a
> > > +                              * software copy, which might take several minutes to finish.
> > > +                              */
> > > +                             nouveau_fence_wait(fence, false, false);
> > >                               ret = ttm_bo_move_accel_cleanup(bo,
> > >                                                               &fence->base,
> > >                                                               evict, false,
> > > --
> > > 2.37.1
> > >
> > >
> >
> > While this is marked for 5.15+ only, a user in Debian was seeing the
> > suspend issue as well on 5.10.y and did confirm the commit fixes the
> > issue as well in the 5.10.y series:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69
> >
> > Karol, Lyude, should that as well be picked for 5.10.y?
> >
> 
> mhh from the original report 5.10 was fine, but maybe something got
> backported and it broke it? I'll try to do some testing on my machine
> and see what I can figure out, but it could also be a debian only
> issue at this point.

Right, this is a possiblity, thanks for looking into it!

Computer Enthusiastic, can you verify the problem as well in a
non-Debian patched upstream kernel directly from the 5.10.y series
(latest 5.10.144) and verify the fix there?

Regards,
Salvatore

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Salvatore Bonaccorso]

Hi,

On Tue, Sep 20, 2022 at 01:36:32PM +0200, Karol Herbst wrote:
> On Tue, Sep 20, 2022 at 12:42 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
> >
> > Hi,
> >
> > On Fri, Aug 19, 2022 at 10:09:28PM +0200, Karol Herbst wrote:
> > > It is a bit unlcear to us why that's helping, but it does and unbreaks
> > > suspend/resume on a lot of GPUs without any known drawbacks.
> > >
> > > Cc: stable@vger.kernel.org # v5.15+
> > > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> > > Signed-off-by: Karol Herbst <kherbst@redhat.com>
> > > ---
> > >  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index 35bb0bb3fe61..126b3c6e12f9 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
> > >               if (ret == 0) {
> > >                       ret = nouveau_fence_new(chan, false, &fence);
> > >                       if (ret == 0) {
> > > +                             /* TODO: figure out a better solution here
> > > +                              *
> > > +                              * wait on the fence here explicitly as going through
> > > +                              * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> > > +                              *
> > > +                              * Without this the operation can timeout and we'll fallback to a
> > > +                              * software copy, which might take several minutes to finish.
> > > +                              */
> > > +                             nouveau_fence_wait(fence, false, false);
> > >                               ret = ttm_bo_move_accel_cleanup(bo,
> > >                                                               &fence->base,
> > >                                                               evict, false,
> > > --
> > > 2.37.1
> > >
> > >
> >
> > While this is marked for 5.15+ only, a user in Debian was seeing the
> > suspend issue as well on 5.10.y and did confirm the commit fixes the
> > issue as well in the 5.10.y series:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#69
> >
> > Karol, Lyude, should that as well be picked for 5.10.y?
> >
> 
> mhh from the original report 5.10 was fine, but maybe something got
> backported and it broke it? I'll try to do some testing on my machine
> and see what I can figure out, but it could also be a debian only
> issue at this point.

Right, this is a possiblity, thanks for looking into it!

Computer Enthusiastic, can you verify the problem as well in a
non-Debian patched upstream kernel directly from the 5.10.y series
(latest 5.10.144) and verify the fix there?

Regards,
Salvatore

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

Hello,

Il giorno mar 20 set 2022 alle ore 13:59 Salvatore Bonaccorso
<carnil@debian.org> ha scritto:
[..]
> Computer Enthusiastic, can you verify the problem as well in a
> non-Debian patched upstream kernel directly from the 5.10.y series
> (latest 5.10.144) and verify the fix there?
>
> Regards,
> Salvatore

I've tested the vanilla kernel 5.10.145 (it was the latest one week
ago) without Debian kernel patches, but using the kernel config file
from the latest kernel for Debian Stable:
- without the Karol's patch: it always fails both suspend to ram and
hibernate to disk with the usual behavior (a very long time to suspend
or hibernate, then it fails on resume with a garbled screen)
- with the Karol's patch: it succeeds both suspend and hibernate and
it correctly resumes afterwards.

The kernel was tested using the following graphic adapter:
Graphics:  Device-1: NVIDIA G96CM [GeForce 9600M GT] driver: nouveau v: kernel
          Device-2: Suyin Acer HD Crystal Eye webcam type: USB driver:
uvcvideo
          Display: x11 server: X.Org 1.20.11 driver: loaded:
modesetting unloaded: fbdev,vesa
          resolution: 1280x800~60Hz
          OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5

Therefore, 5.10.y series of the kernel need to be patched to work
correctly at least with the aforementioned graphic card.

The script I used to compile the kernel are attached for further
reference and verification.

Hope that helps.

[-- Attachment #2: vanilla-kernel-build-5.10.145 --]
[-- Type: application/octet-stream, Size: 572 bytes --]

# Download source code
wget -nc https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.145.tar.xz
tar xf linux-5.10.145.tar.xz

# Automate subversion index
SUBVERSION_INDEX="1"

# Delete from previous builds
cd linux-5.10.145
rm -rf ./debian
rm -rf ../linux.orig/
rm -rf ../linux-upstream*

cp /boot/config-5.10.0-18-amd64 .config
make olddefconfig

scripts/config --disable SYSTEM_TRUSTED_KEYRING
scripts/config --set-str SYSTEM_TRUSTED_KEYS ''

# Build kernel
time make -j 8 deb-pkg LOCALVERSION=-vanilla KDEB_PKGVERSION=$(make kernelversion)-$SUBVERSION_INDEX

exit 0

[-- Attachment #3: vanilla-kernel-build-5.10.145-patched --]
[-- Type: application/octet-stream, Size: 781 bytes --]

# Download source code
wget -nc https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.145.tar.xz
tar xf linux-5.10.145.tar.xz

# get patch
wget nc -O nouveau.patch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=3640cdccbe75b8922e5bfc0191dd37e3aaa24833

# Automate subversion index
SUBVERSION_INDEX="1"

# Delete from previous builds
cd linux-5.10.145
rm -rf ./debian
rm -rf ../linux.orig/
rm -rf ../linux-upstream*

cp /boot/config-5.10.0-18-amd64 .config
make olddefconfig

scripts/config --disable SYSTEM_TRUSTED_KEYRING
scripts/config --set-str SYSTEM_TRUSTED_KEYS ''

# Apply patch
patch -p 1 < ../nouveau.patch || exit 1

# Build kernel
time make -j 8 deb-pkg LOCALVERSION=-patched KDEB_PKGVERSION=$(make kernelversion)-$SUBVERSION_INDEX

exit 0

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

Hello,

Il giorno mar 20 set 2022 alle ore 13:59 Salvatore Bonaccorso
<carnil@debian.org> ha scritto:
[..]
> Computer Enthusiastic, can you verify the problem as well in a
> non-Debian patched upstream kernel directly from the 5.10.y series
> (latest 5.10.144) and verify the fix there?
>
> Regards,
> Salvatore

I've tested the vanilla kernel 5.10.145 (it was the latest one week
ago) without Debian kernel patches, but using the kernel config file
from the latest kernel for Debian Stable:
- without the Karol's patch: it always fails both suspend to ram and
hibernate to disk with the usual behavior (a very long time to suspend
or hibernate, then it fails on resume with a garbled screen)
- with the Karol's patch: it succeeds both suspend and hibernate and
it correctly resumes afterwards.

The kernel was tested using the following graphic adapter:
Graphics:  Device-1: NVIDIA G96CM [GeForce 9600M GT] driver: nouveau v: kernel
          Device-2: Suyin Acer HD Crystal Eye webcam type: USB driver:
uvcvideo
          Display: x11 server: X.Org 1.20.11 driver: loaded:
modesetting unloaded: fbdev,vesa
          resolution: 1280x800~60Hz
          OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5

Therefore, 5.10.y series of the kernel need to be patched to work
correctly at least with the aforementioned graphic card.

The script I used to compile the kernel are attached for further
reference and verification.

Hope that helps.

[-- Attachment #2: vanilla-kernel-build-5.10.145 --]
[-- Type: application/octet-stream, Size: 572 bytes --]

# Download source code
wget -nc https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.145.tar.xz
tar xf linux-5.10.145.tar.xz

# Automate subversion index
SUBVERSION_INDEX="1"

# Delete from previous builds
cd linux-5.10.145
rm -rf ./debian
rm -rf ../linux.orig/
rm -rf ../linux-upstream*

cp /boot/config-5.10.0-18-amd64 .config
make olddefconfig

scripts/config --disable SYSTEM_TRUSTED_KEYRING
scripts/config --set-str SYSTEM_TRUSTED_KEYS ''

# Build kernel
time make -j 8 deb-pkg LOCALVERSION=-vanilla KDEB_PKGVERSION=$(make kernelversion)-$SUBVERSION_INDEX

exit 0

[-- Attachment #3: vanilla-kernel-build-5.10.145-patched --]
[-- Type: application/octet-stream, Size: 781 bytes --]

# Download source code
wget -nc https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.145.tar.xz
tar xf linux-5.10.145.tar.xz

# get patch
wget nc -O nouveau.patch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=3640cdccbe75b8922e5bfc0191dd37e3aaa24833

# Automate subversion index
SUBVERSION_INDEX="1"

# Delete from previous builds
cd linux-5.10.145
rm -rf ./debian
rm -rf ../linux.orig/
rm -rf ../linux-upstream*

cp /boot/config-5.10.0-18-amd64 .config
make olddefconfig

scripts/config --disable SYSTEM_TRUSTED_KEYRING
scripts/config --set-str SYSTEM_TRUSTED_KEYS ''

# Apply patch
patch -p 1 < ../nouveau.patch || exit 1

# Build kernel
time make -j 8 deb-pkg LOCALVERSION=-patched KDEB_PKGVERSION=$(make kernelversion)-$SUBVERSION_INDEX

exit 0

Re: [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

Hello,

Il giorno mar 20 set 2022 alle ore 13:59 Salvatore Bonaccorso
<carnil@debian.org> ha scritto:
[..]
> Computer Enthusiastic, can you verify the problem as well in a
> non-Debian patched upstream kernel directly from the 5.10.y series
> (latest 5.10.144) and verify the fix there?
>
> Regards,
> Salvatore

I've tested the vanilla kernel 5.10.145 (it was the latest one week
ago) without Debian kernel patches, but using the kernel config file
from the latest kernel for Debian Stable:
- without the Karol's patch: it always fails both suspend to ram and
hibernate to disk with the usual behavior (a very long time to suspend
or hibernate, then it fails on resume with a garbled screen)
- with the Karol's patch: it succeeds both suspend and hibernate and
it correctly resumes afterwards.

The kernel was tested using the following graphic adapter:
Graphics:  Device-1: NVIDIA G96CM [GeForce 9600M GT] driver: nouveau v: kernel
          Device-2: Suyin Acer HD Crystal Eye webcam type: USB driver:
uvcvideo
          Display: x11 server: X.Org 1.20.11 driver: loaded:
modesetting unloaded: fbdev,vesa
          resolution: 1280x800~60Hz
          OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5

Therefore, 5.10.y series of the kernel need to be patched to work
correctly at least with the aforementioned graphic card.

The script I used to compile the kernel are attached for further
reference and verification.

Hope that helps.

[-- Attachment #2: vanilla-kernel-build-5.10.145 --]
[-- Type: application/octet-stream, Size: 572 bytes --]

# Download source code
wget -nc https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.145.tar.xz
tar xf linux-5.10.145.tar.xz

# Automate subversion index
SUBVERSION_INDEX="1"

# Delete from previous builds
cd linux-5.10.145
rm -rf ./debian
rm -rf ../linux.orig/
rm -rf ../linux-upstream*

cp /boot/config-5.10.0-18-amd64 .config
make olddefconfig

scripts/config --disable SYSTEM_TRUSTED_KEYRING
scripts/config --set-str SYSTEM_TRUSTED_KEYS ''

# Build kernel
time make -j 8 deb-pkg LOCALVERSION=-vanilla KDEB_PKGVERSION=$(make kernelversion)-$SUBVERSION_INDEX

exit 0

[-- Attachment #3: vanilla-kernel-build-5.10.145-patched --]
[-- Type: application/octet-stream, Size: 781 bytes --]

# Download source code
wget -nc https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.145.tar.xz
tar xf linux-5.10.145.tar.xz

# get patch
wget nc -O nouveau.patch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=3640cdccbe75b8922e5bfc0191dd37e3aaa24833

# Automate subversion index
SUBVERSION_INDEX="1"

# Delete from previous builds
cd linux-5.10.145
rm -rf ./debian
rm -rf ../linux.orig/
rm -rf ../linux-upstream*

cp /boot/config-5.10.0-18-amd64 .config
make olddefconfig

scripts/config --disable SYSTEM_TRUSTED_KEYRING
scripts/config --set-str SYSTEM_TRUSTED_KEYS ''

# Apply patch
patch -p 1 < ../nouveau.patch || exit 1

# Build kernel
time make -j 8 deb-pkg LOCALVERSION=-patched KDEB_PKGVERSION=$(make kernelversion)-$SUBVERSION_INDEX

exit 0

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello,

Il giorno ven 19 ago 2022 alle ore 22:09 Karol Herbst
<kherbst@redhat.com> ha scritto:
>
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
>
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>                 if (ret == 0) {
>                         ret = nouveau_fence_new(chan, false, &fence);
>                         if (ret == 0) {
> +                               /* TODO: figure out a better solution here
> +                                *
> +                                * wait on the fence here explicitly as going through
> +                                * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +                                *
> +                                * Without this the operation can timeout and we'll fallback to a
> +                                * software copy, which might take several minutes to finish.
> +                                */
> +                               nouveau_fence_wait(fence, false, false);
>                                 ret = ttm_bo_move_accel_cleanup(bo,
>                                                                 &fence->base,
>                                                                 evict, false,
> --
> 2.37.1
>

Do you think it could be possible to make the patch land in kernel
5.10.x in the near future ?

Is there something I can do to help it to happen ?

Thanks.

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Karol Herbst]

On Tue, Nov 1, 2022 at 7:45 AM Computer Enthusiastic
<computer.enthusiastic@gmail.com> wrote:
>
> Hello,
>
> Il giorno ven 19 ago 2022 alle ore 22:09 Karol Herbst
> <kherbst@redhat.com> ha scritto:
> >
> > It is a bit unlcear to us why that's helping, but it does and unbreaks
> > suspend/resume on a lot of GPUs without any known drawbacks.
> >
> > Cc: stable@vger.kernel.org # v5.15+
> > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> > Signed-off-by: Karol Herbst <kherbst@redhat.com>
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 35bb0bb3fe61..126b3c6e12f9 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
> >                 if (ret == 0) {
> >                         ret = nouveau_fence_new(chan, false, &fence);
> >                         if (ret == 0) {
> > +                               /* TODO: figure out a better solution here
> > +                                *
> > +                                * wait on the fence here explicitly as going through
> > +                                * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> > +                                *
> > +                                * Without this the operation can timeout and we'll fallback to a
> > +                                * software copy, which might take several minutes to finish.
> > +                                */
> > +                               nouveau_fence_wait(fence, false, false);
> >                                 ret = ttm_bo_move_accel_cleanup(bo,
> >                                                                 &fence->base,
> >                                                                 evict, false,
> > --
> > 2.37.1
> >
>
> Do you think it could be possible to make the patch land in kernel
> 5.10.x in the near future ?
>
> Is there something I can do to help it to happen ?
>

you can send it out to the stable mailing list and I ack it there. I
just totally forgot about it, sorry.

> Thanks.
>

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello,

Il giorno ven 19 ago 2022 alle ore 22:09 Karol Herbst
<kherbst@redhat.com> ha scritto:
>
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
>
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>                 if (ret == 0) {
>                         ret = nouveau_fence_new(chan, false, &fence);
>                         if (ret == 0) {
> +                               /* TODO: figure out a better solution here
> +                                *
> +                                * wait on the fence here explicitly as going through
> +                                * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +                                *
> +                                * Without this the operation can timeout and we'll fallback to a
> +                                * software copy, which might take several minutes to finish.
> +                                */
> +                               nouveau_fence_wait(fence, false, false);
>                                 ret = ttm_bo_move_accel_cleanup(bo,
>                                                                 &fence->base,
>                                                                 evict, false,
> --
> 2.37.1
>

Could it be possible to make land the aforementioned patch to the
5.10.x kernel version ? It is currently for >= 5.15.x kernel version
only.

Thanks.

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello,

Il giorno ven 19 ago 2022 alle ore 22:09 Karol Herbst
<kherbst@redhat.com> ha scritto:
>
> It is a bit unlcear to us why that's helping, but it does and unbreaks
> suspend/resume on a lot of GPUs without any known drawbacks.
>
> Cc: stable@vger.kernel.org # v5.15+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> Signed-off-by: Karol Herbst <kherbst@redhat.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 35bb0bb3fe61..126b3c6e12f9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
>                 if (ret == 0) {
>                         ret = nouveau_fence_new(chan, false, &fence);
>                         if (ret == 0) {
> +                               /* TODO: figure out a better solution here
> +                                *
> +                                * wait on the fence here explicitly as going through
> +                                * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> +                                *
> +                                * Without this the operation can timeout and we'll fallback to a
> +                                * software copy, which might take several minutes to finish.
> +                                */
> +                               nouveau_fence_wait(fence, false, false);
>                                 ret = ttm_bo_move_accel_cleanup(bo,
>                                                                 &fence->base,
>                                                                 evict, false,
> --
> 2.37.1
>

Could it be possible to make land the aforementioned patch to the
5.10.x kernel version ? It is currently for >= 5.15.x kernel version
only.

Thanks.

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello Karol,

Il giorno mar 1 nov 2022 alle ore 11:46 Karol Herbst
<kherbst@redhat.com> ha scritto:
>
> On Tue, Nov 1, 2022 at 7:45 AM Computer Enthusiastic
> <computer.enthusiastic@gmail.com> wrote:
> >
> > Hello,
> >
> > Il giorno ven 19 ago 2022 alle ore 22:09 Karol Herbst
> > <kherbst@redhat.com> ha scritto:
> > >
> > > It is a bit unlcear to us why that's helping, but it does and unbreaks
> > > suspend/resume on a lot of GPUs without any known drawbacks.
> > >
> > > Cc: stable@vger.kernel.org # v5.15+
> > > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
> > > Signed-off-by: Karol Herbst <kherbst@redhat.com>
> > > ---
> > >  drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index 35bb0bb3fe61..126b3c6e12f9 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -822,6 +822,15 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
> > >                 if (ret == 0) {
> > >                         ret = nouveau_fence_new(chan, false, &fence);
> > >                         if (ret == 0) {
> > > +                               /* TODO: figure out a better solution here
> > > +                                *
> > > +                                * wait on the fence here explicitly as going through
> > > +                                * ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
> > > +                                *
> > > +                                * Without this the operation can timeout and we'll fallback to a
> > > +                                * software copy, which might take several minutes to finish.
> > > +                                */
> > > +                               nouveau_fence_wait(fence, false, false);
> > >                                 ret = ttm_bo_move_accel_cleanup(bo,
> > >                                                                 &fence->base,
> > >                                                                 evict, false,
> > > --
> > > 2.37.1
> > >
> >
> > Do you think it could be possible to make the patch land in kernel
> > 5.10.x in the near future ?
> >
> > Is there something I can do to help it to happen ?
> >
>
> you can send it out to the stable mailing list and I ack it there. I
> just totally forgot about it, sorry.
>
> > Thanks.
> >

As you suggested, I sent a request to a request to linux-kernel [1],
but it was not acknowledged.

What else can I do to help the patch land in the 5.10.x kernel in the future ?

Thanks and happy Christmas.

[1] https://marc.info/?l=linux-kernel&m=166883482714930&w=2

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello,

The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in 
nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was 
merged upstream.

The same patch [1] works with kernel 5.10.y, but it is not been merged 
upstream so far.

According to Karol Herbst suggestion [2], I'm sending this message to 
ask for merging it into 5.10 kernel.

Thanks in advance.

---
[1] 
https://lore.kernel.org/nouveau/20220819200928.401416-1-kherbst@redhat.com/

[2] 
https://lore.kernel.org/nouveau/CACO55tv0jO2TmuWcwFiAUQB-__DZVwhv7WNN9MfgMXV053gknw@mail.gmail.com/

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello,

The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in 
nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was 
merged upstream.

The same patch [1] works with kernel 5.10.y, but it is not been merged 
upstream so far.

According to Karol Herbst suggestion [2], I'm sending this message to 
ask for merging it into 5.10 kernel.

Thanks in advance.

---
[1] 
https://lore.kernel.org/nouveau/20220819200928.401416-1-kherbst@redhat.com/

[2] 
https://lore.kernel.org/nouveau/CACO55tv0jO2TmuWcwFiAUQB-__DZVwhv7WNN9MfgMXV053gknw@mail.gmail.com/

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Greg KH]

On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
> Hello,
> 
> The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
> nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
> upstream.
> 
> The same patch [1] works with kernel 5.10.y, but it is not been merged
> upstream so far.
> 
> According to Karol Herbst suggestion [2], I'm sending this message to ask
> for merging it into 5.10 kernel.

We need to know the git commit id.  And have you tested it on 5.10.y?
And why are you stuck on 5.10.y for this type of hardware?  Why not move
to 5.15.y or 6.1.y?

And as my bot says:

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

thanks,

greg k-h

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Greg KH]

On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
> Hello,
> 
> The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
> nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
> upstream.
> 
> The same patch [1] works with kernel 5.10.y, but it is not been merged
> upstream so far.
> 
> According to Karol Herbst suggestion [2], I'm sending this message to ask
> for merging it into 5.10 kernel.

We need to know the git commit id.  And have you tested it on 5.10.y?
And why are you stuck on 5.10.y for this type of hardware?  Why not move
to 5.15.y or 6.1.y?

And as my bot says:

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

thanks,

greg k-h

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Salvatore Bonaccorso]

Hi Greg,

I'm not the reporter, so would like to confirm him explicitly, but I
believe I can give some context:

On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
> On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
> > Hello,
> > 
> > The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
> > nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
> > upstream.
> > 
> > The same patch [1] works with kernel 5.10.y, but it is not been merged
> > upstream so far.
> > 
> > According to Karol Herbst suggestion [2], I'm sending this message to ask
> > for merging it into 5.10 kernel.
> 
> We need to know the git commit id.  And have you tested it on 5.10.y?
> And why are you stuck on 5.10.y for this type of hardware?  Why not move
> to 5.15.y or 6.1.y?

This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
backported to 5.19.6 and 5.15.64.

Computer Enthusiastic, tested it on 5.10.y: 
https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/

It was reported in Debian by the user originally as
https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
bullseye.

I guess the user could move to the next stable release Debian bookworm, once
it's released (it's currently in the last milestones to finalize, cf.
https://release.debian.org/ but we are not yet there). In the next release this
will be automatically be fixed indeed.

Computer Enthusiastic, can you confirm please to Greg in particular the first
questions, in particular to confirm the commit fixes the suspend issue?

Regards,
Salvatore

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Salvatore Bonaccorso]

Hi Greg,

I'm not the reporter, so would like to confirm him explicitly, but I
believe I can give some context:

On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
> On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
> > Hello,
> > 
> > The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
> > nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
> > upstream.
> > 
> > The same patch [1] works with kernel 5.10.y, but it is not been merged
> > upstream so far.
> > 
> > According to Karol Herbst suggestion [2], I'm sending this message to ask
> > for merging it into 5.10 kernel.
> 
> We need to know the git commit id.  And have you tested it on 5.10.y?
> And why are you stuck on 5.10.y for this type of hardware?  Why not move
> to 5.15.y or 6.1.y?

This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
backported to 5.19.6 and 5.15.64.

Computer Enthusiastic, tested it on 5.10.y: 
https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/

It was reported in Debian by the user originally as
https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
bullseye.

I guess the user could move to the next stable release Debian bookworm, once
it's released (it's currently in the last milestones to finalize, cf.
https://release.debian.org/ but we are not yet there). In the next release this
will be automatically be fixed indeed.

Computer Enthusiastic, can you confirm please to Greg in particular the first
questions, in particular to confirm the commit fixes the suspend issue?

Regards,
Salvatore

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello Greg,
Hello Salvatore,

On 28/01/2023 20:49, Salvatore Bonaccorso wrote:
> Hi Greg,
> 
> I'm not the reporter, so would like to confirm him explicitly, but I
> believe I can give some context:
> 
> On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
>> On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
>>> Hello,
>>>
>>> The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
>>> nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
>>> upstream.
>>>
>>> The same patch [1] works with kernel 5.10.y, but it is not been merged
>>> upstream so far.
>>>
>>> According to Karol Herbst suggestion [2], I'm sending this message to ask
>>> for merging it into 5.10 kernel.
>>
>> We need to know the git commit id.  And have you tested it on 5.10.y?
>> And why are you stuck on 5.10.y for this type of hardware?  Why not move
>> to 5.15.y or 6.1.y?
> 
> This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
> fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
> backported to 5.19.6 and 5.15.64.
> 
> Computer Enthusiastic, tested it on 5.10.y:
> https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/
> 
> It was reported in Debian by the user originally as
> https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
> bullseye.
> 
> I guess the user could move to the next stable release Debian bookworm, once
> it's released (it's currently in the last milestones to finalize, cf.
> https://release.debian.org/ but we are not yet there). In the next release this
> will be automatically be fixed indeed.
> 
> Computer Enthusiastic, can you confirm please to Greg in particular the first
> questions, in particular to confirm the commit fixes the suspend issue?
> 
> Regards,
> Salvatore

Thanks for replaying to my request: I really appreciate.

I apologize if my request was not formally correct.

The upstream kernel 5.10.y hangs on suspend or fails to resume if it is 
suspended to ram or suspended to disk (if nouveau kernel module is used 
with some nvidia graphic cards).

I confirm the commit ID 6b04ce966a73 (by Karol Herbst) fixes the 
aforementioned suspend to ram and suspend to disk issues with kernel 
5.10.y . It tested it with my own computer.

The last kernel version I tested is 5.10.165, that I patched and 
installed in Debian Stable (11.6) that I'm currently running and that I 
tested again today.

It would be nice if the next point release of Debian Stable could ship a 
kernel that includes patch commit ID 6b04ce966a73 for the benefit of 
nouveau module users.

Thanks again.

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello Greg,
Hello Salvatore,

On 28/01/2023 20:49, Salvatore Bonaccorso wrote:
> Hi Greg,
> 
> I'm not the reporter, so would like to confirm him explicitly, but I
> believe I can give some context:
> 
> On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
>> On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
>>> Hello,
>>>
>>> The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
>>> nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
>>> upstream.
>>>
>>> The same patch [1] works with kernel 5.10.y, but it is not been merged
>>> upstream so far.
>>>
>>> According to Karol Herbst suggestion [2], I'm sending this message to ask
>>> for merging it into 5.10 kernel.
>>
>> We need to know the git commit id.  And have you tested it on 5.10.y?
>> And why are you stuck on 5.10.y for this type of hardware?  Why not move
>> to 5.15.y or 6.1.y?
> 
> This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
> fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
> backported to 5.19.6 and 5.15.64.
> 
> Computer Enthusiastic, tested it on 5.10.y:
> https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/
> 
> It was reported in Debian by the user originally as
> https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
> bullseye.
> 
> I guess the user could move to the next stable release Debian bookworm, once
> it's released (it's currently in the last milestones to finalize, cf.
> https://release.debian.org/ but we are not yet there). In the next release this
> will be automatically be fixed indeed.
> 
> Computer Enthusiastic, can you confirm please to Greg in particular the first
> questions, in particular to confirm the commit fixes the suspend issue?
> 
> Regards,
> Salvatore

Thanks for replaying to my request: I really appreciate.

I apologize if my request was not formally correct.

The upstream kernel 5.10.y hangs on suspend or fails to resume if it is 
suspended to ram or suspended to disk (if nouveau kernel module is used 
with some nvidia graphic cards).

I confirm the commit ID 6b04ce966a73 (by Karol Herbst) fixes the 
aforementioned suspend to ram and suspend to disk issues with kernel 
5.10.y . It tested it with my own computer.

The last kernel version I tested is 5.10.165, that I patched and 
installed in Debian Stable (11.6) that I'm currently running and that I 
tested again today.

It would be nice if the next point release of Debian Stable could ship a 
kernel that includes patch commit ID 6b04ce966a73 for the benefit of 
nouveau module users.

Thanks again.

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Greg KH]

On Sun, Jan 29, 2023 at 10:36:31PM +0100, Computer Enthusiastic wrote:
> Hello Greg,
> Hello Salvatore,
> 
> On 28/01/2023 20:49, Salvatore Bonaccorso wrote:
> > Hi Greg,
> > 
> > I'm not the reporter, so would like to confirm him explicitly, but I
> > believe I can give some context:
> > 
> > On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
> > > On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
> > > > Hello,
> > > > 
> > > > The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
> > > > nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
> > > > upstream.
> > > > 
> > > > The same patch [1] works with kernel 5.10.y, but it is not been merged
> > > > upstream so far.
> > > > 
> > > > According to Karol Herbst suggestion [2], I'm sending this message to ask
> > > > for merging it into 5.10 kernel.
> > > 
> > > We need to know the git commit id.  And have you tested it on 5.10.y?
> > > And why are you stuck on 5.10.y for this type of hardware?  Why not move
> > > to 5.15.y or 6.1.y?
> > 
> > This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
> > fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
> > backported to 5.19.6 and 5.15.64.
> > 
> > Computer Enthusiastic, tested it on 5.10.y:
> > https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/
> > 
> > It was reported in Debian by the user originally as
> > https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
> > bullseye.
> > 
> > I guess the user could move to the next stable release Debian bookworm, once
> > it's released (it's currently in the last milestones to finalize, cf.
> > https://release.debian.org/ but we are not yet there). In the next release this
> > will be automatically be fixed indeed.
> > 
> > Computer Enthusiastic, can you confirm please to Greg in particular the first
> > questions, in particular to confirm the commit fixes the suspend issue?
> > 
> > Regards,
> > Salvatore
> 
> Thanks for replaying to my request: I really appreciate.
> 
> I apologize if my request was not formally correct.
> 
> The upstream kernel 5.10.y hangs on suspend or fails to resume if it is
> suspended to ram or suspended to disk (if nouveau kernel module is used with
> some nvidia graphic cards).
> 
> I confirm the commit ID 6b04ce966a73 (by Karol Herbst) fixes the
> aforementioned suspend to ram and suspend to disk issues with kernel 5.10.y
> . It tested it with my own computer.
> 
> The last kernel version I tested is 5.10.165, that I patched and installed
> in Debian Stable (11.6) that I'm currently running and that I tested again
> today.
> 
> It would be nice if the next point release of Debian Stable could ship a
> kernel that includes patch commit ID 6b04ce966a73 for the benefit of nouveau
> module users.

Ok, I've queued it up for 5.10.y now, thanks.

greg k-h

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Greg KH]

On Sun, Jan 29, 2023 at 10:36:31PM +0100, Computer Enthusiastic wrote:
> Hello Greg,
> Hello Salvatore,
> 
> On 28/01/2023 20:49, Salvatore Bonaccorso wrote:
> > Hi Greg,
> > 
> > I'm not the reporter, so would like to confirm him explicitly, but I
> > believe I can give some context:
> > 
> > On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
> > > On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
> > > > Hello,
> > > > 
> > > > The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
> > > > nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
> > > > upstream.
> > > > 
> > > > The same patch [1] works with kernel 5.10.y, but it is not been merged
> > > > upstream so far.
> > > > 
> > > > According to Karol Herbst suggestion [2], I'm sending this message to ask
> > > > for merging it into 5.10 kernel.
> > > 
> > > We need to know the git commit id.  And have you tested it on 5.10.y?
> > > And why are you stuck on 5.10.y for this type of hardware?  Why not move
> > > to 5.15.y or 6.1.y?
> > 
> > This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
> > fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
> > backported to 5.19.6 and 5.15.64.
> > 
> > Computer Enthusiastic, tested it on 5.10.y:
> > https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/
> > 
> > It was reported in Debian by the user originally as
> > https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
> > bullseye.
> > 
> > I guess the user could move to the next stable release Debian bookworm, once
> > it's released (it's currently in the last milestones to finalize, cf.
> > https://release.debian.org/ but we are not yet there). In the next release this
> > will be automatically be fixed indeed.
> > 
> > Computer Enthusiastic, can you confirm please to Greg in particular the first
> > questions, in particular to confirm the commit fixes the suspend issue?
> > 
> > Regards,
> > Salvatore
> 
> Thanks for replaying to my request: I really appreciate.
> 
> I apologize if my request was not formally correct.
> 
> The upstream kernel 5.10.y hangs on suspend or fails to resume if it is
> suspended to ram or suspended to disk (if nouveau kernel module is used with
> some nvidia graphic cards).
> 
> I confirm the commit ID 6b04ce966a73 (by Karol Herbst) fixes the
> aforementioned suspend to ram and suspend to disk issues with kernel 5.10.y
> . It tested it with my own computer.
> 
> The last kernel version I tested is 5.10.165, that I patched and installed
> in Debian Stable (11.6) that I'm currently running and that I tested again
> today.
> 
> It would be nice if the next point release of Debian Stable could ship a
> kernel that includes patch commit ID 6b04ce966a73 for the benefit of nouveau
> module users.

Ok, I've queued it up for 5.10.y now, thanks.

greg k-h

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Lyude Paul]

Thanks a ton for the help Greg!

On Mon, 2023-01-30 at 11:05 +0100, Greg KH wrote:
> On Sun, Jan 29, 2023 at 10:36:31PM +0100, Computer Enthusiastic wrote:
> > Hello Greg,
> > Hello Salvatore,
> > 
> > On 28/01/2023 20:49, Salvatore Bonaccorso wrote:
> > > Hi Greg,
> > > 
> > > I'm not the reporter, so would like to confirm him explicitly, but I
> > > believe I can give some context:
> > > 
> > > On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
> > > > On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
> > > > > Hello,
> > > > > 
> > > > > The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
> > > > > nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
> > > > > upstream.
> > > > > 
> > > > > The same patch [1] works with kernel 5.10.y, but it is not been merged
> > > > > upstream so far.
> > > > > 
> > > > > According to Karol Herbst suggestion [2], I'm sending this message to ask
> > > > > for merging it into 5.10 kernel.
> > > > 
> > > > We need to know the git commit id.  And have you tested it on 5.10.y?
> > > > And why are you stuck on 5.10.y for this type of hardware?  Why not move
> > > > to 5.15.y or 6.1.y?
> > > 
> > > This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
> > > fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
> > > backported to 5.19.6 and 5.15.64.
> > > 
> > > Computer Enthusiastic, tested it on 5.10.y:
> > > https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/
> > > 
> > > It was reported in Debian by the user originally as
> > > https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
> > > bullseye.
> > > 
> > > I guess the user could move to the next stable release Debian bookworm, once
> > > it's released (it's currently in the last milestones to finalize, cf.
> > > https://release.debian.org/ but we are not yet there). In the next release this
> > > will be automatically be fixed indeed.
> > > 
> > > Computer Enthusiastic, can you confirm please to Greg in particular the first
> > > questions, in particular to confirm the commit fixes the suspend issue?
> > > 
> > > Regards,
> > > Salvatore
> > 
> > Thanks for replaying to my request: I really appreciate.
> > 
> > I apologize if my request was not formally correct.
> > 
> > The upstream kernel 5.10.y hangs on suspend or fails to resume if it is
> > suspended to ram or suspended to disk (if nouveau kernel module is used with
> > some nvidia graphic cards).
> > 
> > I confirm the commit ID 6b04ce966a73 (by Karol Herbst) fixes the
> > aforementioned suspend to ram and suspend to disk issues with kernel 5.10.y
> > . It tested it with my own computer.
> > 
> > The last kernel version I tested is 5.10.165, that I patched and installed
> > in Debian Stable (11.6) that I'm currently running and that I tested again
> > today.
> > 
> > It would be nice if the next point release of Debian Stable could ship a
> > kernel that includes patch commit ID 6b04ce966a73 for the benefit of nouveau
> > module users.
> 
> Ok, I've queued it up for 5.10.y now, thanks.
> 
> greg k-h
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Lyude Paul]

Thanks a ton for the help Greg!

On Mon, 2023-01-30 at 11:05 +0100, Greg KH wrote:
> On Sun, Jan 29, 2023 at 10:36:31PM +0100, Computer Enthusiastic wrote:
> > Hello Greg,
> > Hello Salvatore,
> > 
> > On 28/01/2023 20:49, Salvatore Bonaccorso wrote:
> > > Hi Greg,
> > > 
> > > I'm not the reporter, so would like to confirm him explicitly, but I
> > > believe I can give some context:
> > > 
> > > On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
> > > > On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
> > > > > Hello,
> > > > > 
> > > > > The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
> > > > > nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
> > > > > upstream.
> > > > > 
> > > > > The same patch [1] works with kernel 5.10.y, but it is not been merged
> > > > > upstream so far.
> > > > > 
> > > > > According to Karol Herbst suggestion [2], I'm sending this message to ask
> > > > > for merging it into 5.10 kernel.
> > > > 
> > > > We need to know the git commit id.  And have you tested it on 5.10.y?
> > > > And why are you stuck on 5.10.y for this type of hardware?  Why not move
> > > > to 5.15.y or 6.1.y?
> > > 
> > > This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
> > > fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
> > > backported to 5.19.6 and 5.15.64.
> > > 
> > > Computer Enthusiastic, tested it on 5.10.y:
> > > https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/
> > > 
> > > It was reported in Debian by the user originally as
> > > https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
> > > bullseye.
> > > 
> > > I guess the user could move to the next stable release Debian bookworm, once
> > > it's released (it's currently in the last milestones to finalize, cf.
> > > https://release.debian.org/ but we are not yet there). In the next release this
> > > will be automatically be fixed indeed.
> > > 
> > > Computer Enthusiastic, can you confirm please to Greg in particular the first
> > > questions, in particular to confirm the commit fixes the suspend issue?
> > > 
> > > Regards,
> > > Salvatore
> > 
> > Thanks for replaying to my request: I really appreciate.
> > 
> > I apologize if my request was not formally correct.
> > 
> > The upstream kernel 5.10.y hangs on suspend or fails to resume if it is
> > suspended to ram or suspended to disk (if nouveau kernel module is used with
> > some nvidia graphic cards).
> > 
> > I confirm the commit ID 6b04ce966a73 (by Karol Herbst) fixes the
> > aforementioned suspend to ram and suspend to disk issues with kernel 5.10.y
> > . It tested it with my own computer.
> > 
> > The last kernel version I tested is 5.10.165, that I patched and installed
> > in Debian Stable (11.6) that I'm currently running and that I tested again
> > today.
> > 
> > It would be nice if the next point release of Debian Stable could ship a
> > kernel that includes patch commit ID 6b04ce966a73 for the benefit of nouveau
> > module users.
> 
> Ok, I've queued it up for 5.10.y now, thanks.
> 
> greg k-h
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello Greg,

On 30/01/2023 23:27, Lyude Paul wrote:
> Thanks a ton for the help Greg!
> 
> On Mon, 2023-01-30 at 11:05 +0100, Greg KH wrote:
>> On Sun, Jan 29, 2023 at 10:36:31PM +0100, Computer Enthusiastic wrote:
>>> Hello Greg,
>>> Hello Salvatore,
>>>
>>> On 28/01/2023 20:49, Salvatore Bonaccorso wrote:
>>>> Hi Greg,
>>>>
>>>> I'm not the reporter, so would like to confirm him explicitly, but I
>>>> believe I can give some context:
>>>>
>>>> On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
>>>>> On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
>>>>>> Hello,
>>>>>>
>>>>>> The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
>>>>>> nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
>>>>>> upstream.
>>>>>>
>>>>>> The same patch [1] works with kernel 5.10.y, but it is not been merged
>>>>>> upstream so far.
>>>>>>
>>>>>> According to Karol Herbst suggestion [2], I'm sending this message to ask
>>>>>> for merging it into 5.10 kernel.
>>>>>
>>>>> We need to know the git commit id.  And have you tested it on 5.10.y?
>>>>> And why are you stuck on 5.10.y for this type of hardware?  Why not move
>>>>> to 5.15.y or 6.1.y?
>>>>
>>>> This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
>>>> fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
>>>> backported to 5.19.6 and 5.15.64.
>>>>
>>>> Computer Enthusiastic, tested it on 5.10.y:
>>>> https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/
>>>>
>>>> It was reported in Debian by the user originally as
>>>> https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
>>>> bullseye.
>>>>
>>>> I guess the user could move to the next stable release Debian bookworm, once
>>>> it's released (it's currently in the last milestones to finalize, cf.
>>>> https://release.debian.org/ but we are not yet there). In the next release this
>>>> will be automatically be fixed indeed.
>>>>
>>>> Computer Enthusiastic, can you confirm please to Greg in particular the first
>>>> questions, in particular to confirm the commit fixes the suspend issue?
>>>>
>>>> Regards,
>>>> Salvatore
>>>
>>> Thanks for replaying to my request: I really appreciate.
>>>
>>> I apologize if my request was not formally correct.
>>>
>>> The upstream kernel 5.10.y hangs on suspend or fails to resume if it is
>>> suspended to ram or suspended to disk (if nouveau kernel module is used with
>>> some nvidia graphic cards).
>>>
>>> I confirm the commit ID 6b04ce966a73 (by Karol Herbst) fixes the
>>> aforementioned suspend to ram and suspend to disk issues with kernel 5.10.y
>>> . It tested it with my own computer.
>>>
>>> The last kernel version I tested is 5.10.165, that I patched and installed
>>> in Debian Stable (11.6) that I'm currently running and that I tested again
>>> today.
>>>
>>> It would be nice if the next point release of Debian Stable could ship a
>>> kernel that includes patch commit ID 6b04ce966a73 for the benefit of nouveau
>>> module users.
>>
>> Ok, I've queued it up for 5.10.y now, thanks.
>>
>> greg k-h
>>

Thank you so much.

Many thanks to Salvatore for the help and, of course, to Karl for the 
patch and to all of you who made it possible.

Re: [Nouveau] [PATCH] nouveau: explicitly wait on the fence in nouveau_bo_move_m2mf

[Computer Enthusiastic]

Hello Greg,

On 30/01/2023 23:27, Lyude Paul wrote:
> Thanks a ton for the help Greg!
> 
> On Mon, 2023-01-30 at 11:05 +0100, Greg KH wrote:
>> On Sun, Jan 29, 2023 at 10:36:31PM +0100, Computer Enthusiastic wrote:
>>> Hello Greg,
>>> Hello Salvatore,
>>>
>>> On 28/01/2023 20:49, Salvatore Bonaccorso wrote:
>>>> Hi Greg,
>>>>
>>>> I'm not the reporter, so would like to confirm him explicitly, but I
>>>> believe I can give some context:
>>>>
>>>> On Sat, Jan 28, 2023 at 06:51:08PM +0100, Greg KH wrote:
>>>>> On Sat, Jan 28, 2023 at 03:49:59PM +0100, Computer Enthusiastic wrote:
>>>>>> Hello,
>>>>>>
>>>>>> The patch "[Nouveau] [PATCH] nouveau: explicitly wait on the fence in
>>>>>> nouveau_bo_move_m2mf" [1] was marked for kernels v5.15+ and it was merged
>>>>>> upstream.
>>>>>>
>>>>>> The same patch [1] works with kernel 5.10.y, but it is not been merged
>>>>>> upstream so far.
>>>>>>
>>>>>> According to Karol Herbst suggestion [2], I'm sending this message to ask
>>>>>> for merging it into 5.10 kernel.
>>>>>
>>>>> We need to know the git commit id.  And have you tested it on 5.10.y?
>>>>> And why are you stuck on 5.10.y for this type of hardware?  Why not move
>>>>> to 5.15.y or 6.1.y?
>>>>
>>>> This would be commit 6b04ce966a73 ("nouveau: explicitly wait on the
>>>> fence in nouveau_bo_move_m2mf") in mainline, applied in 6.0-rc3 and
>>>> backported to 5.19.6 and 5.15.64.
>>>>
>>>> Computer Enthusiastic, tested it on 5.10.y:
>>>> https://lore.kernel.org/nouveau/CAHSpYy1mcTns0JS6eivjK82CZ9_ajSwH-H7gtDwCkNyfvihaAw@mail.gmail.com/
>>>>
>>>> It was reported in Debian by the user originally as
>>>> https://bugs.debian.org/989705#69 after updating to the 5.10.y series in Debian
>>>> bullseye.
>>>>
>>>> I guess the user could move to the next stable release Debian bookworm, once
>>>> it's released (it's currently in the last milestones to finalize, cf.
>>>> https://release.debian.org/ but we are not yet there). In the next release this
>>>> will be automatically be fixed indeed.
>>>>
>>>> Computer Enthusiastic, can you confirm please to Greg in particular the first
>>>> questions, in particular to confirm the commit fixes the suspend issue?
>>>>
>>>> Regards,
>>>> Salvatore
>>>
>>> Thanks for replaying to my request: I really appreciate.
>>>
>>> I apologize if my request was not formally correct.
>>>
>>> The upstream kernel 5.10.y hangs on suspend or fails to resume if it is
>>> suspended to ram or suspended to disk (if nouveau kernel module is used with
>>> some nvidia graphic cards).
>>>
>>> I confirm the commit ID 6b04ce966a73 (by Karol Herbst) fixes the
>>> aforementioned suspend to ram and suspend to disk issues with kernel 5.10.y
>>> . It tested it with my own computer.
>>>
>>> The last kernel version I tested is 5.10.165, that I patched and installed
>>> in Debian Stable (11.6) that I'm currently running and that I tested again
>>> today.
>>>
>>> It would be nice if the next point release of Debian Stable could ship a
>>> kernel that includes patch commit ID 6b04ce966a73 for the benefit of nouveau
>>> module users.
>>
>> Ok, I've queued it up for 5.10.y now, thanks.
>>
>> greg k-h
>>

Thank you so much.

Many thanks to Salvatore for the help and, of course, to Karl for the 
patch and to all of you who made it possible.