On Sun, 2014-04-13 at 22:01 +0200, Stefani Seibold wrote: > Rebooting my kernel vanilla kernel 3.14 will fail with tons of kernel > log messages: > > [ 0.262754] IOMMU: Setting identity map for device 0000:00:1a.0 > [0x7c45f000 - 0x7c46bfff] > [ 0.262780] IOMMU: Setting identity map for device 0000:00:14.0 > [0x7c45f000 - 0x7c46bfff] > [ 0.262798] IOMMU: Prepare 0-16MiB unity mapping for LPC > [ 0.262807] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - > 0xffffff] > [ 0.262948] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O > [ 0.262948] dmar: DRHD: handling fault status reg 3 > [ 0.262951] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr > ffffe000 > DMAR:[fault reason 05] PTE Write access is not set
I'm inferring from the subject line that you mean kexec, not "rebooting"? It looks like a peripheral device is being left active and doing DMA by the previous kernel, rather than being shut down. So as soon as the new kernel resets the IOMMU mappings, that peripheral device is causing faults. We really ought to rate-limit the faults and isolate the offending device before there are 21,000 of them. As discussed elsewhere recently, we could do with a way to tell the PCI layer that it offended us but I suppose we could at *least* stop the IOMMU from reporting faults for it. Is this new behaviour? I'm not sure why this should have changed... -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
