On Fri, Jul 2, 2021 at 8:54 AM Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail....@lists.yoctoproject.org> wrote: > > On Fri, Jul 2, 2021 at 1:47 AM Zhang, Qiang <qiang.zh...@windriver.com> wrote: > > > > > > > > ________________________________________ > > From: Bruce Ashfield <bruce.ashfi...@gmail.com> > > Sent: Monday, 7 June 2021 10:54 > > To: Zhang, Qiang > > Cc: linux-yocto@lists.yoctoproject.org > > Subject: Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: > > Ratelimit event dump > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > On Fri, Jun 4, 2021 at 5:14 AM Zhang, Qiang <qiang.zh...@windriver.com> > > wrote: > > > > > > > > > > > > ________________________________________ > > > From: Bruce Ashfield <bruce.ashfi...@gmail.com> > > > Sent: Thursday, 3 June 2021 05:05 > > > To: Zhang, Qiang > > > Cc: linux-yocto@lists.yoctoproject.org > > > Subject: Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: > > > Ratelimit event dump > > > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > > > In message: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: > > > Ratelimit event dump > > > on 02/06/2021 qiang.zh...@windriver.com wrote: > > > > > > > From: Zqiang <qiang.zh...@windriver.com> > > > > > > > > When a device or driver misbehaves, it is possible to receive events > > > > much faster than we can print them out. Ratelimit the printing of events > > > > > > > > During the SVA tests when the device driver didn't properly stop DMA > > > > before unbinding, the event queue thread would almost lock-up the server > > > > with a flood of event 0xa. This patch helped recover from the error. > > > > > > > > Tested-by: Aaro Koskinen <aaro.koski...@nokia.com> > > > > Signed-off-by: Jean-Philippe Brucker <jean-phili...@linaro.org> > > > > Signed-off-by: Zqiang <qiang.zh...@windriver.com> > > > > > > > >Is there a link / reference to where this patch came from ? Judging > > > >by the sign-offs, I assume it is from a mailing list ? > > > > > > > Hello Bruce > > > > > > https://lore.kernel.org/linux-iommu/20210526161927.24268-4-jean-phili...@linaro.org/#r > > > > >Are you tracking the subsystem tree ? > > > > > >I don't see any acked-by or reviewed-by on the list or in the lore link. > > > > Hello Bruce > > > > This change have been megre to linux-next > > > > Excellent. I'll get it queued today.
I ran into some issues when queuing the change, largely around the fact that the linux-next / mainline version is different than the one you originally submitted. The final version of this change depends on 395ad89d11fd93f [iommu/arm-smmu-v3: Add stall support for platform devices], which of course is a more invasive change. That being said, it did apply cleanly to 5.10, and then the ratelimit patch stacks cleanly as well. I'm not set up to test that the fix is correct. Can you do the same cherry pick and see if the result is what you are looking for ? Bruce > > Bruce > > > commit 9cff922bba429b310507eac3b6cb5eb1b57e9ad1 > > Author: Jean-Philippe Brucker <jean-phili...@linaro.org> > > Date: Mon May 31 11:56:50 2021 +0200 > > > > iommu/arm-smmu-v3: Ratelimit event dump > > > > When a device or driver misbehaves, it is possible to receive DMA fault > > events much faster than we can print them out, causing a lock up of the > > system and inability to cancel the source of the problem. Ratelimit > > printing of events to help recovery. > > > > Tested-by: Aaro Koskinen <aaro.koski...@nokia.com> > > Signed-off-by: Jean-Philippe Brucker <jean-phili...@linaro.org> > > Link: > > https://lore.kernel.org/r/20210531095648.118282-1-jean-phili...@linaro.org > > Signed-off-by: Will Deacon <w...@kernel.org> > > > > Thanks > > Qiang > > > > > > >I'm trying to track down that this has been queued for linux-next and > > >merging, that gives us confidence for v5.10/standard/base > > > > > >Without that, I'd prefer to merge this to branches just for the BSPs > > >that are seeing issues with the event dump. Do we have a list of > > >impacted boards or is it generally hitting various ARM BSPs ? > > > > > >Bruce > > > > > > > > thanks > > > Qiang > > > >Also, were you targetting v5.10/standard/base ? If so, we want that > > > >link even more. > > > > > > > >Bruce > > > > > > > --- > > > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 12 ++++++++---- > > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > > > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > > > index 7067b7c11626..583db3dd1465 100644 > > > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > > > @@ -1357,16 +1357,20 @@ static irqreturn_t arm_smmu_evtq_thread(int > > > > irq, void *dev) > > > > struct arm_smmu_device *smmu = dev; > > > > struct arm_smmu_queue *q = &smmu->evtq.q; > > > > struct arm_smmu_ll_queue *llq = &q->llq; > > > > + static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL, > > > > + DEFAULT_RATELIMIT_BURST); > > > > u64 evt[EVTQ_ENT_DWORDS]; > > > > > > > > do { > > > > while (!queue_remove_raw(q, evt)) { > > > > u8 id = FIELD_GET(EVTQ_0_ID, evt[0]); > > > > > > > > - dev_info(smmu->dev, "event 0x%02x received:\n", > > > > id); > > > > - for (i = 0; i < ARRAY_SIZE(evt); ++i) > > > > - dev_info(smmu->dev, "\t0x%016llx\n", > > > > - (unsigned long long)evt[i]); > > > > + if (__ratelimit(&rs)) { > > > > + dev_info(smmu->dev, "event 0x%02x > > > > received:\n", id); > > > > + for (i = 0; i < ARRAY_SIZE(evt); ++i) > > > > + dev_info(smmu->dev, > > > > "\t0x%016llx\n", > > > > + (unsigned long > > > > long)evt[i]); > > > > + } > > > > > > > > } > > > > > > > > -- > > > > 2.31.1 > > > > > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10034): https://lists.yoctoproject.org/g/linux-yocto/message/10034 Mute This Topic: https://lists.yoctoproject.org/mt/83252521/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
