On 06/12/19 at 09:55am, Baoquan He wrote: > On 06/10/19 at 01:37pm, Borislav Petkov wrote: > > On Sat, Jun 08, 2019 at 06:26:59PM +0800, Baoquan He wrote: > > > OK, I see. Then it should be the issue we have met and talked about with > > > Tom. > > > https://lkml.kernel.org/r/20190604134952.GC26891@MiWiFi-R3L-srv > > > > > > You can apply Tom's patch as below. I tested it, it can make kexec > > > kernel succeed to boot, but failed for kdump kernel booting. The kdump > > > kernel can boot till the end of kernel initialization, then hang with a > > > call trace. I have pasted the log in the above thread. Haven't got the > > > reason. > > > http://lkml.kernel.org/r/508c2853-dc4f-70a6-6fa8-97c950dc31c6@xxxxxxx > > > > I can confirm the same observation. > > With further investigation, the failure after applying Tom's patch is > caused by OOM. When increase crashkernel reservation to 512M, kdump > kernel can boot successfully. I noticed your crashkernel reservation is > 256M, that will fail and stuck there very possibly. Usually for Fedora/RHEL variant kernel + userspace, 160M is a good value works for common setup. Sometimes people forgot to strip debuginfo, thus the kernel modules packed in initramfs is too big and cause out of memory. > > So Tom's patch can fix the issue. We need further check why much more > crashkernel memory is needed on those AMD boxes with sme support.. > > Thanks > Baoquan _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
