On 2025-01-15 Wed 12:04:10 +0800, Baoquan He wrote: > On 01/14/25 at 02:16pm, Roberto Ricci wrote: > > On 2025-01-13 Mon 22:28:48 +0100, Roberto Ricci wrote: > > > I can reproduce this with kernel 6.13-rc7 in a qemu x86_64 virtual machine > > > running Void Linux, with the following commands: > > > > > > ``` > > > # kexec -l /boot/vmlinuz-6.13.0-rc7 --initrd=/boot/initramfs-6.13.0-rc7 --reuse-cmdline > > > # reboot > > > # printf reboot >/sys/power/disk > > > # printf disk >/sys/power/state > > > ``` > > > > Looks like it's the kernel performing the kexec which causes the issue, > > not the target one. E.g.: kexec-ing 6.7 from 6.13-rc7 makes resume from > > hibernation fail; but if I kexec 6.13-rc7 from 6.7, then it works fine. > > I tried the latest mainline kernel with your above command execution > series, I didn't see the problem you reported. Can you try kexec from > 6.7 to 6.7 or something like that and try to bisect a specific criminal > commit? As I mentioned in my initial report, only versions >= 6.8 are affected. Anyway, I actually was kexec-ing the same kernel which was already booted when I did the bisection which pointed to 18d565ea95fe. > As for below commit, it seems not a suspect. > 18d565ea95fe ("kexec_file: fix incorrect temp_start value in locate_mem_hole_top_down()") > > If possible, can you revert below two commits altogether to have a try? > I am not sure if they caused the problem. > > 18d565ea95fe kexec_file: fix incorrect temp_start value in locate_mem_hole_top_down() > 816d334afa85 kexec: modify the meaning of the end parameter in kimage_is_destination_range() Reverting these two commits does not fix things on v6.13-rc7. But I have found that reverting 18d565ea95fe fixes the issue for kernels up to 6.11. Since 6.12 this is not enough. So I'm doing another bisection. I will report results maybe later today.