> From: Michael Kelley <[email protected]> > Sent: Thursday, January 22, 2026 10:39 PM > ... > This is good info, and definitely a clue. So to be clear, the problem repros > only when kexec_load() is used. With kexec_file_load(), it does not repro. Is > that right?
Yes and no. The answer depends on the combination of the version of kdump-tools, and the architecture (x86-64 vs. ARM64), and the hypercall (KEXEC_LOAD vs. KEXEC_FILE_LOAD) and the Linux kernel version (there have been patches fixing and breaking kdump over the past several years...) Please see the reply I posted about 2 hours ago for all the details. > I saw a similar distinction when working on commit 304386373007, > though in the opposite direction! I think this happens because you're using Ubuntu 20.04: > https://lwn.net/ml/linux-kernel/sn6pr02mb41572155b6d139c499814eb7d4...@sn6pr02mb4157.namprd02.prod.outlook.com/ > To further complicate matters, the kexec on Oracle Linux 9.4 seems to > have a bug when the -c option forces the use of kexec_load() instead > of kexec_file_load(). As an experiment, I modified the kdumpctl shell > script to add the "-c" option to kexec, but in that case the value "0x0" > is passed as the framebuffer address, which is wrong. Before commit 304386373007, hyperv_fb relocates the framebuffer MMIO base, so KEXEC_FILE_LOAD doesn't work for you, because the kdump kernel's screen_info.lfb_base still points to the initial MMIO, and hence the kdump kernel's efifb driver fails to work properly; KEXEC_LOAD works for you because the kdump-tools v2.0.18 in Ubuntu 20.04 doesn't have that commit (see the other reply from me) The kexec on Oracle Linux 9.4 has that commit, and it's not buggy -- unless we'd like to claim that all the recent kdump-tools versions are buggy :-) Thanks, Dexuan
