Dear Debian Kernel Team, I would like to report several boot and power-management issues observed after installing kernel version 6.12.73+deb13-amd64 on older Ivy Bridge hardware. System Information Motherboard: ASUS Sabertooth Z77 CPU: Intel Core i7-3770K (Ivy Bridge) Firmware: UEFI (legacy-compatible board) Distribution: Debian (stable branch) Architecture: amd64 GPU: NVIDIA (proprietary driver installed) Problem Description After upgrading to kernel 6.12.73+deb13-amd64, the system exhibits multiple boot and runtime problems: Boot failures occur intermittently with the following messages: EFI stub: ERROR: Failed to decompress kernel EFI stub: ERROR: efi_stub_entry() failed During successful boots, ACPI-related errors appear in dmesg involving unresolved symbols and SATA controller initialization (_GTF/DSSP related messages). System suspend behavior is unreliable: *When placing the system into sleep mode, the computer immediately wakes without user interaction. Overall system startup appears noticeably slower compared to previous kernels. Expected Behavior The system boots reliably without EFI stub errors, ACPI warnings, or unexpected wake events during suspend. Observed Behavior Kernel 6.12.73+deb13-amd64 causes intermittent boot loader failures, ACPI-related warnings, and unreliable suspend functionality on this hardware. Workaround Booting an earlier kernel (e.g., 6.12.69+deb13-amd64) restores normal behavior and eliminates the EFI decompression failure and sleep issues. Additional Notes Reinstalling the kernel temporarily resolved the EFI decompression error, suggesting either a regression affecting older firmware platforms or sensitivity during installation on legacy UEFI implementations. Please let me know if additional logs, dmesg output, or hardware information would be helpful for debugging. Best regards, Donovan
Hello, As requested, attaching logs from the affected system. Best regards, Donovan
Hello, That is really surprising. This happens very early in the boot process and if there was a problem in that code, this wouldn't be the only report. The efi stub randomizes the memory location, that is the only non-deterministic thing I'm aware of that could explain that (maybe in combination with a BIOS issue where a memory area isn't marked as reserved). Did that happen more than once and only with 6.12.73+deb13-amd64? That is unfortunately normal and most of the time no problem. I would expect you have these with earlier kernels, too. https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html#a-test-modes-of-hibernation contains some debug ideas. I'm not sure how up-to-date this document is, but it is worth a try. Can you please provide a kernel log for both 6.12.69+deb13-amd64 and 6.12.73+deb13-amd64? Best regards Uwe
Hello, Forwarding to the bug address to have this info in the buglog. Please always keep the bug address on Cc: to increase the bus factor. Best regards Uwe
Hello Donovan, I'm irritated about your wording. If 6.12.69 is "more reliable", that means it crashes less often than 6.12.73 but not never, right? Putting the Linux image and initramfs into RAM and decompressing them are the first heavy RAM operations. So if you have overclocked your system and RAM isn't 100% reliable any more it's expected that it fails during these operations. But you still saw failures? It was already in your first mail, but there I missed it. The proprietary nvidia driver is known to introduce problems that are not debuggable due to the driver not being OSS. Can you please try to reproduce the suspend issue without this driver? It wouldn't be the first time the nvidia driver creates suspend issues. If not using it fixes the suspend issue, there is unfortunately nothing we (Debian kernel team) can do for you, and also upstream won't be able to help. There are a few differences (e.g. irq assignment to the different SATA devices, which might play a role, but my bet is on the nvidia driver until proven otherwise for now. Best regards Uwe