Bug#989705: closing 989705
Hello Salvatore, On Tue, 4 Oct 2022 19:39:23 +0200 Computer Enthusiastic wrote: Hello Salvatore, Il giorno mar 20 set 2022 alle ore 12:32 Salvatore Bonaccorso ha scritto: > > Hi, [..] > > > > What could be done to make the patch land in the current Debian Stable > > (Bullseye) kernel release ? > > It should land in the 5.10.y stable series which we will then pick up > automatically on next rebases. But what is puzzling is that the commit > has been marked for stable only v5.15+. If you were able to confirm it > is actually present in 5.10.y as well then it needs a followup to be > picked as well for the 5.10.y stable series. > > Regards, > Salvatore Yes, the patch is marked as only v5.15+, but the issue is still there in kernel 5.10, too. As you suggested, I have tested the vanilla kernel 5.10.145 with and without kernel patches, as reported here [0]. Thanks. [0] https://lists.freedesktop.org/archives/nouveau/2022-September/041182.html Thank you for supporting me to explain upstream the request for backporting the patch to 5.10.y. The patch has been backported to Linux 5.10.166 few days ago [1]. I suppose it will hopefully be available in the Linux kernel shipped with the next Debian point release. --- [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.10.166
Re: Request to cherry picking a patch to fix bug #989705 for kernels 5.10.y
Hello Diederik, On 27/01/2023 22:35, Diederik de Haas wrote: On Friday, 27 January 2023 21:05:47 CET Computer Enthusiastic wrote: This patch [2] applies to kernel version 5.10.y, too. I used it with a custom built kernel since it was published . The author of the patch acknowledged that the patch applies to kernel version 5.10.y asking me to send it out to the stable mailing list. I did it, but I did not receive an answer. I tried to peek upstream, but again no answer. I noticed in [2] this: "Cc: sta...@vger.kernel.org # v5.15+" The post on marc.info (try to use lore.kernel.org links as that works easier for most people) seems to be posted to the 'linux-kernel' list, which I *think* is not the same as 'sta...@vger.kernel.org'. So I would suggest to try again by sending it to stable.vger.k.o with explicit mention of kernel 5.10. GKH is a busy man so I recommend to take your time to construct an email which is as short as possible, but still contains all the info needed to evaluate the request. I would recommend to mention the following things: Commit ID in 5.15 = 3640cdccbe75b8922e5bfc0191dd37e3aaa24833 Link to post in which the patch author said they'd ACK it for 5.10: https://lore.kernel.org/all/caco55tv0jo2tmuwcwfiauqb-__dzvwhv7wnn9mfgmxv053g...@mail.gmail.com/ In your mail make sure the link doesn't break over 2 lines like it does above. HTH, Diederik --- [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h =v6.0-rc5&id=6b04ce966a738ecdd9294c9593e48513c0dc90aa Just a feedback. Thanks for your tips. Greg Kroah-Hartman backported the patch into Linux 5.10.166 [1]. Therefore it will hopefully land in the next Debian stable point release when it will be released. I would like to thank Salvatore Bonaccorso who helped me to explain Greg the request for backporting the patch: --- [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.166&id=8fe3e574b3ac426ff4a11299f098e1c91538f3e5
Re: Request to cherry picking a patch to fix bug #989705 for kernels 5.10.y
Hello, On 27/01/2023 22:35, Diederik de Haas wrote: On Friday, 27 January 2023 21:05:47 CET Computer Enthusiastic wrote: This patch [2] applies to kernel version 5.10.y, too. I used it with a custom built kernel since it was published . The author of the patch acknowledged that the patch applies to kernel version 5.10.y asking me to send it out to the stable mailing list. I did it, but I did not receive an answer. I tried to peek upstream, but again no answer. I would recommend to mention the following things: Commit ID in 5.15 = 3640cdccbe75b8922e5bfc0191dd37e3aaa24833 Link to post in which the patch author said they'd ACK it for 5.10: https://lore.kernel.org/all/caco55tv0jo2tmuwcwfiauqb-__dzvwhv7wnn9mfgmxv053g...@mail.gmail.com/ In your mail make sure the link doesn't break over 2 lines like it does above. HTH, Diederik Thanks for your suggestions. This [1] is the reference to my new request. I hope I dit it right. --- [1] https://lore.kernel.org/stable/20220819200928.401416-1-kher...@redhat.com/T/#ebac71b81ccec2fb3d1c467e73f4f46667ef75296
Request to cherry picking a patch to fix bug #989705 for kernels 5.10.y
Hello, The bug #989705 [1] is currently closed. It was solved for kernels version 5.15+ using the patch [2] from upstream. This patch [2] applies to kernel version 5.10.y, too. I used it with a custom built kernel since it was published . The author of the patch acknowledged that the patch applies to kernel version 5.10.y asking me to send it out to the stable mailing list. I did it, but I did not receive an answer. I tried to peek upstream, but again no answer. Therefore, I'm sending this post to ask the debian-kernel mailing list if it is possibile to cherry pick the patch [1] to make it land in the next release of Debian Kernel 5.10.y. Let me know if I can help in any way. I cannot update bug #989705 because it is currently closed. Thanks in advance for your attention. --- [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.0-rc5&id=6b04ce966a738ecdd9294c9593e48513c0dc90aa
Bug#989705: closing 989705
Hello Salvatore, Il giorno mar 20 set 2022 alle ore 12:32 Salvatore Bonaccorso ha scritto: > > Hi, [..] > > > > What could be done to make the patch land in the current Debian Stable > > (Bullseye) kernel release ? > > It should land in the 5.10.y stable series which we will then pick up > automatically on next rebases. But what is puzzling is that the commit > has been marked for stable only v5.15+. If you were able to confirm it > is actually present in 5.10.y as well then it needs a followup to be > picked as well for the 5.10.y stable series. > > Regards, > Salvatore Yes, the patch is marked as only v5.15+, but the issue is still there in kernel 5.10, too. As you suggested, I have tested the vanilla kernel 5.10.145 with and without kernel patches, as reported here [0]. Thanks. [0] https://lists.freedesktop.org/archives/nouveau/2022-September/041182.html
Bug#989705: closing 989705
Hello, Il giorno mar 20 set 2022 alle ore 09:33 Salvatore Bonaccorso ha scritto: > > close 989705 5.19.6-1 > thanks What could be done to make the patch land in the current Debian Stable (Bullseye) kernel release ? Thanks.
Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64
Hello, An upstream patch has been released [1] [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.0-rc5&id=6b04ce966a738ecdd9294c9593e48513c0dc90aa
Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64
Hello, To whom it may interests, I've successful tested the patch (see previous message [0]) with Debian kernels version 5.10.0-16-amd64 [1] from bullseye-security and, 5.18.0-0 [2] from bullseye-backports [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#64 [1] http://security.debian.org/debian-security/pool/main/l/linux/linux-image-5.10.0-16-amd64-unsigned_5.10.127-2_amd64.deb [2] https://packages.debian.org/bullseye-backports/linux-image-amd64 .
Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64
Hello,
I've been successfully used an experimental "work in progress" patch
with the kernel version 5.10.113 since last 25 may (see
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/547#note_1438950)
.
I suspended and hibernated the system (Debian GNU/Linux 11.3 with the
aforementioned patch) many times without any issue :
# journalctl -S 2022-05-25 --no-pager | grep -e "PM: suspend
entry\|hibernation: hibernation entry"
May 25 08:39:48 debian kernel: PM: hibernation: hibernation entry
May 26 08:05:44 debian kernel: PM: hibernation: hibernation entry
May 28 12:28:50 debian kernel: PM: suspend entry (deep)
May 28 12:39:52 debian kernel: PM: suspend entry (deep)
May 28 13:34:55 debian kernel: PM: hibernation: hibernation entry
May 28 18:17:35 debian kernel: PM: hibernation: hibernation entry
May 30 08:56:31 debian kernel: PM: hibernation: hibernation entry
Jun 01 22:54:45 debian kernel: PM: hibernation: hibernation entry
Jun 02 17:44:35 debian kernel: PM: suspend entry (deep)
Jun 02 23:49:38 debian kernel: PM: hibernation: hibernation entry
Jun 04 10:54:04 debian kernel: PM: hibernation: hibernation entry
Jun 05 17:34:17 debian kernel: PM: hibernation: hibernation entry
Jun 06 08:18:21 debian kernel: PM: hibernation: hibernation entry
Jun 06 18:11:40 debian kernel: PM: suspend entry (deep)
Jun 06 19:27:39 debian kernel: PM: suspend entry (deep)
Jun 06 23:02:24 debian kernel: PM: hibernation: hibernation entry
Jun 08 08:53:02 debian kernel: PM: hibernation: hibernation entry
Jun 08 08:58:41 debian kernel: PM: suspend entry (deep)
Jun 08 08:59:32 debian kernel: PM: hibernation: hibernation entry
Jun 09 01:11:56 debian kernel: PM: hibernation: hibernation entry
Jun 09 21:08:22 debian kernel: PM: hibernation: hibernation entry
Jun 11 09:00:25 debian kernel: PM: hibernation: hibernation entry
Jun 21 23:35:30 debian kernel: PM: hibernation: hibernation entry
I've successful tested the patch at least one time with upstream
kernels version 5.10.117, 5.16.14 and 5.17.9, too.
Using this patch, the workaround cited in previous messages is not
required anymore with my hardware.
$ inxi -G
Graphics: Device-1: NVIDIA G96CM [GeForce 9600M GT] driver: nouveau v: kernel
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
The root cause of the issue is probably the cause, at least another,
of other different issue (see
https://gitlab.freedesktop.org/drm/nouveau/-/issues/156#note_1383820 )
It probably be useful to test the patch with different affected nvidia
graphic cards.
Hope that helps.
From 70271cb0aa30e4523d39c3942e84b16fe18338f5 Mon Sep 17 00:00:00 2001
From: Karol Herbst
Date: Mon, 16 May 2022 17:40:20 +0200
Subject: [PATCH] nouveau WIP
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 05076e530e7d..b6343741eda6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -820,6 +820,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
if (ret == 0) {
ret = nouveau_fence_new(chan, false, &fence);
if (ret == 0) {
+nouveau_fence_wait(fence, false, false);
ret = ttm_bo_move_accel_cleanup(bo,
&fence->base,
evict, false,
--
2.35.3
Re: Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64
Hello, The bug affects kernel version 5.16, too. To whom it may interests, I tried to analyse the issue in more detail with kernel version 5.10.87: more info are available here [1] [2]. [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/547#note_1242815 [2] https://bugzilla.kernel.org/show_bug.cgi?id=213617#c5
Re: Bug#989705: Suspend to RAM hangs computer with nouveau driver
Hello, On Tue, Nov 09, 2021 at 05:03:07AM +0100, Barney G wrote: > Same problem here. Without init_on_alloc=0 suspend to RAM is not working > (system freezes). > With init_on_alloc=0 suspend to RAM is working, but waking up sometimes is > not working. > > inxi -G > Graphics: > Device-1: NVIDIA GT218 [GeForce 210] driver: nouveau v: kernel > Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting > unloaded: fbdev,vesa resolution: 1: 1920x1080~60Hz 2: 1920x1080~60Hz > OpenGL: renderer: NVA8 v: 3.3 Mesa 20.3.5 > > uname -a > Linux living 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 > GNU/Linux As reported here[1], it is reported that you can use the following two kernel paramters to workaround the issue (adding "init_on_free=0" to the previously reported "init_on_alloc=0"): init_on_alloc=0 init_on_free=0 If it can be usefull, I was able to replicate the issue affects Linux kernel version 5.14 and the actual 5.15 in sid/unstable. Therefore, both the kernel versions seem to be affected together with 5.10 version. [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/547
Bug#993365: linux-image-5.10.0-8-amd64: cannot wake from suspend, cannot suspend by power button
Hello, Another similar bug report has been opened here [1] for a different computer model (different CPU, different GPU) with a possible solution [2]. Perhaps you could test if solution in [2] applies to your computer, too. Hope that help. Bye. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705#30
Bug#989705: Suspend to RAM hangs computer with nouveau driver
Hello, This is an update of the reported issue for different kernel versions. The column 'STATUS" shows if suspend to ram/suspend to disk fails (FAIL) or succeeds (OK). The kernel versions linux-image-4.19.0-11-amd64, linux-image-5.10.0-8-amd64 and linux-image-5.10.0-8-amd64 are from official Debian repositories. The other kernel versions are compiled by me from upstream (git://git.kernel.org/pub/scm/linux/kernel/gi t/stable/linux.git). STATUS KERNEL VERSION VERSION === === OK ii linux-image-4.19.0-11-amd64 4.19.146-1 FAILii linux-image-5.10.0-8-amd64 5.10.46-3 FAILii linux-image-5.10.0-8-amd64 5.10.46-4 OK ii linux-image-5.10.46 5.10.46 OK ii linux-image-5.10.47 5.10.47 OK ii linux-image-5.10.48 5.10.48 OK ii linux-image-5.10.49 5.10.49 OK ii linux-image-5.10.50 5.10.50 OK ii linux-image-5.10.51 5.10.51 OK ii linux-image-5.10.52 5.10.52 OK ii linux-image-5.10.53 5.10.53 FAILii linux-image-5.13.5 5.13.5 As you an see, the actual candidate for the next Debian stable version (5.10.46-4) fails suspend to ram and suspend to disk w ith the specific reported hardware.
Re: Bug #989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64
Hello, This is an update of the reported issue for different kernel versions. The column 'STATUS" shows if suspend to ram/suspend to disk fails (FAIL) or succeeds (OK). The kernel versions linux-image-4.19.0-11-amd64, linux-image-5.10.0-8-amd64 and linux-image-5.10.0-8-amd64 are from official Debian repositories. The other kernel versions are compiled by me from upstream (git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git). STATUS KERNEL VERSION VERSION === === OK ii linux-image-4.19.0-11-amd64 4.19.146-1 FAILii linux-image-5.10.0-8-amd64 5.10.46-3 FAILii linux-image-5.10.0-8-amd64 5.10.46-4 OK ii linux-image-5.10.46 5.10.46 OK ii linux-image-5.10.47 5.10.47 OK ii linux-image-5.10.48 5.10.48 OK ii linux-image-5.10.49 5.10.49 OK ii linux-image-5.10.50 5.10.50 OK ii linux-image-5.10.51 5.10.51 OK ii linux-image-5.10.52 5.10.52 OK ii linux-image-5.10.53 5.10.53 FAILii linux-image-5.13.5 5.13.5 As you an see, the actual candidate for the next Debian stable version (5.10.46-4) fails suspend to ram and suspend to disk with the specific reported hardware.
