Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-07-04 Thread Bruce Ashfield
On Sun, Jul 4, 2021 at 9:47 PM Zhang, Qiang  wrote:
>
>
>
> 
> From: Bruce Ashfield 
> Sent: Sunday, 4 July 2021 11:25
> To: Bruce Ashfield
> Cc: Zhang, Qiang; 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, Jul 2, 2021 at 8:54 AM Bruce Ashfield via
> lists.yoctoproject.org
>  wrote:
> >
> > On Fri, Jul 2, 2021 at 1:47 AM Zhang, Qiang  
> > wrote:
> > >
> > >
> > >
> > > 
> > > From: Bruce Ashfield 
> > > 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  
> > > wrote:
> > > >
> > > >
> > > >
> > > > ________________
> > > > From: Bruce Ashfield 
> > > > 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 
> > > > >
> > > > > 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 
> > > > > Signed-off-by: Jean-Philippe Brucker 
> > > > > Signed-off-by: Zqiang 
> > > > >
> > > > >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 ?
>
> Hello Bruce
>
> Yes, this patch can apply to v5.10, the v5.13 is not apply, in v5.13 this 
> patch depend on 395ad89d11fd93f [iommu/arm-smmu-v3: Add stall support for 
> platform devices].
> I just migrated this change 9cff922bba [iommu/arm-smmu-v3: Ratelimit event 
> dump ] to v5.10, and this be talk in
>
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20200224182401.353359-22-jean-phili...@linaro.org/
>
> this patch [iommu/arm-smmu-v3: Ratelimit event dump ]  can be sent 
> independently of other patches.

I wasn't clear.

I would rather not merge this patch to v5.10, when the upstream
version is different.  Which is why I'm asking about doing the
cherry-pick of both patches, and not using

Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-07-04 Thread Zhang, Qiang



From: Bruce Ashfield 
Sent: Sunday, 4 July 2021 11:25
To: Bruce Ashfield
Cc: Zhang, Qiang; 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, Jul 2, 2021 at 8:54 AM Bruce Ashfield via
lists.yoctoproject.org
 wrote:
>
> On Fri, Jul 2, 2021 at 1:47 AM Zhang, Qiang  wrote:
> >
> >
> >
> > 
> > From: Bruce Ashfield 
> > 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  
> > wrote:
> > >
> > >
> > >
> > > 
> > > From: Bruce Ashfield 
> > > 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 
> > > >
> > > > 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 
> > > > Signed-off-by: Jean-Philippe Brucker 
> > > > Signed-off-by: Zqiang 
> > > >
> > > >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 ?

Hello Bruce

Yes, this patch can apply to v5.10, the v5.13 is not apply, in v5.13 this patch 
depend on 395ad89d11fd93f [iommu/arm-smmu-v3: Add stall support for platform 
devices].
I just migrated this change 9cff922bba [iommu/arm-smmu-v3: Ratelimit event dump 
] to v5.10, and this be talk in 

https://patchwork.kernel.org/project/linux-arm-kernel/patch/20200224182401.353359-22-jean-phili...@linaro.org/

this patch [iommu/arm-smmu-v3: Ratelimit event dump ]  can be sent 
independently of other patches.

Thanks
Qiang


>
>Bruce

>
> Bruce
>
> > commit 9cff922bba429b310507eac3b6cb5eb1b57e9ad1
> > Author: Jean-Philippe Brucker 
> > 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 
> > Signed-off-by: Jean-Philippe Brucker 
> > Link: 
> > https://lore.kernel.org/r/20210531095648.118282-1-jean-phili...@linaro.org
> > Signed-off-by: Will Deacon 
&

Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-07-03 Thread Bruce Ashfield
On Fri, Jul 2, 2021 at 8:54 AM Bruce Ashfield via
lists.yoctoproject.org
 wrote:
>
> On Fri, Jul 2, 2021 at 1:47 AM Zhang, Qiang  wrote:
> >
> >
> >
> > 
> > From: Bruce Ashfield 
> > 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  
> > wrote:
> > >
> > >
> > >
> > > 
> > > From: Bruce Ashfield 
> > > 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 
> > > >
> > > > 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 
> > > > Signed-off-by: Jean-Philippe Brucker 
> > > > Signed-off-by: Zqiang 
> > > >
> > > >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 
> > 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 
> > Signed-off-by: Jean-Philippe Brucker 
> > Link: 
> > https://lore.kernel.org/r/20210531095648.118282-1-jean-phili...@linaro.org
> > Signed-off-by: Will Deacon 
> >
> > 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 
> > &g

Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-07-02 Thread Bruce Ashfield
On Fri, Jul 2, 2021 at 1:47 AM Zhang, Qiang  wrote:
>
>
>
> 
> From: Bruce Ashfield 
> 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  wrote:
> >
> >
> >
> > 
> > From: Bruce Ashfield 
> > 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 
> > >
> > > 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 
> > > Signed-off-by: Jean-Philippe Brucker 
> > > Signed-off-by: Zqiang 
> > >
> > >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.

