On Thu, 28 Nov 2024 at 12:42, Dave Airlie <airlied@xxxxxxxxx> wrote:
>
> Merge window fixes, mostly amdgpu and xe, with a few other minor ones,
> all looks fairly normal,
Hmm. I've pulled this, but do note the report by Sasha.
The
if (WARN_ON(!work->func))
return false;
from __flush_work() looks odd, and is fairly obviously triggered by
this one liner in commit 93df74873703 ("drm/amdgpu/jpeg: cancel the
jpeg worker")
- bool set_clocks = !cancel_delayed_work_sync(&adev->vcn.idle_work);
+ bool set_clocks = !cancel_delayed_work_sync(&adev->jpeg.idle_work);
where apparently the jpeg.idle_work isn't initialized at that point.
It looks like the initialization is done by amdgpu_jpeg_sw_init(), and
it looks like that cancel_delayed_work_sync() is just done too early.
But I don't know the code. Alex?
The other report by Sasha seems to be a 32-bit issue, where something
calls roundup_pow_of_two() on a thing that would round up past the
32-bit limit. Presumably it works on 64-bit.
But I'm not seeing anything that looks like a likely *cause* of the new warning.
There's a couple possible cases, although this one looks suspicious:
adev->vm_manager.max_pfn = (uint64_t)vm_size << 18;
tmp = roundup_pow_of_two(adev->vm_manager.max_pfn);
because it explicitly uses 64-bit types for that max_pfn thing, but
then does that roundup_pow_of_two() that only works on "unsigned
long".
Sasha - it would help if your warning stack dumps had line numbers
(using decode_stacktrace.sh, which you should be familiar with, since
you wrote it...)
I realize that requires some debug info, which might slow down builds
etc, but it would be really nice.
Linus
