Subject: Re: net: dsa: mv88e6xxx: Request for stable inclusion

From: Greg KH <[email-masked]>
Date: Mon, 3 Apr 2023 15:16:25 +0200

On Mon, Apr 03, 2023 at 03:15:19PM +0200, Greg KH wrote:
> On Tue, Mar 28, 2023 at 06:21:58PM +0300, Vladimir Oltean wrote:
> > Hi Fabio,
> > 
> > On Tue, Mar 28, 2023 at 11:51:35AM -0300, Fabio Estevam wrote:
> > > Hi,
> > > 
> > > I am running kernel 6.1 on a system with a mv88e6320 and can easily
> > > trigger a flood of "mv88e6085 30be0000.ethernet-1:00: VTU member
> > > violation for vid 10, source port 5" messages.
> > > 
> > > When this happens, the Ethernet audio that passes through the switch
> > > causes a loud noise in the speaker.
> > > 
> > > Backporting the following commits to 6.1 solves the problem:
> > > 
> > > 4bf24ad09bc0 ("net: dsa: mv88e6xxx: read FID when handling ATU violations")
> > > 8646384d80f3 ("net: dsa: mv88e6xxx: replace ATU violation prints with
> > > trace points")
> > > 9e3d9ae52b56 ("net: dsa: mv88e6xxx: replace VTU violation prints with
> > > trace points")
> > > 
> > > Please apply them to 6.1-stable tree.
> > > 
> > > Thanks,
> > > 
> > > Fabio Estevam
> > 
> > For my information, is there any relationship between the audio samples
> > that (presumably) get packet drops resulting in noise, and the traffic
> > getting VTU member violations? In other words, is the audio traffic sent
> > using VID 10 on switch port 5?
> > 
> > I don't quite understand, since VLAN-filtered traffic should be dropped,
> > what is the reason why the trace point patches would help. My only
> > explanation is that the audio traffic passing through the switch *also*
> > passes through the CPU, and the trace points reduce CPU load caused by
> > an unrelated (and rogue) traffic stream.
> > 
> > If this isn't the case, and you see VTU violations as part of normal
> > operation, I would say that's a different problem for which we would
> > need more details.
> 
> Agreed, this sounds like the removal of printk messages is removing the
> noise, not the actual fix for the reason the printk messages in the
> first place, right?

But, in looking at the above commits, that makes more sense.  I'll go
queue these up for now, thanks.

greg k-h