linux-kernel - Re: [PATCH 1/1] drm/amdgpu: Fix TLB flush failures after hibernation resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e8e1e479-0c13-40f2-b9be-d87e4503dcb4@kernel.org>
Date: Mon, 26 Jan 2026 14:28:49 -0600
From: "Mario Limonciello (AMD) (kernel.org)" <superm1@...nel.org>
To: Alex Deucher <alexdeucher@...il.com>,
 "Ionut Nechita (Sunlight Linux)" <sunlightlinux@...il.com>
Cc: christian.koenig@....com, alexander.deucher@....com,
 amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
 ionut_n2001@...oo.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] drm/amdgpu: Fix TLB flush failures after hibernation
 resume



On 1/26/2026 2:25 PM, Alex Deucher wrote:
> On Mon, Jan 26, 2026 at 2:52 PM Ionut Nechita (Sunlight Linux)
> <sunlightlinux@...il.com> wrote:
>>
>> From: Ionut Nechita <sunlightlinux@...il.com>
>>
>> On Thu, Jan 8 2026 at 13:36, Christian König wrote:
>>
>>> Question is why the KIQ is not up and running before we do anything with it?
>>
>> Thank you for the feedback. I completely understand that my patch is
>> just a workaround and not proper engineering - you're absolutely right
>> that the real issue is KIQ being marked as ready before it's actually
>> functional.
>>
>> I don't have experience with GPU drivers and video subsystems, so I'm
>> not familiar with the proper initialization sequence for KIQ. I'd prefer
>> not to keep a workaround for this issue in my tree.
>>
>> Is there a proper fix available, or could you point me in the right
>> direction? I'm happy to test any patches on my AMD Cezanne (Renoir)
>> hardware where I can reliably reproduce the issue after hibernation.
> 
> Can you get a stack trace when this happens so we can see the call chain?
> 
>>
>> Also, regarding hibernation support: you mentioned that hibernation is
>> not generally supported with the driver. Should I expect other issues
>> beyond this TLB flush problem, or is this the main blocker?
> 
> The biggest issue with hibernation is that it's not compatible with
> secure boot so most distros don't officially support it.

And by extension of this it doesn't get as much testing as s2idle/s3 do.

>  The other
> issue is that when we go into hibernation, we need to evict the
> contents of VRAM somewhere and at the point when that happens, swap is
> already offline.  So in a lot of cases, we don't have enough memory to
> back up the VRAM contents.  There were patches to the Linux PM core,
> but I can't recall if they've all landed yet.  

Yeah everything should have landed now, so swap will still be enabled.

There's also the
> possibility that the user's swap partition is too small.
> 
> Alex

I heard something about /sys/power/reserved_size being too small by 
default still, so if you're having problems you might increase that.