From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Raj, Ashok" Subject: Re: source-id verification failures Date: Fri, 5 Oct 2018 16:54:28 -0700 Message-ID: <20181005235428.GB19502@araj-mobl1.jf.intel.com> References: <20181002172529.fjapu46h5y57m3f7@cantor> <20181004090753.GC3630@8bytes.org> <20181004205724.4kqntecb6m7gcgu6@cantor> <20181004150746.4a243396@jacob-builder> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20181004150746.4a243396@jacob-builder> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Jacob Pan Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Ashok Raj List-Id: iommu@lists.linux-foundation.org On Thu, Oct 04, 2018 at 03:07:46PM -0700, Jacob Pan wrote: > On Thu, 4 Oct 2018 13:57:24 -0700 > Jerry Snitselaar wrote: > > > On Thu Oct 04 18, Joerg Roedel wrote: > > >Hi Jerry, > > > > > >thanks for the report. > > > > > >On Tue, Oct 02, 2018 at 10:25:29AM -0700, Jerry Snitselaar wrote: > > >> I've been trying to track down a problem where an hp dl380 gen8 > > >> with a Cavium QLogic BR-1860 Fabric Adapter is getting source-id > > >> verification failures when running dhclient against that > > >> interface. This started showing up when I backported the iova > > >> deferred flushing patches. So far this has only been seen on this > > >> one system, but I'm trying to understand why it appears with the > > >> new deferred flushing code. I also see it with both 4.18.10, and > > >> 4.19.0-rc6 kernels. Weird.. IRC, these were there to accomodate phantom functions. Thought PCIe allowed 8bit tag, so if the device needs to allow more than 256 outstanding transactions, one could use the extra functions to account for. I assumed Linux didn't enable phantom functions. If that's the case we also need to ensure all the DMA is aliased properly. I'm assuming if interrupts are generated by other aliases we could block them. Is this device one such? Cheers, Ashok > > >> > > >> [35645.282021] bna 0000:24:00.1 ens5f1: link down > > >> [35645.298396] bna 0000:24:00.0 ens5f0: link down > > >> [35650.313210] DMAR: DRHD: handling fault status reg 2 > > >> [35650.332477] DMAR: [INTR-REMAP] Request device [24:00.0] fault > > >> index 14 [fault reason 38] Blocked an interrupt request due to > > >> source-id verification failure [35655.137667] bna 0000:24:00.0 > > >> ens5f0: link up [35657.532454] bna 0000:24:00.1 ens5f1: link up > > >> [35664.281563] bna 0000:24:00.1 ens5f1: link down [35664.298103] > > >> bna 0000:24:00.0 ens5f0: link down [35669.313568] DMAR: DRHD: > > >> handling fault status reg 102 [35669.333198] DMAR: [INTR-REMAP] > > >> Request device [24:00.0] fault index 14 [fault reason 38] Blocked > > >> an interrupt request due to source-id verification failure > > >> [35674.081212] bna 0000:24:00.0 ens5f0: link up [35674.981280] bna > > >> 0000:24:00.1 ens5f1: link up > > >> > > >> > > >> Any ideas? > > > > > >No, not yet. Can you please post the output of lscpi -vvv? > > > > > >Jacob, can you or someone from your team please also have a look into > > >this problem report? > > > > yep. > +Ashok > > Jerry, > Could you also dump the interrupt remapping table with this patchset? > https://lkml.org/lkml/2018/9/12/44 > > Thanks, >