[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wmu0ux3t.fsf@vps.thesusis.net>
Date: Wed, 29 Nov 2023 15:24:06 -0500
From: Phillip Susi <phill@...susis.net>
To: Luben Tuikov <ltuikov89@...il.com>,
Alex Deucher <alexdeucher@...il.com>
Cc: Linux regressions mailing list <regressions@...ts.linux.dev>,
Christian König
<ckoenig.leichtzumerken@...il.com>, linux-kernel@...r.kernel.org,
"amd-gfx@...ts.freedesktop.org" <amd-gfx@...ts.freedesktop.org>,
dri-devel@...ts.freedesktop.org,
Alex Deucher <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
Danilo Krummrich <dakr@...hat.com>
Subject: Re: Radeon regression in 6.6 kernel
Luben Tuikov <ltuikov89@...il.com> writes:
> I remember that the problem was really that amdgpu called drm_sched_entity_init(),
> in amdgpu_ttm_set_buffer_funcs_status() without actually having initialized the scheduler
> used therein. For instance, the code before commit b70438004a14f4, looked like this:
>
<snip>
> sched = &ring->sched; <-- LT: No one has initialized this scheduler
> r = drm_sched_entity_init(&adev->mman.entity, <-- Oopses, now that sched->sched_rq is not
<snip>
> Before commit 56e449603f0ac5, amdgpu was getting away with this, because the sched->sched_rq
> was a static array.
>
> Ideally, amdgpu code would be fixed.
This sounds like an initilization problem that resulted in an OOPS at
boot time, but I don't remember seeing that. I just get a failure on
system suspend.
Powered by blists - more mailing lists