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

WANG Chao chaowang at redhat.com
Fri Mar 8 02:33:22 EST 2013


On 03/08/2013 03:27 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao <chaowang at redhat.com> wrote:
>>>
>>> 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 ...
> 
> Did you put intel_iommu=on on first and second cpu both?

I tried, 2nd kernel didn't boot and keep splitting errors like these:
[    2.106939] DMAR: No ATSR found
[    2.110121] IOMMU 0 0xfed90000: using Queued invalidation
[    2.115522] IOMMU 1 0xfed91000: using Queued invalidation
[    2.120919] IOMMU: Setting RMRR:
[    2.124162] IOMMU: Setting identity map for device 0000:00:02.0 [0xab800000
- 0xaf9fffff]
[    2.133099] IOMMU: Setting identity map for device 0000:00:1d.0 [0xaac95000
- 0xaacb2fff]
[    2.141305] IOMMU: Setting identity map for device 0000:00:1a.0 [0xaac95000
- 0xaacb2fff]
[    2.149503] IOMMU: Setting identity map for device 0000:00:14.0 [0xaac95000
- 0xaacb2fff]
[    2.157690] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    2.163011] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff
[Errors, here we go]
[    2.170932] dmar: DRHD: handling fault status reg 3
[    2.170933] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
[    2.182486] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffe000
[    2.182486] DMAR:[fault reason 05] PTE Write access is not set
[    2.195705] dmar: DRHD: handling fault status reg 3
[    2.200570] dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr ff873000
[    2.200570] DMAR:[fault reason 06] PTE Read access is not set
[    2.213618] dmar: DRHD: handling fault status reg 3
[..]

Thanks,
WANG Chao
> 
> Thanks
> 
> Yinghai
> 




More information about the kexec mailing list