> -----Original Message----- > From: Yijing Wang [mailto:wangyij...@huawei.com] > > On 2014/8/25 17:32, Sathya Perla wrote: > >> -----Original Message----- > >> From: Joerg Roedel [mailto:j...@8bytes.org] > >> > >> [Adding the Emulex driver developers to Cc for some input on the device, > >> and why it might use wrong request ids] > >> > >> On Mon, Aug 25, 2014 at 02:44:59PM +0800, Yijing Wang wrote: > >>> We found some strange devices in HP C7000 and Huawei Storage Server. > >> These > >>> devices can not be enumerated by OS, but they still did DMA read/write > >>> without OS management. Because iommu will not create the DMA > >> mapping for > >>> these devices, the DMA read/write will be blocked by iommu hardware. ... > >>> Eg. > >>> in HP C7000: > >>> \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 > >>> +-01.0-[11]-- > >>> +-01.1-[02]-- > >>> +-02.0-[04]--+-00.0 Emulex Corporation OneConnect > >> 10Gb NIC (be3) > >>> | +-00.1 Emulex Corporation OneConnect 10Gb NIC > >>> (be3) > >>> | +-00.2 Emulex Corporation OneConnect 10Gb iSCSI > >> Initiator (be3) > >>> | \-00.3 Emulex Corporation OneConnect 10Gb iSCSI > >> Initiator (be3) > >>> +-02.1-[12]-- > >>> Kernel only found four devices in bus 0x04, but we found following DMA > >> errors in dmesg. > >>> > >>> [ 1438.477262] DRHD: handling fault status reg 402 > >>> [ 1438.498278] DMAR:[DMA Write] Request device [04:00.4] fault addr > >> bdf70000 > >>> [ 1438.498280] DMAR:[fault reason 02] Present bit in context entry is > clear > >>> [ 1438.566458] DMAR:[DMA Write] Request device [04:00.5] fault addr > >> bdf70000 > >>> [ 1438.566460] DMAR:[fault reason 02] Present bit in context entry is > clear > >>> [ 1438.635211] DMAR:[DMA Write] Request device [04:00.6] fault addr > >> bdf70000 > >>> [ 1438.635213] DMAR:[fault reason 02] Present bit in context entry is > clear > >>> [ 1438.703849] DMAR:[DMA Write] Request device [04:00.7] fault addr > >> bdf70000 > >>> [ 1438.703851] DMAR:[fault reason 02] Present bit in context entry is > clear
Hi Wang, from the kernel log I can see that the faulting address 0xbdf70000 falls in the RMRR range the BIOS requested: [ 0.111343] DMAR: RMRR base: 0x000000bdf6f000 end: 0x000000bdf7efff An identity map is being setup for the visible functions, but not for the "invisible" functions: [ 2.695951] IOMMU: Setting identity map for device 0000:04:00.0 [0xbdf6e000 - 0xbdf6efff] [ 2.698637] IOMMU: Setting identity map for device 0000:04:00.1 [0xbdf6e000 - 0xbdf6efff] [ 2.702551] IOMMU: Setting identity map for device 0000:04:00.2 [0xbdf6e000 - 0xbdf6efff] [ 2.705134] IOMMU: Setting identity map for device 0000:04:00.3 [0xbdf6e000 - 0xbdf6efff] I'm going to follow-up with our FW folks as to why functions 04.00.4-7 are invisible but yet are trying to access the RMRR memory region. Could you also please send the me the FW version (output of "ethtool -i eth0") thanks, -Sathya _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
