> From: Michael Kelley <[email protected]> > Sent: Sunday, April 5, 2026 4:11 PM > > ... > > Unluckily, setup_linux_vesafb() only recognizes the vesafb > > driver in Linux kernel ("VESA VGA") and the efifb driver ("EFI VGA"). > > It looks like normally arch_options.reuse_video_type is always 0. > > > > This means the kdump kernel's screen_info.lfb_base is 0, if > > hyperv_fb or hyperv_drm loads. In the past, for a Ubuntu kernel > > with CONFIG_FB_EFI=y, our workaround is blacklisting > > hyperv_fb or hyperv_drm, so /dev/fb0 is backed by efifb, and > > the screen_info.lfb_base is correctly set for kdump. > > Hmmm. This worse than I thought for x86/x64. In fact, it means > a part of my commit message for 304386373007 is now wrong. I had > described everything as working when using the kexec_load() system > call because the FBIOGET_FSCREENINFO ioctl was returning a good > value for smem_start (at least with the hyperv_fb driver). But as you > point out further down, newer versions of the kexec user space program > are ignoring that smem_start value unless the driver is vesafb or efifb. > > Was blacklisting hyperv_fb or hyperv_drm in the kdump kernel > a workaround we had promulgated in the past? My recollection > is vague. But no matter.
Blacklisting hyperv_fb or hyperv_drm in the *first* kernel was an internal workaround, which no longer works since CONFIG_FB_EFI is not set in the linux-azure kernels. Thanks, Dexuan
