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-__DZVwhv7WNN9MfgMXV...
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
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-H7gtDwCkNy...
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
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-H7gtDwCkNy...
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.
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-H7gtDwCkNy...
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
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-H7gtDwCkNy...
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
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-H7gtDwCkNy...
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.
linux-stable-mirror@lists.linaro.org
-
Computer Enthusiastic -
Greg KH -
Lyude Paul -
Salvatore Bonaccorso