On 02/16/17 at 07:35pm, Eric W. Biederman wrote: > Pawe? Lenkow <p.lenkow at camlintechnologies.com> writes: > > > Hi! > > > > I am trying to run EFI stub kernel using kexec and unfortunately 2nd kernel > > crashes. > > Adding the kexec list as there may be someone there who may be more > knowledgeable about our problem. > > > First kernel is loaded by UEFI, starts simple init with shell and then > > I am loading the same image using kexec. > > > > It looks like a lack of correct mappings for EFI tables because it > > calls address zero (RDI register) in efi_call. > > > > Does kernel support such configuration? > > > > If yes what could be wrong? > > I don't know exactly where the support is, I haven't looked recently. > > There is a major challenge with efi. The call to place efi in virtual > mode may be called exactly once. There has been work on at least ia64 > to make it possible to capture the efi virtual address bass and pass it > through to the kernel calling kexec. I don't remember seeing the work > to do that happen on other platforms. > > I personally think we should just abandon running efi in virtual mode > and always run efi in physicall mode, but the feedback when I suggested > that was that efi didn't actually work if you did that. *Shrug* > > Given that efi_enter_virtual_mode is in your call trace I am guessing > that the problem is the historical problem I have mentioned above. > > Eric > > > > > Using grub-efi all works fine, but it is not enough for me. > > > > See log below: > > > > > > / # kexec -l /mnt/INSTALL/vmlinuz -s What is the kexec-tools version? And does kexec -l works (without -s)? A test with efi=debug parameters may help, also full logs of both pre-kexec boot and post-kexec boot could also help to find something.. Thanks Dave
