On 2014/8/25 20:11, Sathya Perla wrote: >> -----Original Message----- >> From: Yijing Wang [mailto:[email protected]] >> >> On 2014/8/25 17:32, Sathya Perla wrote: >>>> -----Original Message----- >>>> From: Joerg Roedel [mailto:[email protected]] >>>> >>>> [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")
Hi Sathya, thanks for your help. FW version is 4.6.247.5 driver version is 4.4.161.0s Thanks! Yijing. > > thanks, > -Sathya > > . > -- Thanks! Yijing _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
