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
next prev parent 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: linkBe 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.