Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #72489 > unrolled thread

Bug#991546: Acknowledgement (linux-image-5.10.0-8-amd64: soft lockup after screen does a sleep cycle (dpms off then on))

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#991546: Acknowledgement (linux-image-5.10.0-8-amd64: soft lockup after screen does a sleep cycle (dpms off then on)) Marc <dkm@kataplop.net> - 2021-07-27 11:10 +0200
    Bug#991546: Acknowledgement (linux-image-5.10.0-8-amd64: soft lockup after screen does a sleep cycle (dpms off then on)) Marc <dkm+debian@kataplop.net> - 2021-07-27 22:40 +0200
      Bug#991546: Acknowledgement (linux-image-5.10.0-8-amd64: soft lockup after screen does a sleep cycle (dpms off then on)) Salvatore Bonaccorso <carnil@debian.org> - 2021-07-28 08:00 +0200
        Bug#991546: Acknowledgement (linux-image-5.10.0-8-amd64: soft lockup after screen does a sleep cycle (dpms off then on)) Salvatore Bonaccorso <carnil@debian.org> - 2021-07-28 08:20 +0200
      Bug#991546: Acknowledgement (linux-image-5.10.0-8-amd64: soft lockup after screen does a sleep cycle (dpms off then on)) Marc <dkm+debian@kataplop.net> - 2021-07-28 16:50 +0200

#72489 — Bug#991546: Acknowledgement (linux-image-5.10.0-8-amd64: soft lockup after screen does a sleep cycle (dpms off then on))

I'm adding some more info as I discover here that my kernel is tainted:

 * SMP kernel oops on an officially SMP incapable processor

I guess the reason is that my ryzon 1600 has an hw bug and I need to
disable its C6 state by writing in some MSR.

I don't think this is related to my problem, but can verify the
bug still happens with MSR untouched if you think it is worth it.

[toc] | [next] | [standalone]

#72496

After bisecting, I get this SHA1 as the first to have fixed the issue
(at least, it's not showing as easily as before it). It makes sense as
the backtrace shows something in amdgpu and this is a bug fix :)

8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
89fa15ecdca7eb46a711476b961f70a74765bbe4 is the first nobug commit
commit 89fa15ecdca7eb46a711476b961f70a74765bbe4
Author: Huang Rui <ray.huang@amd.com>
Date:   Sat Jan 30 17:14:30 2021 +0800

    drm/amdgpu: fix the issue that retry constantly once the buffer is oversize

    We cannot modify initial_domain every time while the retry starts. That
    will cause the busy waiting that unable to switch to GTT while the vram
    is not enough.

    Fixes: f8aab60422c3 ("drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs")

    Signed-off-by: Huang Rui <ray.huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org

 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---

I also tried to simply cherry-pick it on top of v5.10 tag, and it seems
to also fix the issue.

Here's the bisect log, in case this single SHA1 is not enough:

git bisect start '--term-old=bug' '--term-new=nobug'
# bug: [2c85ebc57b3e1817b6ce1a6b703928e113a90442] Linux 5.10
git bisect bug 2c85ebc57b3e1817b6ce1a6b703928e113a90442
# nobug: [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13
git bisect nobug 62fb9874f5da54fdb243003b386128037319b219
# nobug: [d6560052c2f73db59834e9a3c0aba20579aa7059] Merge tag 'regulator-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect nobug d6560052c2f73db59834e9a3c0aba20579aa7059
# bug: [345b17acb1aa7a443741d9220f66b30d5ddd7c39] Merge tag 'for-linus-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
git bisect bug 345b17acb1aa7a443741d9220f66b30d5ddd7c39
# nobug: [56bf6fc266ca14d2b9276c8a62e4ff6783bfe68b] Merge tag 'arm-defconfig-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect nobug 56bf6fc266ca14d2b9276c8a62e4ff6783bfe68b
# bug: [a692a610d7ed632cab31b61d6c350db68a10e574] Merge tag 'block-5.11-2021-01-24' of git://git.kernel.dk/linux-block
git bisect bug a692a610d7ed632cab31b61d6c350db68a10e574
# bug: [badc6ac3212294bd37304c56ddf573c9ba3202e6] Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue
git bisect bug badc6ac3212294bd37304c56ddf573c9ba3202e6
# nobug: [295f830e53f4838344c97e12ce69637e2128ca8d] rxrpc: Fix dependency on IPv6 in udp tunnel config
git bisect nobug 295f830e53f4838344c97e12ce69637e2128ca8d
# nobug: [6016bf19b3854b6e70ba9278a7ca0fce75278d3a] Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
git bisect nobug 6016bf19b3854b6e70ba9278a7ca0fce75278d3a
# nobug: [eec79181212c9c2670423400a9e78bb1f0c0075d] Merge tag 'block-5.11-2021-02-05' of git://git.kernel.dk/linux-block
git bisect nobug eec79181212c9c2670423400a9e78bb1f0c0075d
# bug: [dd86e7fa07a3ec33c92c957ea7b642c4702516a0] Merge tag 'pci-v5.11-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
git bisect bug dd86e7fa07a3ec33c92c957ea7b642c4702516a0
# nobug: [97ba0c7413f83ab3b43a5ba05362ecc837fce518] Merge tag 'iommu-fixes-v5.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
git bisect nobug 97ba0c7413f83ab3b43a5ba05362ecc837fce518
# nobug: [cfd4951f935c5504e887ed80abaafba210cc0a44] Merge tag 'amd-drm-fixes-5.11-2021-02-03' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
git bisect nobug cfd4951f935c5504e887ed80abaafba210cc0a44
# nobug: [58180a0cc0c57fe62a799a112f95b60f6935bd96] drm/amd/display: Release DSC before acquiring
git bisect nobug 58180a0cc0c57fe62a799a112f95b60f6935bd96
# nobug: [cd9b0159beb7787bec38eb339ed7bc167d83b4ff] drm/amdgpu: enable freesync for A+A configs
git bisect nobug cd9b0159beb7787bec38eb339ed7bc167d83b4ff
# nobug: [b99a8c8f239d76820bbed33c1a42c381cc1f16db] drm/amdkfd: fix null pointer panic while free buffer in kfd
git bisect nobug b99a8c8f239d76820bbed33c1a42c381cc1f16db
# nobug: [89fa15ecdca7eb46a711476b961f70a74765bbe4] drm/amdgpu: fix the issue that retry constantly once the buffer is oversize
git bisect nobug 89fa15ecdca7eb46a711476b961f70a74765bbe4
# first nobug commit: [89fa15ecdca7eb46a711476b961f70a74765bbe4]
drm/amdgpu: fix the issue that retry constantly once the buffer is oversize

