Seiji Aguchi <seiji.aguchi at hds.com> writes: > Hi, > > [Background] > - Requirement in enterprise area > From our support service experience, we always need to detect root causes of OS panic. > Because customers in enterprise area never forgive us if kdump fails and we can't detect > root causes of panic due to lack of materials for investigation. > > That is why I would like to add kmsg_dump() in kdump path. You are whittling this down to something that has a chance of being useful, but the code still has a ways to go. It is good that you have managed to run tests that on one hardware platform the firmware is reliable and that this does not reduce the odds of kexec. Your starting assertion however is that you can not do this in the kernel started by kexec on panic because kexec on panic is unreliable. You don't have test cases that show your code working when the kexec on panic kernel does not. Calling out to EFI continues not to inspire my confidence that this code will work on a wide variety of hardware platforms. What is going on with EFI support? We are still making efi calls in virtual mode, and we don't have the one unified identity mapped physical page table that hpa and I think others were working a while back. Even if because of bugs we need to transition EFI to virtual mode we can still set physical to virtual so we don't have to deal with the nonsense. Can we please make our EFI support ask the minimal from EFI before adding lots more to it? Am I wrong in thinking that the core motivation behind this patch is that our EFI support sucks and thus kdump on EFI does not work on some platforms? Eric
