[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023040308-entwine-paralyses-c870@gregkh>
Date: Mon, 3 Apr 2023 15:16:25 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Fabio Estevam <festevam@...il.com>,
Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
netdev <netdev@...r.kernel.org>, stable <stable@...r.kernel.org>
Subject: Re: net: dsa: mv88e6xxx: Request for stable inclusion
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
Powered by blists - more mailing lists