Re: Oops when returning from hibernation with changed thunderbolt status

Michael Guntsche <[email protected]> Fri, 15 May 2026 08:54:04 +0200
Newsgroups org.kernel.vger.linux-efi,org.kernel.vger.linux-pm
Message-ID <CALG0vJuoF92whbgkzb-a01m4X+=3L2CZDvyVu4gpB7tAFFKACw@mail.gmail.com>
On Mon, May 11, 2026 at 10:05 PM Michael Guntsche
<[email protected]> wrote:
> Since this was still happening to me with 7.0.6 I went back to 6.14 on
> a whim to see if I can see anything specific there. After coming back
> from hibernation (which worked) I noticed that there were no efi
> variables at all. The kernel log showed the following
<snip>

> So it looks like that I ALWAYS had this issue with my notebook but up
> to 6.14 this resulted in a warning and starting with 6.15 it became a
> panic and lock. What I do not understand at all though is why I am
> apparently the only one that can trigger it repeatedly and others are
> not seeing this issue.
>
So I looked at the dmesg output with a connected and unconnected dock
and the memory layout is different. What I am wondering now is how
this is working in the hibernate case.

* Machine goes into hibernation with the dock connected
* During hibernation the dock is unplugged
* On resume the firmware is doing a full init (sans the dock) and
hands-it-over to the boot kernel which continues with this new mapping
* The hibernation image is being loaded with a different memory layout
* Once this image resumes it tries to access efivars which are now
somewhere else apparently and panics.

Is the hibernation resume code accounting for this change in memory
layout in any way?

Kind regards,
Michael Guntsche