On 03/08/2013 02:36 PM, Yinghai Lu wrote: > On Thu, Mar 7, 2013 at 10:32 PM, Yinghai Lu <yinghai at kernel.org> wrote: >> On Thu, Mar 7, 2013 at 10:03 PM, CAI Qian <caiqian at redhat.com> wrote: >>> CC'ing kexec ML. Also mentioned that 3.8 has no such issue. >>> >>> This message looks suspicious and out of range while 3.8 reservation >>> looks within the range. >>> >>> [ 0.000000] Reserving 128MB of memory at 5216MB for crashkernel >>> (System RAM: 3977MB) >>> >>> Wondering if anything to do with memblock again... >> >> that is intended... >> >>> ----- Original Message ----- >>>> From: "WANG Chao" <chaowang at redhat.com> >>>> To: "LKML" vger.kernel.org> >>>> Cc: "CAI Qian" <caiqian at redhat.com> >>>> Sent: Friday, March 8, 2013 1:54:37 PM >>>> Subject: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you >>>> with the DMA bounce buffer >>>> >>>> Hi, All >>>> >>>> On 3.9-rc1, I load crash kernel with latest kexec-tools(up to >>>> 28d413a), but >>>> 2nd kernel panic at early time: >>>> [ 2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB >>>> buffer earlier and can't now provide you with the DMA bounce buffer >>>> [ 2.959958] Pid: 53, comm: khubd Not tainted 3.9.0-rc1+ #1 >> >> You need to add crashkernel_low=64M in first kernel. >> >> As your system does not support DMA remapping. > > looks like your system DO have DMAR table, please enable dmar > remapping in your kernel config. I've already got following config: CONFIG_DMAR_TABLE=y CONFIG_INTEL_IOMMU=y CONFIG_IRQ_REMAP=y but I don't have intel_iommu=on in kernel cmdline. IIRC, iommu will prevent 2nd kernel from booting ... I tested crashkernel=128M and crashkernel_low=64M, seems 2nd-kernel/kexec only works when two params are used in combination. Thanks, WANG Chao > > Yinghai >
