public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	netdev <netdev@vger.kernel.org>, stable <stable@vger.kernel.org>
Subject: Re: net: dsa: mv88e6xxx: Request for stable inclusion
Date: Mon, 3 Apr 2023 15:15:19 +0200	[thread overview]
Message-ID: <2023040343-grip-magical-89d2@gregkh> (raw)
In-Reply-To: <20230328152158.qximoksxqed3ctqv@skbuf>

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?

thanks,

greg k-h

  reply	other threads:[~2023-04-03 13:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 14:51 net: dsa: mv88e6xxx: Request for stable inclusion Fabio Estevam
2023-03-28 15:21 ` Vladimir Oltean
2023-04-03 13:15   ` Greg KH [this message]
2023-04-03 13:16     ` Greg KH
2023-04-03 14:18       ` Vladimir Oltean
  -- strict thread matches above, loose matches on Subject: below --
2023-05-24 17:38 Fabio Estevam
2023-05-24 17:45 ` Andrew Lunn
2023-05-26 18:28   ` Greg KH
2023-05-26 18:28 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2023040343-grip-magical-89d2@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=andrew@lunn.ch \
    --cc=festevam@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox