All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Matteo Croce <mcroce@linux.microsoft.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Drew Fustini <drew@beagleboard.org>,
	Emil Renner Berthing <kernel@esmil.dk>,
	Jon Hunter <jonathanh@nvidia.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH net-next] stmmac: align RX buffers
Date: Fri, 13 Aug 2021 16:44:17 +0200	[thread overview]
Message-ID: <YRaFQRyD8fwc6PEz@orome.fritz.box> (raw)
In-Reply-To: <87v94a8z0u.wl-maz@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 4066 bytes --]

On Thu, Aug 12, 2021 at 04:26:41PM +0100, Marc Zyngier wrote:
> On Thu, 12 Aug 2021 15:29:06 +0100,
> Thierry Reding <thierry.reding@gmail.com> wrote:
> > 
> > On Wed, Aug 11, 2021 at 02:23:10PM +0100, Marc Zyngier wrote:
> 
> [...]
> 
> > > I love this machine... Did this issue occur with the Denver CPUs
> > > disabled?
> > 
> > Interestingly I've been doing some work on a newer device called Jetson
> > TX2 NX (which is kind of a trimmed-down version of Jetson TX2, in the
> > spirit of the Jetson Nano) and I can't seem to reproduce these failures
> > there (tested on next-20210812).
> > 
> > I'll go dig out my Jetson TX2 to run the same tests there, because I've
> > also been using a development version of the bootloader stack and
> > flashing tools and all that, so it's possible that something was fixed
> > at that level. I don't think I've ever tried disabling the Denver CPUs,
> > but then I've also never seen these issues myself.
> > 
> > Just out of curiosity, what version of the BSP have you been using to
> > flash?
> 
> I've only used the BSP for a few weeks when I got the board last
> year. The only thing I use from it is u-boot to chainload an upstream
> u-boot, and boot Debian from there.

That's interesting... have you ever tried to inject a version of
upstream U-Boot into the BSP and have it flash that instead? That should
allow you to drop the chainloading step.

Not that that's likely to have anything to do with this.

> > One other thing that I ran into: there's a known issue with the PHY
> > configuration. We mark the PHY on most devices as "rgmii-id" on most
> > devices and then the Marvell PHY driver needs to be enabled. Jetson TX2
> > has phy-mode = "rgmii", so it /should/ work okay.
> > 
> > Typically what we're seeing with that misconfiguration is that the
> > device fails to get an IP address, but it might still be worth trying to
> > switch Jetson TX2 to rgmii-id and using the Marvell PHY, to see if that
> > improves anything.
> 
> I never failed to get an IP address. Overall, networking has been
> solid on this machine until this patch. I'll try and mess with this
> when I get time, but that's probably going to be next week now.

So I've hooked up my Jetson TX2 and tried various workloads. I wasn't
able to reproduce this on next-20210813. I've tried both the L4T 32.6.1
release and a local development build.

Perhaps one thing to try would be to upgrade your L4T BSP to something
newer. I know that there have occasionally been bugs in the MTS
firmware, which is what's running on the Denver cores, and newer BSPs
can fix those kinds of issues.

If that doesn't help, perhaps try to read out the SoC version numbers so
that we can compare. I know that some newer Tegra186 chips behave
slightly differently, so that's perhaps a difference that would explain
why it's not happening on all devices.

You can read the version and revision from sysfs using something like:

	# cat /sys/devices/soc0/{major,minor,revision}

> [...]
> 
> > > That'd be pretty annoying. Do you know if the Ethernet is a coherent
> > > device on this machine? or does it need active cache maintenance?
> > 
> > I don't think Ethernet is a coherent device on Tegra186. I think
> > Tegra194 had various improvements with regard to coherency, but most
> > devices on Tegra186 do need active cache maintenance.
> > 
> > Let me dig through some old patches and mailing list threads. I vaguely
> > recall prototyping a patch that did something special for outer cache
> > flushing, but that may have been Tegra132, not Tegra186. I also don't
> > think we ended up merging that because it turned out to not be needed.
> 
> ARMv8 forbid any sort of *visible* outer cache, so I really hope this
> is not required. We wouldn't be able to support it.

I couldn't find any trace of this anywhere. So I'm possibly
misremembering. It's also more likely that this was on an earlier SoC
generation, otherwise I'd probably remember more clearly.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Matteo Croce <mcroce@linux.microsoft.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Drew Fustini <drew@beagleboard.org>,
	Emil Renner Berthing <kernel@esmil.dk>,
	Jon Hunter <jonathanh@nvidia.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH net-next] stmmac: align RX buffers
