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