Control: tags -1 + moreinfo On Sun, Jul 05, 2026 at 12:03:30AM +0200, Sören König wrote: > Package: src:linux > Version: 6.19.8-1~bpo13+1 > Severity: normal > X-Debbugs-Cc: [email protected] > User: [email protected] > Usertags: amd64 > > Dear Maintainer, > > * What led up to the situation? > > The machine (ThinkPad T14 Gen 4 AMD, 21K3CTO1WW, BIOS R2FET58W 1.38) was > hibernated (suspend-to-disk) after roughly 8.8 hours of uptime. On the > following boot I resumed from the hibernation image. > > * What exactly did you do (or not do) that was effective (or ineffective)? > > Nothing unusual: a regular hibernate/resume cycle, as I do routinely on > this machine. Resume from hibernation has otherwise been working with > this kernel. > > * What was the outcome of this action? > > The resume itself completed, but shortly afterwards the kernel panicked > ("Fatal exception in interrupt") in an EFI runtime services call and the > machine froze. The Oops shows a supervisor instruction fetch from an > unmapped page (PTE 0) at RIP 0xfffffffed6fe0468, i.e. inside the EFI > runtime services virtual mapping region rather than kernel text. The > faulting task was a kworker on the efi_rts_wq workqueue running > efi_call_rts, and immediately afterwards efi_pstore failed with > "pstore: backend (efi_pstore) writing error (-16)", so the crashing call > was most likely a SetVariable invocation on behalf of efi-pstore. > > * What outcome did you expect instead? > > A normal resume from hibernation without a kernel panic; at worst a > disabled EFI runtime services interface (efi=noruntime-like behaviour) > rather than a fatal exception. > > Additional notes: > > - This has happened once so far. I will report back if it recurs. > - Note the panic occurred on linux-image-6.19.8+deb13-amd64 > (6.19.8-1~bpo13+1, trixie-backports); the reportbug run below was made > from a newer kernel (7.0.9+deb13-amd64), so the "Kernel:" line in the > system information does not reflect the kernel that crashed. > - Hibernation is set up with swap on dm-crypt (dm_crypt/md in use, see > module list in the Oops).
If things are happening only once then we cannot really help. But two things: - Upgrade to the most recent kernel possible. This is for now 7.0.12-2~bpo13+1 in trixie-backports. - Run a memory test, as there might be some indication of defective memory. For now I tag the bug moreinfo, please report back if you re-encounter the issue. Regards, Salvatore