Marc

[toc] | [prev] | [next] | [standalone]

#72497

Hi Marc,

Thanks a lot for your investigation.

On Tue, Jul 27, 2021 at 10:28:24PM +0200, Marc wrote:
> After bisecting, I get this SHA1 as the first to have fixed the issue
> (at least, it's not showing as easily as before it). It makes sense as
> the backtrace shows something in amdgpu and this is a bug fix :)
> 
> 8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
> 89fa15ecdca7eb46a711476b961f70a74765bbe4 is the first nobug commit
> commit 89fa15ecdca7eb46a711476b961f70a74765bbe4
> Author: Huang Rui <ray.huang@amd.com>
> Date:   Sat Jan 30 17:14:30 2021 +0800
> 
>     drm/amdgpu: fix the issue that retry constantly once the buffer is oversize
> 
>     We cannot modify initial_domain every time while the retry starts. That
>     will cause the busy waiting that unable to switch to GTT while the vram
>     is not enough.
> 
>     Fixes: f8aab60422c3 ("drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs")
> 
>     Signed-off-by: Huang Rui <ray.huang@amd.com>
>     Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>     Reviewed-by: Christian König <christian.koenig@amd.com>
>     Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>     Cc: stable@vger.kernel.org
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
> 
> I also tried to simply cherry-pick it on top of v5.10 tag, and it seems
> to also fix the issue.

I wonder if this will be really enough. I'm asking since the commit
you identified, is marked to fix another commit, which was not
backported into the 5.10.y series. 

Now that you identified possible fix for this issue, I would suggest
to report it to upstream, can you do that and keep the Debian bug into
the loop?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#72499

Marc,

On Wed, Jul 28, 2021 at 07:54:58AM +0200, Salvatore Bonaccorso wrote:
> Hi Marc,
> 
> Thanks a lot for your investigation.
> 
> On Tue, Jul 27, 2021 at 10:28:24PM +0200, Marc wrote:
> > After bisecting, I get this SHA1 as the first to have fixed the issue
> > (at least, it's not showing as easily as before it). It makes sense as
> > the backtrace shows something in amdgpu and this is a bug fix :)
> > 
> > 8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
> > 89fa15ecdca7eb46a711476b961f70a74765bbe4 is the first nobug commit
> > commit 89fa15ecdca7eb46a711476b961f70a74765bbe4
> > Author: Huang Rui <ray.huang@amd.com>
> > Date:   Sat Jan 30 17:14:30 2021 +0800
> > 
> >     drm/amdgpu: fix the issue that retry constantly once the buffer is oversize
> > 
> >     We cannot modify initial_domain every time while the retry starts. That
> >     will cause the busy waiting that unable to switch to GTT while the vram
> >     is not enough.
> > 
> >     Fixes: f8aab60422c3 ("drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs")
> > 
> >     Signed-off-by: Huang Rui <ray.huang@amd.com>
> >     Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> >     Reviewed-by: Christian König <christian.koenig@amd.com>
> >     Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> >     Cc: stable@vger.kernel.org
> > 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
> > 
> > I also tried to simply cherry-pick it on top of v5.10 tag, and it seems
> > to also fix the issue.
> 
> I wonder if this will be really enough. I'm asking since the commit
> you identified, is marked to fix another commit, which was not
> backported into the 5.10.y series. 
> 
> Now that you identified possible fix for this issue, I would suggest
> to report it to upstream, can you do that and keep the Debian bug into
> the loop?

Sorry should have been more clear here: Not upstream for mainline, as
it is fixed, but for looking forward for inclusion of the bugfix into
the 5.10.y stable series upstream, I guess we need to clarify the
above.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#72504

I've opened an issue upstream:

 https://bugzilla.kernel.org/show_bug.cgi?id=213889

I've tried the "bts forwarded ..." as instructed on
https://wiki.debian.org/DebianKernelReportingBugs but I think it only
works for DD ?

Thanks,
Marc

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web