> -----Original Message----- > From: Yijing Wang [mailto:wangyij...@huawei.com] > >>>> > >>>> [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
Hi Wang, this issue (a FW bug) was fixed in the 4.9 FW series. The HP qualified FW (ver 4.9.416.0) is available at http://h20565.www2.hp.com/portal/site/hpsc/template.PAGE/public/psi/swdDetails/?sp4ts.oid=4324790&spf_p.tpst=swdMain&spf_p.prp_swdMain=wsrp-navigationalState%3Didx%253D%257CswItem%253Dco_131997_1%257CswEnvOID%253D54%257CitemLocale%253D%257CswLang%253D%257Cmode%253D%257Caction%253DdriverDocument&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken Could you please upgrade your adapter FW and verify the issue. thanks, -Sathya _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
