From: Simon Huelck <simonmail@gmx.de> To: martin.blumenstingl@googlemail.com, linux-amlogic@lists.infradead.org, netdev@vger.kernel.org, Gpeppe.cavallaro@st.com, alexandre.torgue@st.com Subject: Re: stmmac / meson8b-dwmac Date: Thu, 17 Jan 2019 22:23:53 +0100 [thread overview] Message-ID: <e05b7448-cd95-cdeb-c88d-3a324d5f1ddc@gmx.de> (raw) In-Reply-To: <CAFBinCDebPOsmrhSXecx48nGWHh7g_OGPbr1Y0M+n_v9Ht91ew@mail.gmail.com> Am 17.01.2019 um 21:57 schrieb Martin Blumenstingl: > Hi Simon, > > On Thu, Jan 17, 2019 at 7:53 PM Simon Huelck <simonmail@gmx.de> wrote: >> Hi Martin, >> >> >> deutsch ? > theoretisch: ja, das endet bei mir aber in einem komischen Mix aus > deutsch und englisch, von daher... > >> I got problems with my ODROID c2 running on 4.19.16 ( and some releases >> earlier ). the stmmac / dwmac driver doesnt provide the 800M/900M >> performance that i was used to earlier. >> >> >> Now im stuck near 550M/600M in the same environment. but what really >> confuses me that duplex does hurt even more. > interesting that you see this on the Odroid-C2 as well. > previously I have only observed it on an Odroid-C1 > >> PC --- VLAN3 --> switch --VLAN3--> ODROID >> >> NAS <-- VLAN1 -- switch <-- VLAN1-- ODROID >> >> >> this means when im doing a iperf from PC to NAS, that my ODROID has load >> on RX/TX same time (duplex). this shouldnt be an issue , all is 1GBits >> FD. And in the past that wasnt an issue. >> >> >> Now what happens: >> >> - benchmark between PC - ODROID is roughly 550M >> >> - benchmark between NAS - ODROID is roughly 550M >> >> - benchmark between PC - NAS is only around 300M >> >> >> and like i said i was easliy able to hit 800 or even 900M to my NAS >> earlier. I applied some .dtb fixes for interrupt levels for the >> meson-gx.dtsi and meson-gxbb-odroid-c2.dtb, which will be mainlined , >> but the effect stayed identical. > good that you have the interrupt patches already applied > I believe it don't fix any performance issues - it's a fix for the > Ethernet controller seemingly getting "stuck" (not processing data > anymore). however, that already rules out one potential issue > >> are you aware of this problem ? Earlier kernel versions were all >> perfectly fine and i stepped ( self compiled) kernel through all major >> releases since odroid c2 was mainlined. > I'm not aware of this - so it would be great if you could re-send your mail to: > - the mainline Amlogic mailing list at: linux-amlogic@lists.infradead.org > - the netdev mailing list (where all the networking people discuss > their issues): netdev@vger.kernel.org > - the stmmac maintainers: Gpeppe.cavallaro@st.com, > alexandre.torgue@st.com, joabreu@synopsys.com ok , will do so > > it's great that you stepped through various releases in the past. > you can even help us to get closer to the root cause of the problem > using git bisect. in case you haven't used git bisect yet:: > - git bisect start > - git bisect good v4.18 (assuming v4.18 was good) > - git bisect bad v4.19 (assuming v4.19 is bad) > - the repeat the following: > -- (git will checkout a different revision and ask you to test it) > -- compile, boot the kernel and test whether your problem still exists > -- enter either "git bisect good", "git bisect bad" or "git bisect > skip" (for example if the revision doesn't compile, your board doesn't > start with it, ...) > > git bisect will output one commit which is likely to be the cause (or > at least a puzzle piece which points to the root cause) the problem is that i dont have these kernel sources anymore :-(. but i can provide some testing and numbers. maybe i dig if i got these kernel configs somewhere around but i did not change much during migrating im using a zyxel gs1900-8 switch and a qnap ts231p , and as i said i didnt change my setup. i was able to hit 100MByte/s from my NAS , so close to the benchmarks of 900MBit/s > > > Regards > Martin
WARNING: multiple messages have this Message-ID (diff)
From: Simon Huelck <simonmail@gmx.de> To: martin.blumenstingl@googlemail.com, linux-amlogic@lists.infradead.org, netdev@vger.kernel.org, Gpeppe.cavallaro@st.com, alexandre.torgue@st.com Subject: Re: stmmac / meson8b-dwmac Date: Thu, 17 Jan 2019 22:23:53 +0100 [thread overview] Message-ID: <e05b7448-cd95-cdeb-c88d-3a324d5f1ddc@gmx.de> (raw) In-Reply-To: <CAFBinCDebPOsmrhSXecx48nGWHh7g_OGPbr1Y0M+n_v9Ht91ew@mail.gmail.com> Am 17.01.2019 um 21:57 schrieb Martin Blumenstingl: > Hi Simon, > > On Thu, Jan 17, 2019 at 7:53 PM Simon Huelck <simonmail@gmx.de> wrote: >> Hi Martin, >> >> >> deutsch ? > theoretisch: ja, das endet bei mir aber in einem komischen Mix aus > deutsch und englisch, von daher... > >> I got problems with my ODROID c2 running on 4.19.16 ( and some releases >> earlier ). the stmmac / dwmac driver doesnt provide the 800M/900M >> performance that i was used to earlier. >> >> >> Now im stuck near 550M/600M in the same environment. but what really >> confuses me that duplex does hurt even more. > interesting that you see this on the Odroid-C2 as well. > previously I have only observed it on an Odroid-C1 > >> PC --- VLAN3 --> switch --VLAN3--> ODROID >> >> NAS <-- VLAN1 -- switch <-- VLAN1-- ODROID >> >> >> this means when im doing a iperf from PC to NAS, that my ODROID has load >> on RX/TX same time (duplex). this shouldnt be an issue , all is 1GBits >> FD. And in the past that wasnt an issue. >> >> >> Now what happens: >> >> - benchmark between PC - ODROID is roughly 550M >> >> - benchmark between NAS - ODROID is roughly 550M >> >> - benchmark between PC - NAS is only around 300M >> >> >> and like i said i was easliy able to hit 800 or even 900M to my NAS >> earlier. I applied some .dtb fixes for interrupt levels for the >> meson-gx.dtsi and meson-gxbb-odroid-c2.dtb, which will be mainlined , >> but the effect stayed identical. > good that you have the interrupt patches already applied > I believe it don't fix any performance issues - it's a fix for the > Ethernet controller seemingly getting "stuck" (not processing data > anymore). however, that already rules out one potential issue > >> are you aware of this problem ? Earlier kernel versions were all >> perfectly fine and i stepped ( self compiled) kernel through all major >> releases since odroid c2 was mainlined. > I'm not aware of this - so it would be great if you could re-send your mail to: > - the mainline Amlogic mailing list at: linux-amlogic@lists.infradead.org > - the netdev mailing list (where all the networking people discuss > their issues): netdev@vger.kernel.org > - the stmmac maintainers: Gpeppe.cavallaro@st.com, > alexandre.torgue@st.com, joabreu@synopsys.com ok , will do so > > it's great that you stepped through various releases in the past. > you can even help us to get closer to the root cause of the problem > using git bisect. in case you haven't used git bisect yet:: > - git bisect start > - git bisect good v4.18 (assuming v4.18 was good) > - git bisect bad v4.19 (assuming v4.19 is bad) > - the repeat the following: > -- (git will checkout a different revision and ask you to test it) > -- compile, boot the kernel and test whether your problem still exists > -- enter either "git bisect good", "git bisect bad" or "git bisect > skip" (for example if the revision doesn't compile, your board doesn't > start with it, ...) > > git bisect will output one commit which is likely to be the cause (or > at least a puzzle piece which points to the root cause) the problem is that i dont have these kernel sources anymore :-(. but i can provide some testing and numbers. maybe i dig if i got these kernel configs somewhere around but i did not change much during migrating im using a zyxel gs1900-8 switch and a qnap ts231p , and as i said i didnt change my setup. i was able to hit 100MByte/s from my NAS , so close to the benchmarks of 900MBit/s > > > Regards > Martin _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic
next parent reply other threads:[~2019-01-17 21:24 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <a38e643c-ed9f-c306-cc95-84f70ebc1f10@gmx.de> [not found] ` <CAFBinCDebPOsmrhSXecx48nGWHh7g_OGPbr1Y0M+n_v9Ht91ew@mail.gmail.com> 2019-01-17 21:23 ` Simon Huelck [this message] 2019-01-17 21:23 ` stmmac / meson8b-dwmac Simon Huelck 2019-02-04 14:34 ` Martin Blumenstingl 2019-02-04 14:34 ` Martin Blumenstingl 2019-02-06 10:36 ` Emiliano Ingrassia 2019-02-06 10:36 ` Emiliano Ingrassia 2019-02-06 18:04 ` Simon Huelck 2019-02-06 18:04 ` Simon Huelck 2019-02-06 21:21 ` Simon Huelck 2019-02-06 21:21 ` Simon Huelck 2019-02-07 19:30 ` Simon Huelck 2019-02-07 19:30 ` Simon Huelck 2019-02-09 1:09 ` Martin Blumenstingl 2019-02-09 1:09 ` Martin Blumenstingl 2019-02-11 13:44 ` Jose Abreu 2019-02-11 13:44 ` Jose Abreu 2019-02-14 7:21 ` Simon Huelck 2019-02-14 7:21 ` Simon Huelck 2019-02-17 14:48 ` Martin Blumenstingl 2019-02-17 14:48 ` Martin Blumenstingl 2019-02-17 19:13 ` Simon Huelck 2019-02-17 19:13 ` Simon Huelck 2019-02-18 8:42 ` Jose Abreu 2019-02-18 8:42 ` Jose Abreu 2019-02-18 8:45 ` Jose Abreu 2019-02-18 8:45 ` Jose Abreu 2019-02-18 12:33 ` Simon Huelck 2019-02-18 12:33 ` Simon Huelck 2019-02-18 12:41 ` Jose Abreu 2019-02-18 12:41 ` Jose Abreu 2019-02-18 13:02 ` Jose Abreu 2019-02-18 13:02 ` Jose Abreu 2019-02-18 15:29 ` Simon Huelck 2019-02-18 15:29 ` Simon Huelck 2019-02-18 15:31 ` Jose Abreu 2019-02-18 15:31 ` Jose Abreu 2019-02-18 15:53 ` Simon Huelck 2019-02-18 15:53 ` Simon Huelck 2019-02-18 16:26 ` Jose Abreu 2019-02-18 16:26 ` Jose Abreu 2019-02-18 16:40 ` Simon Huelck 2019-02-18 16:40 ` Simon Huelck 2019-02-18 16:43 ` Jose Abreu 2019-02-18 16:43 ` Jose Abreu 2019-02-18 16:51 ` Simon Huelck 2019-02-18 16:51 ` Simon Huelck 2019-02-18 17:05 ` Jose Abreu 2019-02-18 17:05 ` Jose Abreu 2019-02-18 18:05 ` Simon Huelck 2019-02-18 18:05 ` Simon Huelck 2019-02-19 8:47 ` Jose Abreu 2019-02-19 8:47 ` Jose Abreu 2019-02-19 19:41 ` Simon Huelck 2019-02-19 19:41 ` Simon Huelck 2019-02-21 14:21 ` Jerome Brunet 2019-02-21 14:21 ` Jerome Brunet 2019-02-21 17:27 ` Simon Huelck 2019-02-21 17:27 ` Simon Huelck 2019-02-21 17:46 ` Jerome Brunet 2019-02-21 17:46 ` Jerome Brunet 2019-02-21 19:34 ` Simon Huelck 2019-02-21 19:34 ` Simon Huelck 2019-02-22 17:21 ` Anand Moon 2019-02-22 17:21 ` Anand Moon 2019-02-24 15:00 ` Simon Huelck 2019-02-24 15:00 ` Simon Huelck 2019-02-24 15:02 ` Simon Huelck 2019-02-24 15:02 ` Simon Huelck 2019-02-24 19:42 ` Sebastian Gottschall 2019-02-24 19:42 ` Sebastian Gottschall 2019-02-24 20:34 ` Simon Huelck 2019-02-24 20:34 ` Simon Huelck 2019-02-27 11:09 ` Jose Abreu 2019-02-27 11:09 ` Jose Abreu 2019-02-27 19:02 ` Simon Huelck 2019-02-27 19:02 ` Simon Huelck 2019-03-01 9:23 ` Jose Abreu 2019-03-01 9:23 ` Jose Abreu 2019-03-05 9:55 ` Simon Huelck 2019-03-05 9:55 ` Simon Huelck 2019-03-06 11:35 ` Simon Huelck 2019-03-06 11:35 ` Simon Huelck 2019-03-06 11:45 ` Simon Huelck 2019-03-06 11:45 ` Simon Huelck 2019-05-11 14:53 ` Simon Huelck 2019-05-11 14:53 ` Simon Huelck 2019-05-13 9:07 ` Jose Abreu 2019-05-13 9:07 ` Jose Abreu 2019-05-22 12:48 ` Simon Huelck 2019-05-22 12:48 ` Simon Huelck 2019-05-22 14:02 ` Neil Armstrong 2019-05-22 14:02 ` Neil Armstrong 2019-02-27 21:03 ` Simon Huelck 2019-02-27 21:03 ` Simon Huelck 2019-02-18 17:05 ` Simon Huelck 2019-02-18 17:05 ` Simon Huelck
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=e05b7448-cd95-cdeb-c88d-3a324d5f1ddc@gmx.de \ --to=simonmail@gmx.de \ --cc=Gpeppe.cavallaro@st.com \ --cc=alexandre.torgue@st.com \ --cc=linux-amlogic@lists.infradead.org \ --cc=martin.blumenstingl@googlemail.com \ --cc=netdev@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: 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.