Hi,
In regard to how kexec hands off the framebuffer to the newly-booted
kernel:
Commit 060eee589dd1 (2018-01-28) added the "blindly try old boot time
video type" behavior, without doing any checking to see if the
framebuffer is compatible with the stated format.
Commit fb5a8792e6e4 (2019-03-05) made this behavior conditional on the
--reuse-video-type option. The commit message observes that:
Currently kernel hanging is inspected on some hyper-v VMs after this
commit, because hyperv_fb will mimic EFI (or VESA) VGA on first boot
up, but after the real driver is loaded, it will switch to new mode
and no longer compatible with EFI/VESA VGA. Keep setting
orig_video_isVGA to EFI/VESA VGA flag will get wrong driver loaded
and try to manipulate the framebuffer in a wrong way.
It's clear to me that various bad things *might* happen if kexec
pretends that the framebuffer is "VESA-compatible" or "EFI-compatible"
when in fact it isn't.
Yet, in many cases, the Linux framebuffer is VESA/EFI-compatible, at
least to the extent that blindly setting orig_video_isVGA = 0x23 or
0x70 results in a usable display. So I have to wonder, in the
situation mentioned above:
- was the framebuffer not in a compatible format to begin with?
- was the framebuffer address not correctly reported by the existing
kernel driver?
- did the original bootloader give wrong information and somehow that
broke the newly booted kernel?
Kairui, can you please clarify what sort of kernel hangs you were
seeing and what specific hardware and drivers you were using?
Benjamin Moody
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