Date: Fri, 13 Aug 2021 16:44:17 +0200	[thread overview]
Message-ID: <YRaFQRyD8fwc6PEz@orome.fritz.box> (raw)
In-Reply-To: <87v94a8z0u.wl-maz@kernel.org>


[-- Attachment #1.1: Type: text/plain, Size: 4066 bytes --]

On Thu, Aug 12, 2021 at 04:26:41PM +0100, Marc Zyngier wrote:
> On Thu, 12 Aug 2021 15:29:06 +0100,
> Thierry Reding <thierry.reding@gmail.com> wrote:
> > 
> > On Wed, Aug 11, 2021 at 02:23:10PM +0100, Marc Zyngier wrote:
> 
> [...]
> 
> > > I love this machine... Did this issue occur with the Denver CPUs
> > > disabled?
> > 
> > Interestingly I've been doing some work on a newer device called Jetson
> > TX2 NX (which is kind of a trimmed-down version of Jetson TX2, in the
> > spirit of the Jetson Nano) and I can't seem to reproduce these failures
> > there (tested on next-20210812).
> > 
> > I'll go dig out my Jetson TX2 to run the same tests there, because I've
> > also been using a development version of the bootloader stack and
> > flashing tools and all that, so it's possible that something was fixed
> > at that level. I don't think I've ever tried disabling the Denver CPUs,
> > but then I've also never seen these issues myself.
> > 
> > Just out of curiosity, what version of the BSP have you been using to
> > flash?
> 
> I've only used the BSP for a few weeks when I got the board last
> year. The only thing I use from it is u-boot to chainload an upstream
> u-boot, and boot Debian from there.

That's interesting... have you ever tried to inject a version of
upstream U-Boot into the BSP and have it flash that instead? That should
allow you to drop the chainloading step.

Not that that's likely to have anything to do with this.

> > One other thing that I ran into: there's a known issue with the PHY
> > configuration. We mark the PHY on most devices as "rgmii-id" on most
> > devices and then the Marvell PHY driver needs to be enabled. Jetson TX2
> > has phy-mode = "rgmii", so it /should/ work okay.
> > 
> > Typically what we're seeing with that misconfiguration is that the
> > device fails to get an IP address, but it might still be worth trying to
> > switch Jetson TX2 to rgmii-id and using the Marvell PHY, to see if that
> > improves anything.
> 
> I never failed to get an IP address. Overall, networking has been
> solid on this machine until this patch. I'll try and mess with this
> when I get time, but that's probably going to be next week now.

So I've hooked up my Jetson TX2 and tried various workloads. I wasn't
able to reproduce this on next-20210813. I've tried both the L4T 32.6.1
release and a local development build.

Perhaps one thing to try would be to upgrade your L4T BSP to something
newer. I know that there have occasionally been bugs in the MTS
firmware, which is what's running on the Denver cores, and newer BSPs
can fix those kinds of issues.

If that doesn't help, perhaps try to read out the SoC version numbers so
that we can compare. I know that some newer Tegra186 chips behave
slightly differently, so that's perhaps a difference that would explain
why it's not happening on all devices.

You can read the version and revision from sysfs using something like:

	# cat /sys/devices/soc0/{major,minor,revision}

> [...]
> 
> > > That'd be pretty annoying. Do you know if the Ethernet is a coherent
> > > device on this machine? or does it need active cache maintenance?
> > 
> > I don't think Ethernet is a coherent device on Tegra186. I think
> > Tegra194 had various improvements with regard to coherency, but most
> > devices on Tegra186 do need active cache maintenance.
> > 
> > Let me dig through some old patches and mailing list threads. I vaguely
> > recall prototyping a patch that did something special for outer cache
> > flushing, but that may have been Tegra132, not Tegra186. I also don't
> > think we ended up merging that because it turned out to not be needed.
> 
> ARMv8 forbid any sort of *visible* outer cache, so I really hope this
> is not required. We wouldn't be able to support it.

I couldn't find any trace of this anywhere. So I'm possibly
misremembering. It's also more likely that this was on an earlier SoC
generation, otherwise I'd probably remember more clearly.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2021-08-13 14:44 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14  2:25 [PATCH net-next] stmmac: align RX buffers Matteo Croce
2021-06-14  2:25 ` Matteo Croce
2021-06-14 19:51 ` David Miller
2021-06-14 19:51   ` David Miller
2021-06-14 23:21   ` Matteo Croce
2021-06-14 23:21     ` Matteo Croce
2021-06-15 17:28     ` David Miller
2021-06-15 17:28       ` David Miller
2021-06-15 17:30 ` patchwork-bot+netdevbpf
2021-06-15 17:30   ` patchwork-bot+netdevbpf
2021-08-10 19:07 ` Marc Zyngier
2021-08-10 19:07   ` Marc Zyngier
2021-08-11 10:28   ` Thierry Reding
2021-08-11 10:28     ` Thierry Reding
2021-08-11 12:53     ` Eric Dumazet
2021-08-11 12:53       ` Eric Dumazet
2021-08-11 14:16       ` Marc Zyngier
2021-08-11 14:16         ` Marc Zyngier
2021-08-12  8:48         ` Eric Dumazet
2021-08-12  8:48           ` Eric Dumazet
2021-08-12 10:18           ` Matteo Croce
2021-08-12 10:18             ` Matteo Croce
2021-08-12 11:05             ` Marc Zyngier
2021-08-12 11:05               ` Marc Zyngier
2021-08-12 11:18               ` Matteo Croce
2021-08-12 11:18                 ` Matteo Croce
2021-08-19 16:29                 ` Marc Zyngier
2021-08-19 16:29                   ` Marc Zyngier
2021-08-20 10:37                   ` Matteo Croce
2021-08-20 10:37                     ` Matteo Croce
2021-08-20 16:26                     ` Marc Zyngier
2021-08-20 16:26                       ` Marc Zyngier
2021-08-20 16:38                       ` Matteo Croce
2021-08-20 16:38                         ` Matteo Croce
2021-08-20 17:09                         ` Marc Zyngier
2021-08-20 17:09                           ` Marc Zyngier
2021-08-20 17:14                           ` Matteo Croce
2021-08-20 17:14                             ` Matteo Croce
2021-08-20 17:24                             ` Marc Zyngier
2021-08-20 17:24                               ` Marc Zyngier
2021-08-20 17:35                               ` Matteo Croce
2021-08-20 17:35                                 ` Matteo Croce
2021-08-20 17:51                                 ` Marc Zyngier
2021-08-20 17:51                                   ` Marc Zyngier
2021-08-20 17:56                                   ` Matteo Croce
2021-08-20 17:56                                     ` Matteo Croce
2021-08-20 18:05                                     ` Matteo Croce
2021-08-20 18:05                                       ` Matteo Croce
2021-08-20 18:14                                       ` Marc Zyngier
2021-08-20 18:14                                         ` Marc Zyngier
2021-08-20 18:09                                     ` Marc Zyngier
2021-08-20 18:09                                       ` Marc Zyngier
2021-08-20 18:14                                       ` Matteo Croce
2021-08-20 18:14                                         ` Matteo Croce
2021-08-20 18:41                                         ` Marc Zyngier
2021-08-20 18:41                                           ` Marc Zyngier
2021-08-16 15:12               ` Jakub Kicinski
2021-08-16 15:12                 ` Jakub Kicinski
2021-08-17  0:01                 ` Matteo Croce
2021-08-17  0:01                   ` Matteo Croce
2021-08-19 15:26                   ` Marc Zyngier
2021-08-19 15:26                     ` Marc Zyngier
2021-08-11 10:41   ` Thierry Reding
2021-08-11 10:41     ` Thierry Reding
2021-08-11 10:56     ` Joakim Zhang
2021-08-11 10:56       ` Joakim Zhang
2021-08-11 13:23     ` Marc Zyngier
2021-08-11 13:23       ` Marc Zyngier
2021-08-12 14:29       ` Thierry Reding
2021-08-12 14:29         ` Thierry Reding
2021-08-12 15:26         ` Marc Zyngier
2021-08-12 15:26           ` Marc Zyngier
2021-08-13 14:44           ` Thierry Reding [this message]
2021-08-13 14:44             ` Thierry Reding

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=YRaFQRyD8fwc6PEz@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=davem@davemloft.net \
    --cc=drew@beagleboard.org \
    --cc=jonathanh@nvidia.com \
    --cc=kernel@esmil.dk \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=mcroce@linux.microsoft.com \
    --cc=netdev@vger.kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peppe.cavallaro@st.com \
    --cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.