On 01/26/15 at 09:08am, Vivek Goyal wrote: > On Sat, Jan 24, 2015 at 09:26:37PM +0800, Dave Young wrote: > > Hi, > > > > Kdump has several limitations currently such as kdump kernel reboot will bypass > > device shutdown path so device drivers should reset during initialization. > > > > * One of such problem we encounter now is the iommu > > issue, 1st kernel's on fly DMA requests cause 2nd kernel hang. There's some effort > > on this area, Zhenhua Li posted patches to resolve the intel iommu issue which is > > under review. But that is just one case there's other possible problems in the future. > > > > * There's no serial console on most machines in the market especially for desktop > > machines and laptops. kms enabled kernel need drm layer driver for framebuffer > > console, after kernel crashing we need a console to see the 2nd kernel output > > ideally a serial console because we can not switch back to VGA mode. > > > > ppc64 has a feature "firmware assisted kdump", see below documentation: > > Documentation/powerpc/firmware-assisted-dump.txt > > > > In case UEFI machines I wonder if we can do similar things, basic idea is doing > > minimum thing based on original kdump process. > > > > kernel reserve crashkernel memory during early boot > > -> user (kdump service) save necessary informations in some way so that second > > kernel boot can access ie. efi runtime variables or in reserved memory > > * crashkernel memory ranges infomation > > * collect infomations and save elf notes for 2nd kernel vmcore initialization > > I think anything related to vmcore initilization can be in memory > somewhere and should not be a problem. > > But we do have to think about anything which is passed in bootparams or > command line to second kenrnel with current mechanism, how will it be > passed to second kernel. Hi, Vivek, Since we are rebooting via efi maybe we can just choose another boot entry in grub.cfg with the proper cmdline? Thanks Dave
