net: dsa: mv88e6xxx: Request for stable inclusion

net: dsa: mv88e6xxx: Request for stable inclusion

[Fabio Estevam]

Hi,

I would like to request the commit below to be applied to the 6.1-stable tree:

91e87045a5ef ("net: dsa: mv88e6xxx: Add RGMII delay to 88E6320")

Without this commit, there is a failure to retrieve an IP address via DHCP.

Thanks,

Fabio Estevam

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

[Andrew Lunn]

On Wed, May 24, 2023 at 02:38:22PM -0300, Fabio Estevam wrote:
> Hi,
> 
> I would like to request the commit below to be applied to the 6.1-stable tree:
> 
> 91e87045a5ef ("net: dsa: mv88e6xxx: Add RGMII delay to 88E6320")
> 
> Without this commit, there is a failure to retrieve an IP address via DHCP.

Please could your provide a Fixes: tag.

       Andrew

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

[Greg KH]

On Wed, May 24, 2023 at 07:45:50PM +0200, Andrew Lunn wrote:
> On Wed, May 24, 2023 at 02:38:22PM -0300, Fabio Estevam wrote:
> > Hi,
> > 
> > I would like to request the commit below to be applied to the 6.1-stable tree:
> > 
> > 91e87045a5ef ("net: dsa: mv88e6xxx: Add RGMII delay to 88E6320")
> > 
> > Without this commit, there is a failure to retrieve an IP address via DHCP.
> 
> Please could your provide a Fixes: tag.

I do not understand what this means.

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

[Greg KH]

On Wed, May 24, 2023 at 02:38:22PM -0300, Fabio Estevam wrote:
> Hi,
> 
> I would like to request the commit below to be applied to the 6.1-stable tree:
> 
> 91e87045a5ef ("net: dsa: mv88e6xxx: Add RGMII delay to 88E6320")
> 
> Without this commit, there is a failure to retrieve an IP address via DHCP.

Now queued up, thanks.

greg k-h

net: dsa: mv88e6xxx: Request for stable inclusion

[Fabio Estevam]

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

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

[Vladimir Oltean]

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.

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

[Greg KH]

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

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

[Greg KH]

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

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

[Vladimir Oltean]

On Mon, Apr 03, 2023 at 03:16:25PM +0200, Greg KH wrote:
> On Mon, Apr 03, 2023 at 03:15:19PM +0200, Greg KH wrote:
> > 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

No objections there, although that might have just bombed my attempts to
find out what is truly going on :)