Bruce

> commit 9cff922bba429b310507eac3b6cb5eb1b57e9ad1
> Author: Jean-Philippe Brucker 
> 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 
> Signed-off-by: Jean-Philippe Brucker 
> Link: 
> https://lore.kernel.org/r/20210531095648.118282-1-jean-phili...@linaro.org
> Signed-off-by: Will Deacon 
>
> 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 = >evtq.q;
> > >   struct arm_smmu_ll_queue *llq = >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);
> > > - 

Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-07-01 Thread Zhang, Qiang



From: Bruce Ashfield 
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  wrote:
>
>
>
> 
> From: Bruce Ashfield 
> 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 
> >
> > 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 
> > Signed-off-by: Jean-Philippe Brucker 
> > Signed-off-by: Zqiang 
> >
> >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 

commit 9cff922bba429b310507eac3b6cb5eb1b57e9ad1
Author: Jean-Philippe Brucker 
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 
Signed-off-by: Jean-Philippe Brucker 
Link: 
https://lore.kernel.org/r/20210531095648.118282-1-jean-phili...@linaro.org
Signed-off-by: Will Deacon 

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 = >evtq.q;
> >   struct arm_smmu_ll_queue *llq = >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()) {
> > + 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]);
> > + }

Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-06-07 Thread Zhang, Qiang



From: Bruce Ashfield 
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  wrote:
>
>
>
> 
> From: Bruce Ashfield 
> 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 
> >
> > 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 
> > Signed-off-by: Jean-Philippe Brucker 
> > Signed-off-by: Zqiang 
> >
> >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.
>

Yes it hasn't been acked-by or reviewed-by , 
maybe merge it after this change enters linux-next, I will keep tracing.
thanks Bruce

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 = >evtq.q;
> >   struct arm_smmu_ll_queue *llq = >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()) {
> > + 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9941): 
https://lists.yoctoproject.org/g/linux-yocto/message/9941
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]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-06-06 Thread Bruce Ashfield
On Fri, Jun 4, 2021 at 5:14 AM Zhang, Qiang  wrote:
>
>
>
> 
> From: Bruce Ashfield 
> 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 
> >
> > 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 
> > Signed-off-by: Jean-Philippe Brucker 
> > Signed-off-by: Zqiang 
> >
> >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.

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 = >evtq.q;
> >   struct arm_smmu_ll_queue *llq = >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()) {
> > + 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9939): 
https://lists.yoctoproject.org/g/linux-yocto/message/9939
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]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-06-04 Thread Zhang, Qiang



From: Bruce Ashfield 
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 
>
> 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 
> Signed-off-by: Jean-Philippe Brucker 
> Signed-off-by: Zqiang 
>
>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

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 = >evtq.q;
>   struct arm_smmu_ll_queue *llq = >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()) {
> + 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
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9938): 
https://lists.yoctoproject.org/g/linux-yocto/message/9938
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]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-06-02 Thread Zhang, Qiang



From: Bruce Ashfield 
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 
>
> 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 
> Signed-off-by: Jean-Philippe Brucker 
> Signed-off-by: Zqiang 

>Is there a link / reference to where this patch came from ? Judging
>by the sign-offs, I assume it is from a mailing list ?

Here's a link to the discussion:
 
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20200224182401.353359-22-jean-phili...@linaro.org/

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 = >evtq.q;
>   struct arm_smmu_ll_queue *llq = >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()) {
> + 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
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9933): 
https://lists.yoctoproject.org/g/linux-yocto/message/9933
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]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: Ratelimit event dump

2021-06-02 Thread Bruce Ashfield
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 
> 
> 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 
> Signed-off-by: Jean-Philippe Brucker 
> Signed-off-by: Zqiang 

Is there a link / reference to where this patch came from ? Judging
by the sign-offs, I assume it is from a mailing list ?

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 = >evtq.q;
>   struct arm_smmu_ll_queue *llq = >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()) {
> + 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
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9931): 
https://lists.yoctoproject.org/g/linux-yocto/message/9931
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]
-=-=-=-=-=-=-=-=-=-=-=-