* Re: stmmac / meson8b-dwmac [not found] ` <CAFBinCDebPOsmrhSXecx48nGWHh7g_OGPbr1Y0M+n_v9Ht91ew@mail.gmail.com> @ 2019-01-17 21:23 ` Simon Huelck 2019-02-04 14:34 ` Martin Blumenstingl 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-01-17 21:23 UTC (permalink / raw) To: martin.blumenstingl, linux-amlogic, netdev, Gpeppe.cavallaro, alexandre.torgue 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-01-17 21:23 ` stmmac / meson8b-dwmac Simon Huelck @ 2019-02-04 14:34 ` Martin Blumenstingl 2019-02-06 10:36 ` Emiliano Ingrassia 0 siblings, 1 reply; 48+ messages in thread From: Martin Blumenstingl @ 2019-02-04 14:34 UTC (permalink / raw) To: ingrassia, Gpeppe.cavallaro, alexandre.torgue Cc: Simon Huelck, linux-amlogic, netdev On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck <simonmail@gmx.de> wrote: [...] > >> 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. +Cc Emiliano who has seen a similar duplex issue on his Odroid-C1: [0] (please note that all kernels prior to v5.1 with the pending patches from [1] applied are only receiving data on RXD0 and RXD1 but not on RXD2 and RXD3) Emiliano, can you confirm the duplex issue observed by Simon is similar to the one you see on your Odroid-C1? > >> > >> > >> 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. Guiseppe, Alexandre: what kind of data do you need from us if we see the speeds drop (in both directions) when we send and receive at the same time? [...] > 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 do you remember the kernel version where it worked fine? > 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 I typically only do small transfers or I have traffic only in one direction. thus it's likely that I missed this in my own tests Regards Martin [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009679.html [1] https://patchwork.kernel.org/cover/10744905/ ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-04 14:34 ` Martin Blumenstingl @ 2019-02-06 10:36 ` Emiliano Ingrassia 2019-02-06 18:04 ` Simon Huelck ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Emiliano Ingrassia @ 2019-02-06 10:36 UTC (permalink / raw) To: Martin Blumenstingl, Simon Huelck Cc: Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi Martin, Hi Simon, On Mon, Feb 04, 2019 at 03:34:41PM +0100, Martin Blumenstingl wrote: > On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck <simonmail@gmx.de> wrote: > [...] > > >> 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. > > >> Simon, did you ever reach 1 Gbps full duplex speed? If yes, what was the kernel version did you use? > > >> > > >> 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. > +Cc Emiliano who has seen a similar duplex issue on his Odroid-C1: [0] > (please note that all kernels prior to v5.1 with the pending patches > from [1] applied are only receiving data on RXD0 and RXD1 but not on > RXD2 and RXD3) > > Emiliano, can you confirm the duplex issue observed by Simon is > similar to the one you see on your Odroid-C1? > It could be but, if I understand correctly, Simon is limited in speed also in half duplex transmission (~550/600 Mbps), while we can reach at least 900 Mbps. > > >> > > >> > > >> 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. > Guiseppe, Alexandre: what kind of data do you need from us if we see > the speeds drop (in both directions) when we send and receive at the > same time? > > [...] > > 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 > do you remember the kernel version where it worked fine? > > > 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 > I typically only do small transfers or I have traffic only in one direction. > thus it's likely that I missed this in my own tests > > > Regards > Martin > > > [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009679.html > [1] https://patchwork.kernel.org/cover/10744905/ Regards, Emiliano ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-06 10:36 ` Emiliano Ingrassia @ 2019-02-06 18:04 ` Simon Huelck 2019-02-06 21:21 ` Simon Huelck 2019-02-07 19:30 ` Simon Huelck 2 siblings, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-02-06 18:04 UTC (permalink / raw) To: Emiliano Ingrassia, Martin Blumenstingl Cc: Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi, yes i did reach 900MBits . maybe it was kernel 4.14 or 4.17. The 3.x series was also ok. I will pull latest 4.17 and test. If this doesnt work i go for 4.14 regards, Simon Am 06.02.2019 um 11:36 schrieb Emiliano Ingrassia: > Hi Martin, Hi Simon, > > On Mon, Feb 04, 2019 at 03:34:41PM +0100, Martin Blumenstingl wrote: >> On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck <simonmail@gmx.de> wrote: >> [...] >>>>> 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. >>>>> > Simon, did you ever reach 1 Gbps full duplex speed? > If yes, what was the kernel version did you use? > >>>>> 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. >> +Cc Emiliano who has seen a similar duplex issue on his Odroid-C1: [0] >> (please note that all kernels prior to v5.1 with the pending patches >> from [1] applied are only receiving data on RXD0 and RXD1 but not on >> RXD2 and RXD3) >> >> Emiliano, can you confirm the duplex issue observed by Simon is >> similar to the one you see on your Odroid-C1? >> > It could be but, if I understand correctly, Simon is limited in > speed also in half duplex transmission (~550/600 Mbps), while we can > reach at least 900 Mbps. > >>>>> >>>>> 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. >> Guiseppe, Alexandre: what kind of data do you need from us if we see >> the speeds drop (in both directions) when we send and receive at the >> same time? >> >> [...] >>> 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 >> do you remember the kernel version where it worked fine? >> >>> 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 >> I typically only do small transfers or I have traffic only in one direction. >> thus it's likely that I missed this in my own tests >> >> >> Regards >> Martin >> >> >> [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009679.html >> [1] https://patchwork.kernel.org/cover/10744905/ > Regards, > > Emiliano ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-06 10:36 ` Emiliano Ingrassia 2019-02-06 18:04 ` Simon Huelck @ 2019-02-06 21:21 ` Simon Huelck 2019-02-07 19:30 ` Simon Huelck 2 siblings, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-02-06 21:21 UTC (permalink / raw) To: Emiliano Ingrassia, Martin Blumenstingl Cc: Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi, 4.17.9 failed going back further regards, Simon Am 06.02.2019 um 11:36 schrieb Emiliano Ingrassia: > Hi Martin, Hi Simon, > > On Mon, Feb 04, 2019 at 03:34:41PM +0100, Martin Blumenstingl wrote: >> On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck <simonmail@gmx.de> wrote: >> [...] >>>>> 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. >>>>> > Simon, did you ever reach 1 Gbps full duplex speed? > If yes, what was the kernel version did you use? > >>>>> 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. >> +Cc Emiliano who has seen a similar duplex issue on his Odroid-C1: [0] >> (please note that all kernels prior to v5.1 with the pending patches >> from [1] applied are only receiving data on RXD0 and RXD1 but not on >> RXD2 and RXD3) >> >> Emiliano, can you confirm the duplex issue observed by Simon is >> similar to the one you see on your Odroid-C1? >> > It could be but, if I understand correctly, Simon is limited in > speed also in half duplex transmission (~550/600 Mbps), while we can > reach at least 900 Mbps. > >>>>> >>>>> 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. >> Guiseppe, Alexandre: what kind of data do you need from us if we see >> the speeds drop (in both directions) when we send and receive at the >> same time? >> >> [...] >>> 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 >> do you remember the kernel version where it worked fine? >> >>> 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 >> I typically only do small transfers or I have traffic only in one direction. >> thus it's likely that I missed this in my own tests >> >> >> Regards >> Martin >> >> >> [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009679.html >> [1] https://patchwork.kernel.org/cover/10744905/ > Regards, > > Emiliano ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-06 10:36 ` Emiliano Ingrassia 2019-02-06 18:04 ` Simon Huelck 2019-02-06 21:21 ` Simon Huelck @ 2019-02-07 19:30 ` Simon Huelck 2019-02-09 1:09 ` Martin Blumenstingl 2 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-07 19:30 UTC (permalink / raw) To: Emiliano Ingrassia, Martin Blumenstingl Cc: Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi Guys, i can confirm better performance with 4.14.29 - ~900 MBits with iperf2 in one way -~ 500 - 600MBits with iperf2 in duplex in both directions This wasnt the case with 4.17.9, not with 4.18, 4.19 or the 5.0 series..... How can i help further ? regards, Simon Am 06.02.2019 um 11:36 schrieb Emiliano Ingrassia: > Hi Martin, Hi Simon, > > On Mon, Feb 04, 2019 at 03:34:41PM +0100, Martin Blumenstingl wrote: >> On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck <simonmail@gmx.de> wrote: >> [...] >>>>> 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. >>>>> > Simon, did you ever reach 1 Gbps full duplex speed? > If yes, what was the kernel version did you use? > >>>>> 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. >> +Cc Emiliano who has seen a similar duplex issue on his Odroid-C1: [0] >> (please note that all kernels prior to v5.1 with the pending patches >> from [1] applied are only receiving data on RXD0 and RXD1 but not on >> RXD2 and RXD3) >> >> Emiliano, can you confirm the duplex issue observed by Simon is >> similar to the one you see on your Odroid-C1? >> > It could be but, if I understand correctly, Simon is limited in > speed also in half duplex transmission (~550/600 Mbps), while we can > reach at least 900 Mbps. > >>>>> >>>>> 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. >> Guiseppe, Alexandre: what kind of data do you need from us if we see >> the speeds drop (in both directions) when we send and receive at the >> same time? >> >> [...] >>> 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 >> do you remember the kernel version where it worked fine? >> >>> 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 >> I typically only do small transfers or I have traffic only in one direction. >> thus it's likely that I missed this in my own tests >> >> >> Regards >> Martin >> >> >> [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009679.html >> [1] https://patchwork.kernel.org/cover/10744905/ > Regards, > > Emiliano ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-07 19:30 ` Simon Huelck @ 2019-02-09 1:09 ` Martin Blumenstingl 2019-02-11 13:44 ` Jose Abreu 0 siblings, 1 reply; 48+ messages in thread From: Martin Blumenstingl @ 2019-02-09 1:09 UTC (permalink / raw) To: Simon Huelck Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi Simon, On Thu, Feb 7, 2019 at 8:30 PM Simon Huelck <simonmail@gmx.de> wrote: > > Hi Guys, > > > i can confirm better performance with 4.14.29 > > - ~900 MBits with iperf2 in one way > -~ 500 - 600MBits with iperf2 in duplex in both directions > > > This wasnt the case with 4.17.9, not with 4.18, 4.19 or the 5.0 series..... I just did a small test myself on a Khadas VIM2: # iperf3 -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.189 port 37192 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 113 MBytes 946 Mbits/sec 0 354 KBytes [ 5] 1.00-2.00 sec 112 MBytes 940 Mbits/sec 0 354 KBytes [ 5] 2.00-3.00 sec 110 MBytes 920 Mbits/sec 241 228 KBytes [ 5] 3.00-4.00 sec 112 MBytes 940 Mbits/sec 0 314 KBytes [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 89 83.4 KBytes [ 5] 5.00-6.00 sec 110 MBytes 926 Mbits/sec 115 335 KBytes [ 5] 6.00-7.00 sec 112 MBytes 941 Mbits/sec 0 358 KBytes [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 0 362 KBytes [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 369 KBytes [ 5] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 0 372 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec 445 sender [ 5] 0.00-10.04 sec 1.09 GBytes 932 Mbits/sec receiver iperf Done. (it's interesting that the sending direction has 445 retries) # iperf3 -c 192.168.1.100 -R Connecting to host 192.168.1.100, port 5201 Reverse mode, remote host 192.168.1.100 is sending [ 5] local 192.168.1.189 port 37196 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 90.9 MBytes 763 Mbits/sec [ 5] 1.00-2.00 sec 90.9 MBytes 762 Mbits/sec [ 5] 2.00-3.00 sec 90.7 MBytes 760 Mbits/sec [ 5] 3.00-4.00 sec 91.3 MBytes 766 Mbits/sec [ 5] 4.00-5.00 sec 91.1 MBytes 764 Mbits/sec [ 5] 5.00-6.00 sec 91.1 MBytes 765 Mbits/sec [ 5] 6.00-7.00 sec 90.8 MBytes 762 Mbits/sec [ 5] 7.00-8.00 sec 90.9 MBytes 762 Mbits/sec [ 5] 8.00-9.00 sec 91.0 MBytes 764 Mbits/sec [ 5] 9.00-10.00 sec 91.3 MBytes 766 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.04 sec 911 MBytes 762 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 910 MBytes 763 Mbits/sec receiver iperf Done. (when receiving I see no retries) for my test I used my Khadas VIM2 (as I don't have a GXBB board anymore). test setup: PC -> built-in switch in some ath79 based OpenWrt device -> VIM2. no VLANs are used revision: latest mainline, which at the time of testing is: 46c291e277f937378 ("Merge tag 'armsoc-fixes-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc") > How can i help further ? it's good to know that 4.14 has "good" performance in your scenario can you please show the full iperf outputs for your tests (preferably on both, 4.14 and 5.0-rcX)? do you see any improvements on 5.0-rcX when not using VLANs (this is just a random guess)? Regards Martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-09 1:09 ` Martin Blumenstingl @ 2019-02-11 13:44 ` Jose Abreu 2019-02-14 7:21 ` Simon Huelck 2019-02-17 14:48 ` Martin Blumenstingl 0 siblings, 2 replies; 48+ messages in thread From: Jose Abreu @ 2019-02-11 13:44 UTC (permalink / raw) To: Martin Blumenstingl, Simon Huelck Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hello, On 2/9/2019 1:09 AM, Martin Blumenstingl wrote: > (it's interesting that the sending direction has 445 retries) I saw this before and I think it was related with COE. Can you please disable all offloading and try again? Anyway, maybe Simon should bissect ? I think since 4.14 there are not that many commits in stmmac / meson8b-dwmac that can cause this behavior. Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-11 13:44 ` Jose Abreu @ 2019-02-14 7:21 ` Simon Huelck 2019-02-17 14:48 ` Martin Blumenstingl 1 sibling, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-02-14 7:21 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi, i used iperf2 on my odroid c2 , since this can do duplex tests ! iperf2 -c 10.10.11.1 -i1 -d Do you really need the exact numbers ? NON-duplex: 4.14.29 reached 930 MBits without the -d ( duplex option ), 5.0rc5 only reaches 600MBits there DUPLEX: With the -d option things get worse on 4.14.29 , 600MBits in both directions. on 5.0rc5 this is the 500 to 600 in one direction, the other only 150MBits. iperf3 is not duplex capable, i didnt test the reverse option, but duplex tests show that one direction drops in performance when the other is busy. Do you really need the exact output ? I need to reflash my box then ..... if needed i would do so. regards, Simon Am 11.02.2019 um 14:44 schrieb Jose Abreu: > Hello, > > On 2/9/2019 1:09 AM, Martin Blumenstingl wrote: >> (it's interesting that the sending direction has 445 retries) > I saw this before and I think it was related with COE. Can you > please disable all offloading and try again? > > Anyway, maybe Simon should bissect ? I think since 4.14 there are > not that many commits in stmmac / meson8b-dwmac that can cause > this behavior. > > Thanks, > Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-11 13:44 ` Jose Abreu 2019-02-14 7:21 ` Simon Huelck @ 2019-02-17 14:48 ` Martin Blumenstingl 2019-02-17 19:13 ` Simon Huelck 2019-02-18 8:42 ` Jose Abreu 1 sibling, 2 replies; 48+ messages in thread From: Martin Blumenstingl @ 2019-02-17 14:48 UTC (permalink / raw) To: Jose Abreu Cc: Simon Huelck, Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hello Jose, On Mon, Feb 11, 2019 at 2:45 PM Jose Abreu <jose.abreu@synopsys.com> wrote: > > Hello, > > On 2/9/2019 1:09 AM, Martin Blumenstingl wrote: > > (it's interesting that the sending direction has 445 retries) > > I saw this before and I think it was related with COE. Can you > please disable all offloading and try again? OK, details are: (before doing anything) # ethtool -k eth0 Features for eth0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: on tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: on tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off [fixed] tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off [fixed] tx-tcp6-segmentation: off [fixed] udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: off [fixed] tx-vlan-offload: off [fixed] ntuple-filters: off [fixed] receive-hashing: off [fixed] highdma: on [fixed] rx-vlan-filter: off [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-gre-csum-segmentation: off [fixed] tx-ipxip4-segmentation: off [fixed] tx-ipxip6-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-udp_tnl-csum-segmentation: off [fixed] tx-gso-partial: off [fixed] tx-sctp-segmentation: off [fixed] tx-esp-segmentation: off [fixed] tx-udp-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] hw-tc-offload: off [fixed] esp-hw-offload: off [fixed] esp-tx-csum-hw-offload: off [fixed] rx-udp_tunnel-port-offload: off [fixed] tls-hw-tx-offload: off [fixed] tls-hw-rx-offload: off [fixed] rx-gro-hw: off [fixed] tls-hw-record: off [fixed] this causes retries when running iperf3 in transmit mode. with offloading disabled: # ethtool -K eth0 rx off tx off # ethtool -k eth0 Features for eth0: rx-checksumming: off tx-checksumming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off [fixed] tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off [fixed] tx-tcp6-segmentation: off [fixed] udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: off [fixed] tx-vlan-offload: off [fixed] ntuple-filters: off [fixed] receive-hashing: off [fixed] highdma: on [fixed] rx-vlan-filter: off [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-gre-csum-segmentation: off [fixed] tx-ipxip4-segmentation: off [fixed] tx-ipxip6-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-udp_tnl-csum-segmentation: off [fixed] tx-gso-partial: off [fixed] tx-sctp-segmentation: off [fixed] tx-esp-segmentation: off [fixed] tx-udp-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] hw-tc-offload: off [fixed] esp-hw-offload: off [fixed] esp-tx-csum-hw-offload: off [fixed] rx-udp_tunnel-port-offload: off [fixed] tls-hw-tx-offload: off [fixed] tls-hw-rx-offload: off [fixed] rx-gro-hw: off [fixed] tls-hw-record: off [fixed] # iperf3 -c 192.168.1.100 Connecting to host 192.168.1.100, port 5201 [ 5] local 192.168.1.131 port 58412 connected to 192.168.1.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 112 MBytes 937 Mbits/sec 32 59.4 KBytes [ 5] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 25 290 KBytes [ 5] 2.00-3.00 sec 109 MBytes 915 Mbits/sec 150 279 KBytes [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 334 KBytes [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 342 KBytes [ 5] 5.00-6.00 sec 111 MBytes 934 Mbits/sec 98 320 KBytes [ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 123 76.4 KBytes [ 5] 7.00-8.00 sec 109 MBytes 917 Mbits/sec 119 277 KBytes [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 314 KBytes [ 5] 9.00-10.00 sec 112 MBytes 940 Mbits/sec 0 318 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec 547 sender [ 5] 0.00-10.04 sec 1.09 GBytes 929 Mbits/sec receiver iperf Done. so for me disabling offloading didn't change anything. Jose, is my command for disabling offloading correct? Simon, does disabling offloading improve anything in your iperf2 or real-world scenario on a kernel where you previously had performance issues? Regards Martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-17 14:48 ` Martin Blumenstingl @ 2019-02-17 19:13 ` Simon Huelck 2019-02-18 8:42 ` Jose Abreu 1 sibling, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-02-17 19:13 UTC (permalink / raw) To: Martin Blumenstingl, Jose Abreu Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi Martin, i repeated your commands , nothing changed the problematic result .... regards, Simon Am 17.02.2019 um 15:48 schrieb Martin Blumenstingl: > Hello Jose, > > On Mon, Feb 11, 2019 at 2:45 PM Jose Abreu <jose.abreu@synopsys.com> wrote: >> Hello, >> >> On 2/9/2019 1:09 AM, Martin Blumenstingl wrote: >>> (it's interesting that the sending direction has 445 retries) >> I saw this before and I think it was related with COE. Can you >> please disable all offloading and try again? > OK, details are: > > (before doing anything) > # ethtool -k eth0 > Features for eth0: > rx-checksumming: on > tx-checksumming: on > tx-checksum-ipv4: on > tx-checksum-ip-generic: off [fixed] > tx-checksum-ipv6: on > tx-checksum-fcoe-crc: off [fixed] > tx-checksum-sctp: off [fixed] > scatter-gather: on > tx-scatter-gather: on > tx-scatter-gather-fraglist: off [fixed] > tcp-segmentation-offload: off > tx-tcp-segmentation: off [fixed] > tx-tcp-ecn-segmentation: off [fixed] > tx-tcp-mangleid-segmentation: off [fixed] > tx-tcp6-segmentation: off [fixed] > udp-fragmentation-offload: off > generic-segmentation-offload: on > generic-receive-offload: on > large-receive-offload: off [fixed] > rx-vlan-offload: off [fixed] > tx-vlan-offload: off [fixed] > ntuple-filters: off [fixed] > receive-hashing: off [fixed] > highdma: on [fixed] > rx-vlan-filter: off [fixed] > vlan-challenged: off [fixed] > tx-lockless: off [fixed] > netns-local: off [fixed] > tx-gso-robust: off [fixed] > tx-fcoe-segmentation: off [fixed] > tx-gre-segmentation: off [fixed] > tx-gre-csum-segmentation: off [fixed] > tx-ipxip4-segmentation: off [fixed] > tx-ipxip6-segmentation: off [fixed] > tx-udp_tnl-segmentation: off [fixed] > tx-udp_tnl-csum-segmentation: off [fixed] > tx-gso-partial: off [fixed] > tx-sctp-segmentation: off [fixed] > tx-esp-segmentation: off [fixed] > tx-udp-segmentation: off [fixed] > fcoe-mtu: off [fixed] > tx-nocache-copy: off > loopback: off [fixed] > rx-fcs: off [fixed] > rx-all: off [fixed] > tx-vlan-stag-hw-insert: off [fixed] > rx-vlan-stag-hw-parse: off [fixed] > rx-vlan-stag-filter: off [fixed] > l2-fwd-offload: off [fixed] > hw-tc-offload: off [fixed] > esp-hw-offload: off [fixed] > esp-tx-csum-hw-offload: off [fixed] > rx-udp_tunnel-port-offload: off [fixed] > tls-hw-tx-offload: off [fixed] > tls-hw-rx-offload: off [fixed] > rx-gro-hw: off [fixed] > tls-hw-record: off [fixed] > > this causes retries when running iperf3 in transmit mode. > > with offloading disabled: > > # ethtool -K eth0 rx off tx off > # ethtool -k eth0 > Features for eth0: > rx-checksumming: off > tx-checksumming: off > tx-checksum-ipv4: off > tx-checksum-ip-generic: off [fixed] > tx-checksum-ipv6: off > tx-checksum-fcoe-crc: off [fixed] > tx-checksum-sctp: off [fixed] > scatter-gather: on > tx-scatter-gather: on > tx-scatter-gather-fraglist: off [fixed] > tcp-segmentation-offload: off > tx-tcp-segmentation: off [fixed] > tx-tcp-ecn-segmentation: off [fixed] > tx-tcp-mangleid-segmentation: off [fixed] > tx-tcp6-segmentation: off [fixed] > udp-fragmentation-offload: off > generic-segmentation-offload: on > generic-receive-offload: on > large-receive-offload: off [fixed] > rx-vlan-offload: off [fixed] > tx-vlan-offload: off [fixed] > ntuple-filters: off [fixed] > receive-hashing: off [fixed] > highdma: on [fixed] > rx-vlan-filter: off [fixed] > vlan-challenged: off [fixed] > tx-lockless: off [fixed] > netns-local: off [fixed] > tx-gso-robust: off [fixed] > tx-fcoe-segmentation: off [fixed] > tx-gre-segmentation: off [fixed] > tx-gre-csum-segmentation: off [fixed] > tx-ipxip4-segmentation: off [fixed] > tx-ipxip6-segmentation: off [fixed] > tx-udp_tnl-segmentation: off [fixed] > tx-udp_tnl-csum-segmentation: off [fixed] > tx-gso-partial: off [fixed] > tx-sctp-segmentation: off [fixed] > tx-esp-segmentation: off [fixed] > tx-udp-segmentation: off [fixed] > fcoe-mtu: off [fixed] > tx-nocache-copy: off > loopback: off [fixed] > rx-fcs: off [fixed] > rx-all: off [fixed] > tx-vlan-stag-hw-insert: off [fixed] > rx-vlan-stag-hw-parse: off [fixed] > rx-vlan-stag-filter: off [fixed] > l2-fwd-offload: off [fixed] > hw-tc-offload: off [fixed] > esp-hw-offload: off [fixed] > esp-tx-csum-hw-offload: off [fixed] > rx-udp_tunnel-port-offload: off [fixed] > tls-hw-tx-offload: off [fixed] > tls-hw-rx-offload: off [fixed] > rx-gro-hw: off [fixed] > tls-hw-record: off [fixed] > # iperf3 -c 192.168.1.100 > Connecting to host 192.168.1.100, port 5201 > [ 5] local 192.168.1.131 port 58412 connected to 192.168.1.100 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 112 MBytes 937 Mbits/sec 32 59.4 KBytes > [ 5] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 25 290 KBytes > [ 5] 2.00-3.00 sec 109 MBytes 915 Mbits/sec 150 279 KBytes > [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 334 KBytes > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 342 KBytes > [ 5] 5.00-6.00 sec 111 MBytes 934 Mbits/sec 98 320 KBytes > [ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 123 76.4 KBytes > [ 5] 7.00-8.00 sec 109 MBytes 917 Mbits/sec 119 277 KBytes > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 314 KBytes > [ 5] 9.00-10.00 sec 112 MBytes 940 Mbits/sec 0 318 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec 547 sender > [ 5] 0.00-10.04 sec 1.09 GBytes 929 Mbits/sec receiver > > iperf Done. > > so for me disabling offloading didn't change anything. > > Jose, is my command for disabling offloading correct? > Simon, does disabling offloading improve anything in your iperf2 or > real-world scenario on a kernel where you previously had performance > issues? > > > Regards > Martin ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-17 14:48 ` Martin Blumenstingl 2019-02-17 19:13 ` Simon Huelck @ 2019-02-18 8:42 ` Jose Abreu 2019-02-18 8:45 ` Jose Abreu 1 sibling, 1 reply; 48+ messages in thread From: Jose Abreu @ 2019-02-18 8:42 UTC (permalink / raw) To: Martin Blumenstingl, Jose Abreu Cc: Simon Huelck, Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev On 2/17/2019 2:48 PM, Martin Blumenstingl wrote: > Jose, is my command for disabling offloading correct? Yes, I think so. What about NIC statistics and logs ? ("ethtool -S eth0", "dmesg | grep -i stmmac") Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 8:42 ` Jose Abreu @ 2019-02-18 8:45 ` Jose Abreu 2019-02-18 12:33 ` Simon Huelck 0 siblings, 1 reply; 48+ messages in thread From: Jose Abreu @ 2019-02-18 8:45 UTC (permalink / raw) To: Martin Blumenstingl, Jose Abreu Cc: Simon Huelck, Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev On 2/18/2019 8:42 AM, Jose Abreu wrote: > On 2/17/2019 2:48 PM, Martin Blumenstingl wrote: >> Jose, is my command for disabling offloading correct? > > Yes, I think so. What about NIC statistics and logs ? ("ethtool > -S eth0", "dmesg | grep -i stmmac") And, "ifconfig eth0" after running the test. > > Thanks, > Jose Miguel Abreu > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 8:45 ` Jose Abreu @ 2019-02-18 12:33 ` Simon Huelck 2019-02-18 12:41 ` Jose Abreu 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-18 12:33 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi, i recognize the followin on my ethernet stats: threshold: 1 tx_pkt_n: 1457325 rx_pkt_n: 5022405 normal_irq_n: 671738 rx_normal_irq_n: 606573 napi_poll: 784439 tx_normal_irq_n: 61061 tx_clean: 784439 tx_set_ic_bit: 58293 irq_receive_pmt_irq_n: 0 mmc_tx_irq_n: 0 mmc_rx_irq_n: 0 mmc_rx_csum_offload_irq_n: 0 -> irq_tx_path_in_lpi_mode_n: 382037 -> irq_tx_path_exit_lpi_mode_n: 382021 Is this normal ? regards, Simon Am 18.02.2019 um 09:45 schrieb Jose Abreu: > On 2/18/2019 8:42 AM, Jose Abreu wrote: >> On 2/17/2019 2:48 PM, Martin Blumenstingl wrote: >>> Jose, is my command for disabling offloading correct? >> Yes, I think so. What about NIC statistics and logs ? ("ethtool >> -S eth0", "dmesg | grep -i stmmac") > And, "ifconfig eth0" after running the test. > >> Thanks, >> Jose Miguel Abreu >> ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 12:33 ` Simon Huelck @ 2019-02-18 12:41 ` Jose Abreu 2019-02-18 13:02 ` Jose Abreu 0 siblings, 1 reply; 48+ messages in thread From: Jose Abreu @ 2019-02-18 12:41 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev On 2/18/2019 12:33 PM, Simon Huelck wrote: > Hi, > > > i recognize the followin on my ethernet stats: > > threshold: 1 > tx_pkt_n: 1457325 > rx_pkt_n: 5022405 > normal_irq_n: 671738 > rx_normal_irq_n: 606573 > napi_poll: 784439 > tx_normal_irq_n: 61061 > tx_clean: 784439 > tx_set_ic_bit: 58293 > irq_receive_pmt_irq_n: 0 > mmc_tx_irq_n: 0 > mmc_rx_irq_n: 0 > mmc_rx_csum_offload_irq_n: 0 > -> irq_tx_path_in_lpi_mode_n: 382037 > -> irq_tx_path_exit_lpi_mode_n: 382021 > > > Is this normal ? Did you try disabling EEE ? ("ethtool --set-eee eth0 eee off") Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 12:41 ` Jose Abreu @ 2019-02-18 13:02 ` Jose Abreu 2019-02-18 15:29 ` Simon Huelck 0 siblings, 1 reply; 48+ messages in thread From: Jose Abreu @ 2019-02-18 13:02 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev On 2/18/2019 12:41 PM, Jose Abreu wrote: > On 2/18/2019 12:33 PM, Simon Huelck wrote: >> Hi, >> >> >> i recognize the followin on my ethernet stats: >> >> threshold: 1 >> tx_pkt_n: 1457325 >> rx_pkt_n: 5022405 >> normal_irq_n: 671738 >> rx_normal_irq_n: 606573 >> napi_poll: 784439 >> tx_normal_irq_n: 61061 >> tx_clean: 784439 >> tx_set_ic_bit: 58293 >> irq_receive_pmt_irq_n: 0 >> mmc_tx_irq_n: 0 >> mmc_rx_irq_n: 0 >> mmc_rx_csum_offload_irq_n: 0 >> -> irq_tx_path_in_lpi_mode_n: 382037 >> -> irq_tx_path_exit_lpi_mode_n: 382021 >> >> >> Is this normal ? > > Did you try disabling EEE ? ("ethtool --set-eee eth0 eee off") BTW, do not try to re-enable it. There is a race in the enable function. I will send a fix ASAP. > > Thanks, > Jose Miguel Abreu > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 13:02 ` Jose Abreu @ 2019-02-18 15:29 ` Simon Huelck 2019-02-18 15:31 ` Jose Abreu 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-18 15:29 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi, i tried your command and tested afterwards, no change in behaviour . Can i reset the ethtool statistics for better overview ? regards, Simon Am 18.02.2019 um 14:02 schrieb Jose Abreu: > On 2/18/2019 12:41 PM, Jose Abreu wrote: >> On 2/18/2019 12:33 PM, Simon Huelck wrote: >>> Hi, >>> >>> >>> i recognize the followin on my ethernet stats: >>> >>> threshold: 1 >>> tx_pkt_n: 1457325 >>> rx_pkt_n: 5022405 >>> normal_irq_n: 671738 >>> rx_normal_irq_n: 606573 >>> napi_poll: 784439 >>> tx_normal_irq_n: 61061 >>> tx_clean: 784439 >>> tx_set_ic_bit: 58293 >>> irq_receive_pmt_irq_n: 0 >>> mmc_tx_irq_n: 0 >>> mmc_rx_irq_n: 0 >>> mmc_rx_csum_offload_irq_n: 0 >>> -> irq_tx_path_in_lpi_mode_n: 382037 >>> -> irq_tx_path_exit_lpi_mode_n: 382021 >>> >>> >>> Is this normal ? >> Did you try disabling EEE ? ("ethtool --set-eee eth0 eee off") > BTW, do not try to re-enable it. There is a race in the enable > function. I will send a fix ASAP. > >> Thanks, >> Jose Miguel Abreu >> ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 15:29 ` Simon Huelck @ 2019-02-18 15:31 ` Jose Abreu 2019-02-18 15:53 ` Simon Huelck 0 siblings, 1 reply; 48+ messages in thread From: Jose Abreu @ 2019-02-18 15:31 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev On 2/18/2019 3:29 PM, Simon Huelck wrote: > Can i reset the ethtool statistics for better overview ? Yes please. And do send the remaining logs + DT bindings. Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 15:31 ` Jose Abreu @ 2019-02-18 15:53 ` Simon Huelck 2019-02-18 16:26 ` Jose Abreu 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-18 15:53 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev [-- Attachment #1: Type: text/plain, Size: 350 bytes --] How can i do this (reset stats) ? The .dtb .dts is meson-gxbb-odroid-c2 from mainline kernel 5.0.rc7 Am 18.02.2019 um 16:31 schrieb Jose Abreu: > On 2/18/2019 3:29 PM, Simon Huelck wrote: >> Can i reset the ethtool statistics for better overview ? > Yes please. And do send the remaining logs + DT bindings. > > Thanks, > Jose Miguel Abreu [-- Attachment #2: ethtool.txt --] [-- Type: text/plain, Size: 5439 bytes --] NIC statistics: mmc_tx_octetcount_gb: 0 mmc_tx_framecount_gb: 0 mmc_tx_broadcastframe_g: 0 mmc_tx_multicastframe_g: 0 mmc_tx_64_octets_gb: 0 mmc_tx_65_to_127_octets_gb: 0 mmc_tx_128_to_255_octets_gb: 0 mmc_tx_256_to_511_octets_gb: 0 mmc_tx_512_to_1023_octets_gb: 0 mmc_tx_1024_to_max_octets_gb: 0 mmc_tx_unicast_gb: 0 mmc_tx_multicast_gb: 0 mmc_tx_broadcast_gb: 0 mmc_tx_underflow_error: 0 mmc_tx_singlecol_g: 0 mmc_tx_multicol_g: 0 mmc_tx_deferred: 0 mmc_tx_latecol: 0 mmc_tx_exesscol: 0 mmc_tx_carrier_error: 0 mmc_tx_octetcount_g: 0 mmc_tx_framecount_g: 0 mmc_tx_excessdef: 0 mmc_tx_pause_frame: 0 mmc_tx_vlan_frame_g: 0 mmc_rx_framecount_gb: 9651493 mmc_rx_octetcount_gb: 1567068041 mmc_rx_octetcount_g: 1567068041 mmc_rx_broadcastframe_g: 928080 mmc_rx_multicastframe_g: 2102 mmc_rx_crc_error: 0 mmc_rx_align_error: 0 mmc_rx_run_error: 0 mmc_rx_jabber_error: 0 mmc_rx_undersize_g: 0 mmc_rx_oversize_g: 0 mmc_rx_64_octets_gb: 0 mmc_rx_65_to_127_octets_gb: 2053537 mmc_rx_128_to_255_octets_gb: 393851 mmc_rx_256_to_511_octets_gb: 232137 mmc_rx_512_to_1023_octets_gb: 319994 mmc_rx_1024_to_max_octets_gb: 6651974 mmc_rx_unicast_g: 8721311 mmc_rx_length_error: 0 mmc_rx_autofrangetype: 0 mmc_rx_pause_frames: 0 mmc_rx_fifo_overflow: 6336 mmc_rx_vlan_frames_gb: 9650884 mmc_rx_watchdog_error: 0 mmc_rx_ipc_intr_mask: 4294770684 mmc_rx_ipc_intr: 0 mmc_rx_ipv4_gd: 8728187 mmc_rx_ipv4_hderr: 0 mmc_rx_ipv4_nopay: 30 mmc_rx_ipv4_frag: 2654 mmc_rx_ipv4_udsbl: 471 mmc_rx_ipv4_gd_octets: 1306820178 mmc_rx_ipv4_hderr_octets: 0 mmc_rx_ipv4_nopay_octets: 1394 mmc_rx_ipv4_frag_octets: 1890414 mmc_rx_ipv4_udsbl_octets: 177279 mmc_rx_ipv6_gd_octets: 223594 mmc_rx_ipv6_hderr_octets: 0 mmc_rx_ipv6_nopay_octets: 0 mmc_rx_ipv6_gd: 708 mmc_rx_ipv6_hderr: 0 mmc_rx_ipv6_nopay: 0 mmc_rx_udp_gd: 1904334 mmc_rx_udp_err: 4 mmc_rx_tcp_gd: 6821336 mmc_rx_tcp_err: 30 mmc_rx_icmp_gd: 2755 mmc_rx_icmp_err: 0 mmc_rx_udp_gd_octets: 1519481289 mmc_rx_udp_err_octets: 1089 mmc_rx_tcp_gd_octets: 3907148290 mmc_rx_tcp_err_octets: 1212 mmc_rx_icmp_gd_octets: 611804 mmc_rx_icmp_err_octets: 0 tx_underflow: 0 tx_carrier: 0 tx_losscarrier: 0 vlan_tag: 9644514 tx_deferred: 0 tx_vlan: 5470028 tx_jabber: 0 tx_frame_flushed: 0 tx_payload_error: 0 tx_ip_header_error: 0 rx_desc: 0 sa_filter_fail: 0 overflow_error: 0 ipc_csum_error: 0 rx_collision: 0 rx_crc_errors: 0 dribbling_bit: 0 rx_length: 0 rx_mii: 0 rx_multicast: 0 rx_gmac_overflow: 0 rx_watchdog: 0 da_rx_filter_fail: 0 sa_rx_filter_fail: 0 rx_missed_cntr: 0 rx_overflow_cntr: 0 rx_vlan: 0 tx_undeflow_irq: 0 tx_process_stopped_irq: 0 tx_jabber_irq: 0 rx_overflow_irq: 0 rx_buf_unav_irq: 0 rx_process_stopped_irq: 0 rx_watchdog_irq: 0 tx_early_irq: 0 fatal_bus_error_irq: 0 rx_early_irq: 69906 threshold: 1 tx_pkt_n: 5470028 rx_pkt_n: 9645123 normal_irq_n: 4005760 rx_normal_irq_n: 3772995 napi_poll: 4879751 tx_normal_irq_n: 224986 tx_clean: 4879751 tx_set_ic_bit: 218801 irq_receive_pmt_irq_n: 0 mmc_tx_irq_n: 0 mmc_rx_irq_n: 0 mmc_rx_csum_offload_irq_n: 0 irq_tx_path_in_lpi_mode_n: 1737935 irq_tx_path_exit_lpi_mode_n: 1737885 irq_rx_path_in_lpi_mode_n: 1 irq_rx_path_exit_lpi_mode_n: 1 phy_eee_wakeup_error_n: 0 ip_hdr_err: 0 ip_payload_err: 0 ip_csum_bypassed: 0 ipv4_pkt_rcvd: 0 ipv6_pkt_rcvd: 0 no_ptp_rx_msg_type_ext: 0 ptp_rx_msg_type_sync: 0 ptp_rx_msg_type_follow_up: 0 ptp_rx_msg_type_delay_req: 0 ptp_rx_msg_type_delay_resp: 0 ptp_rx_msg_type_pdelay_req: 0 ptp_rx_msg_type_pdelay_resp: 0 ptp_rx_msg_type_pdelay_follow_up: 0 ptp_rx_msg_type_announce: 0 ptp_rx_msg_type_management: 0 ptp_rx_msg_pkt_reserved_type: 0 ptp_frame_type: 0 ptp_ver: 0 timestamp_dropped: 0 av_pkt_rcvd: 0 av_tagged_pkt_rcvd: 0 vlan_tag_priority_val: 0 l3_filter_match: 0 l4_filter_match: 0 l3_l4_filter_no_match: 0 irq_pcs_ane_n: 0 irq_pcs_link_n: 0 irq_rgmii_n: 0 mtl_tx_status_fifo_full: 0 mtl_tx_fifo_not_empty: 0 mmtl_fifo_ctrl: 0 mtl_tx_fifo_read_ctrl_write: 0 mtl_tx_fifo_read_ctrl_wait: 0 mtl_tx_fifo_read_ctrl_read: 0 mtl_tx_fifo_read_ctrl_idle: 0 mac_tx_in_pause: 0 mac_tx_frame_ctrl_xfer: 0 mac_tx_frame_ctrl_idle: 0 mac_tx_frame_ctrl_wait: 0 mac_tx_frame_ctrl_pause: 0 mac_gmii_tx_proto_engine: 0 mtl_rx_fifo_fill_level_full: 0 mtl_rx_fifo_fill_above_thresh: 0 mtl_rx_fifo_fill_below_thresh: 0 mtl_rx_fifo_fill_level_empty: 0 mtl_rx_fifo_read_ctrl_flush: 0 mtl_rx_fifo_read_ctrl_read_data: 0 mtl_rx_fifo_read_ctrl_status: 0 mtl_rx_fifo_read_ctrl_idle: 0 mtl_rx_fifo_ctrl_active: 0 mac_rx_frame_ctrl_fifo: 0 mac_gmii_rx_proto_engine: 0 tx_tso_frames: 0 tx_tso_nfrags: 0 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 15:53 ` Simon Huelck @ 2019-02-18 16:26 ` Jose Abreu 2019-02-18 16:40 ` Simon Huelck 0 siblings, 1 reply; 48+ messages in thread From: Jose Abreu @ 2019-02-18 16:26 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev On 2/18/2019 3:53 PM, Simon Huelck wrote: > How can i do this (reset stats) ? A simple ifdown / ifup should work. > The .dtb .dts is meson-gxbb-odroid-c2 from mainline kernel 5.0.rc7 So, according to your DT bindings you have broken EEE yet it's still enabled in stmmac as we see the LPI counters increase. Try adding a simple "return false;" in the beginning of stmmac_eee_init() function and check if it works. BTW, you still haven't sent any dmesg logs, which can be handy and you also shouldn't top post. Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 16:26 ` Jose Abreu @ 2019-02-18 16:40 ` Simon Huelck 2019-02-18 16:43 ` Jose Abreu 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-18 16:40 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi, EEE is enabled for odroid - c2 and should be working in 5.0-rc7 afaik ? there was a recent patch for this which was added to mainline regards, Simon Am 18.02.2019 um 17:26 schrieb Jose Abreu: > On 2/18/2019 3:53 PM, Simon Huelck wrote: >> How can i do this (reset stats) ? > A simple ifdown / ifup should work. > >> The .dtb .dts is meson-gxbb-odroid-c2 from mainline kernel 5.0.rc7 > So, according to your DT bindings you have broken EEE yet it's > still enabled in stmmac as we see the LPI counters increase. > > Try adding a simple "return false;" in the beginning of > stmmac_eee_init() function and check if it works. > > BTW, you still haven't sent any dmesg logs, which can be handy > and you also shouldn't top post. > > Thanks, > Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 16:40 ` Simon Huelck @ 2019-02-18 16:43 ` Jose Abreu 2019-02-18 16:51 ` Simon Huelck 2019-02-18 17:05 ` Simon Huelck 0 siblings, 2 replies; 48+ messages in thread From: Jose Abreu @ 2019-02-18 16:43 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev On 2/18/2019 4:40 PM, Simon Huelck wrote: > Hi, > > EEE is enabled for odroid - c2 and should be working in 5.0-rc7 afaik ? Oops, I was seeing in the wrong version, sorry. And did you test without that patch ? Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 16:43 ` Jose Abreu @ 2019-02-18 16:51 ` Simon Huelck 2019-02-18 17:05 ` Jose Abreu 2019-02-18 17:05 ` Simon Huelck 1 sibling, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-18 16:51 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev [-- Attachment #1: Type: text/plain, Size: 724 bytes --] Hi, no im testing vanilla mainline kernel and against 4.14. where performance was ok. but turning off EEE via ethtool should have same results than removal of that patch. But, since it was mainlined recently , not long ago, i think this was tested ?? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=a152c91889556df17ca6d8ea134fb2cb4ac9f893 attached is my kern.log regards, Simon Am 18.02.2019 um 17:43 schrieb Jose Abreu: > On 2/18/2019 4:40 PM, Simon Huelck wrote: >> Hi, >> >> EEE is enabled for odroid - c2 and should be working in 5.0-rc7 afaik ? > Oops, I was seeing in the wrong version, sorry. > > And did you test without that patch ? > > Thanks, > Jose Miguel Abreu [-- Attachment #2: kern.log --] [-- Type: text/plain, Size: 46464 bytes --] Feb 18 11:46:51 localhost kernel: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] Feb 18 11:46:51 localhost kernel: [ 0.000000] Linux version 5.0.0-rc7+ (root@odroidc2) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Mon Feb 18 08:12:57 CET 2019 Feb 18 11:46:51 localhost kernel: [ 0.000000] Machine model: Hardkernel ODROID-C2 Feb 18 11:46:51 localhost kernel: [ 0.000000] Reserved memory: created CMA memory pool at 0x0000000068000000, size 256 MiB Feb 18 11:46:51 localhost kernel: [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool Feb 18 11:46:51 localhost kernel: [ 0.000000] On node 0 totalpages: 486144 Feb 18 11:46:51 localhost kernel: [ 0.000000] DMA32 zone: 7616 pages used for memmap Feb 18 11:46:51 localhost kernel: [ 0.000000] DMA32 zone: 0 pages reserved Feb 18 11:46:51 localhost kernel: [ 0.000000] DMA32 zone: 486144 pages, LIFO batch:63 Feb 18 11:46:51 localhost kernel: [ 0.000000] psci: probing for conduit method from DT. Feb 18 11:46:51 localhost kernel: [ 0.000000] psci: PSCIv0.2 detected in firmware. Feb 18 11:46:51 localhost kernel: [ 0.000000] psci: Using standard PSCI v0.2 function IDs Feb 18 11:46:51 localhost kernel: [ 0.000000] psci: Trusted OS migration not required Feb 18 11:46:51 localhost kernel: [ 0.000000] random: get_random_bytes called from start_kernel+0xa4/0x448 with crng_init=0 Feb 18 11:46:51 localhost kernel: [ 0.000000] percpu: Embedded 23 pages/cpu @(____ptrval____) s53528 r8192 d32488 u94208 Feb 18 11:46:51 localhost kernel: [ 0.000000] pcpu-alloc: s53528 r8192 d32488 u94208 alloc=23*4096 Feb 18 11:46:51 localhost kernel: [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Feb 18 11:46:51 localhost kernel: [ 0.000000] Detected VIPT I-cache on CPU0 Feb 18 11:46:51 localhost kernel: [ 0.000000] CPU features: detected: ARM erratum 843419 Feb 18 11:46:51 localhost kernel: [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 478528 Feb 18 11:46:51 localhost kernel: [ 0.000000] Kernel command line: console=ttyAML0,115200 root=/dev/mmcblk1p2 rootwait rootflags=data=writeback rw slub_debug=P page_poison=1 slab_nomerge Feb 18 11:46:51 localhost kernel: [ 0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Feb 18 11:46:51 localhost kernel: [ 0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Feb 18 11:46:51 localhost kernel: [ 0.000000] Memory: 1626632K/1944576K available (9150K kernel code, 650K rwdata, 2288K rodata, 448K init, 1101K bss, 55800K reserved, 262144K cma-reserved) Feb 18 11:46:51 localhost kernel: [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Feb 18 11:46:51 localhost kernel: [ 0.000000] rcu: Hierarchical RCU implementation. Feb 18 11:46:51 localhost kernel: [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. Feb 18 11:46:51 localhost kernel: [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 Feb 18 11:46:51 localhost kernel: [ 0.000000] GIC: Using split EOI/Deactivate mode Feb 18 11:46:51 localhost kernel: [ 0.000000] irq_meson_gpio: 133 to 8 gpio interrupt mux initialized Feb 18 11:46:51 localhost kernel: [ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys). Feb 18 11:46:51 localhost kernel: [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns Feb 18 11:46:51 localhost kernel: [ 0.000002] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns Feb 18 11:46:51 localhost kernel: [ 0.000234] Console: colour dummy device 80x25 Feb 18 11:46:51 localhost kernel: [ 0.000263] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000) Feb 18 11:46:51 localhost kernel: [ 0.000269] pid_max: default: 32768 minimum: 301 Feb 18 11:46:51 localhost kernel: [ 0.000396] LSM: Security Framework initializing Feb 18 11:46:51 localhost kernel: [ 0.000524] AppArmor: AppArmor initialized Feb 18 11:46:51 localhost kernel: [ 0.000578] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) Feb 18 11:46:51 localhost kernel: [ 0.000584] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes) Feb 18 11:46:51 localhost kernel: [ 0.001754] ASID allocator initialised with 65536 entries Feb 18 11:46:51 localhost kernel: [ 0.001813] rcu: Hierarchical SRCU implementation. Feb 18 11:46:51 localhost kernel: [ 0.002276] smp: Bringing up secondary CPUs ... Feb 18 11:46:51 localhost kernel: [ 0.003175] Detected VIPT I-cache on CPU1 Feb 18 11:46:51 localhost kernel: [ 0.003218] CPU1: Booted secondary processor 0x0000000001 [0x410fd034] Feb 18 11:46:51 localhost kernel: [ 0.004126] Detected VIPT I-cache on CPU2 Feb 18 11:46:51 localhost kernel: [ 0.004146] CPU2: Booted secondary processor 0x0000000002 [0x410fd034] Feb 18 11:46:51 localhost kernel: [ 0.005043] Detected VIPT I-cache on CPU3 Feb 18 11:46:51 localhost kernel: [ 0.005060] CPU3: Booted secondary processor 0x0000000003 [0x410fd034] Feb 18 11:46:51 localhost kernel: [ 0.005101] smp: Brought up 1 node, 4 CPUs Feb 18 11:46:51 localhost kernel: [ 0.005111] SMP: Total of 4 processors activated. Feb 18 11:46:51 localhost kernel: [ 0.005116] CPU features: detected: 32-bit EL0 Support Feb 18 11:46:51 localhost kernel: [ 0.005120] CPU features: detected: CRC32 instructions Feb 18 11:46:51 localhost kernel: [ 0.005243] CPU: All CPU(s) started at EL2 Feb 18 11:46:51 localhost kernel: [ 0.005256] alternatives: patching kernel code Feb 18 11:46:51 localhost kernel: [ 0.006007] devtmpfs: initialized Feb 18 11:46:51 localhost kernel: [ 0.011312] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns Feb 18 11:46:51 localhost kernel: [ 0.011331] futex hash table entries: 1024 (order: 4, 65536 bytes) Feb 18 11:46:51 localhost kernel: [ 0.089849] xor: measuring software checksum speed Feb 18 11:46:51 localhost kernel: [ 0.128135] 8regs : 2947.000 MB/sec Feb 18 11:46:51 localhost kernel: [ 0.168158] 32regs : 3491.000 MB/sec Feb 18 11:46:51 localhost kernel: [ 0.208182] arm64_neon: 3199.000 MB/sec Feb 18 11:46:51 localhost kernel: [ 0.208185] xor: using function: 32regs (3491.000 MB/sec) Feb 18 11:46:51 localhost kernel: [ 0.208198] pinctrl core: initialized pinctrl subsystem Feb 18 11:46:51 localhost kernel: [ 0.209125] NET: Registered protocol family 16 Feb 18 11:46:51 localhost kernel: [ 0.209433] audit: initializing netlink subsys (disabled) Feb 18 11:46:51 localhost kernel: [ 0.209584] audit: type=2000 audit(0.208:1): state=initialized audit_enabled=0 res=1 Feb 18 11:46:51 localhost kernel: [ 0.210114] vdso: 2 pages (1 code @ (____ptrval____), 1 data @ (____ptrval____)) Feb 18 11:46:51 localhost kernel: [ 0.210120] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. Feb 18 11:46:51 localhost kernel: [ 0.212724] DMA: preallocated 256 KiB pool for atomic allocations Feb 18 11:46:51 localhost kernel: [ 0.212765] Serial: AMBA PL011 UART driver Feb 18 11:46:51 localhost kernel: [ 0.221791] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages Feb 18 11:46:51 localhost kernel: [ 0.221800] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages Feb 18 11:46:51 localhost kernel: [ 0.221804] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages Feb 18 11:46:51 localhost kernel: [ 0.221808] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages Feb 18 11:46:51 localhost kernel: [ 0.288280] raid6: neonx8 gen() 2048 MB/s Feb 18 11:46:51 localhost kernel: [ 0.356338] raid6: neonx8 xor() 1940 MB/s Feb 18 11:46:51 localhost kernel: [ 0.424401] raid6: neonx4 gen() 1942 MB/s Feb 18 11:46:51 localhost kernel: [ 0.492441] raid6: neonx4 xor() 1862 MB/s Feb 18 11:46:51 localhost kernel: [ 0.560515] raid6: neonx2 gen() 1496 MB/s Feb 18 11:46:51 localhost kernel: [ 0.628532] raid6: neonx2 xor() 1559 MB/s Feb 18 11:46:51 localhost kernel: [ 0.696638] raid6: neonx1 gen() 934 MB/s Feb 18 11:46:51 localhost kernel: [ 0.764632] raid6: neonx1 xor() 1103 MB/s Feb 18 11:46:51 localhost kernel: [ 0.832724] raid6: int64x8 gen() 1414 MB/s Feb 18 11:46:51 localhost kernel: [ 0.900746] raid6: int64x8 xor() 937 MB/s Feb 18 11:46:51 localhost kernel: [ 0.968806] raid6: int64x4 gen() 1268 MB/s Feb 18 11:46:51 localhost kernel: [ 1.036858] raid6: int64x4 xor() 976 MB/s Feb 18 11:46:51 localhost kernel: [ 1.104923] raid6: int64x2 gen() 844 MB/s Feb 18 11:46:51 localhost kernel: [ 1.172978] raid6: int64x2 xor() 769 MB/s Feb 18 11:46:51 localhost kernel: [ 1.241028] raid6: int64x1 gen() 531 MB/s Feb 18 11:46:51 localhost kernel: [ 1.309057] raid6: int64x1 xor() 575 MB/s Feb 18 11:46:51 localhost kernel: [ 1.309060] raid6: using algorithm neonx8 gen() 2048 MB/s Feb 18 11:46:51 localhost kernel: [ 1.309063] raid6: .... xor() 1940 MB/s, rmw enabled Feb 18 11:46:51 localhost kernel: [ 1.309066] raid6: using neon recovery algorithm Feb 18 11:46:51 localhost kernel: [ 1.310471] SCSI subsystem initialized Feb 18 11:46:51 localhost kernel: [ 1.310655] libata version 3.00 loaded. Feb 18 11:46:51 localhost kernel: [ 1.310803] usbcore: registered new interface driver usbfs Feb 18 11:46:51 localhost kernel: [ 1.310834] usbcore: registered new interface driver hub Feb 18 11:46:51 localhost kernel: [ 1.310874] usbcore: registered new device driver usb Feb 18 11:46:51 localhost kernel: [ 1.310960] pps_core: LinuxPPS API ver. 1 registered Feb 18 11:46:51 localhost kernel: [ 1.310964] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> Feb 18 11:46:51 localhost kernel: [ 1.310980] PTP clock support registered Feb 18 11:46:51 localhost kernel: [ 1.311350] Advanced Linux Sound Architecture Driver Initialized. Feb 18 11:46:51 localhost kernel: [ 1.311729] NetLabel: Initializing Feb 18 11:46:51 localhost kernel: [ 1.311733] NetLabel: domain hash size = 128 Feb 18 11:46:51 localhost kernel: [ 1.311735] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO Feb 18 11:46:51 localhost kernel: [ 1.311807] NetLabel: unlabeled traffic allowed by default Feb 18 11:46:51 localhost kernel: [ 1.312093] clocksource: Switched to clocksource arch_sys_counter Feb 18 11:46:51 localhost kernel: [ 1.312218] VFS: Disk quotas dquot_6.6.0 Feb 18 11:46:51 localhost kernel: [ 1.312266] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) Feb 18 11:46:51 localhost kernel: [ 1.312352] FS-Cache: Loaded Feb 18 11:46:51 localhost kernel: [ 1.312559] CacheFiles: Loaded Feb 18 11:46:51 localhost kernel: [ 1.312878] AppArmor: AppArmor Filesystem Enabled Feb 18 11:46:51 localhost kernel: [ 1.317898] NET: Registered protocol family 2 Feb 18 11:46:51 localhost kernel: [ 1.318383] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes) Feb 18 11:46:51 localhost kernel: [ 1.318412] TCP established hash table entries: 16384 (order: 5, 131072 bytes) Feb 18 11:46:51 localhost kernel: [ 1.318498] TCP bind hash table entries: 16384 (order: 6, 262144 bytes) Feb 18 11:46:51 localhost kernel: [ 1.318667] TCP: Hash tables configured (established 16384 bind 16384) Feb 18 11:46:51 localhost kernel: [ 1.318750] UDP hash table entries: 1024 (order: 3, 32768 bytes) Feb 18 11:46:51 localhost kernel: [ 1.318787] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) Feb 18 11:46:51 localhost kernel: [ 1.318959] NET: Registered protocol family 1 Feb 18 11:46:51 localhost kernel: [ 1.319677] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available Feb 18 11:46:51 localhost kernel: [ 1.319894] kvm [1]: 8-bit VMID Feb 18 11:46:51 localhost kernel: [ 1.319898] kvm [1]: IPA Size Limit: 40bits Feb 18 11:46:51 localhost kernel: [ 1.320202] kvm [1]: vgic interrupt IRQ1 Feb 18 11:46:51 localhost kernel: [ 1.320282] kvm [1]: Hyp mode initialized successfully Feb 18 11:46:51 localhost kernel: [ 1.321223] Initialise system trusted keyrings Feb 18 11:46:51 localhost kernel: [ 1.321384] workingset: timestamp_bits=46 max_order=19 bucket_order=0 Feb 18 11:46:51 localhost kernel: [ 1.334565] Key type asymmetric registered Feb 18 11:46:51 localhost kernel: [ 1.334575] Asymmetric key parser 'x509' registered Feb 18 11:46:51 localhost kernel: [ 1.334631] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) Feb 18 11:46:51 localhost kernel: [ 1.334739] io scheduler mq-deadline registered Feb 18 11:46:51 localhost kernel: [ 1.334743] io scheduler kyber registered Feb 18 11:46:51 localhost kernel: [ 1.335948] GPIO line 501 (usb-hub-reset) hogged as output/high Feb 18 11:46:51 localhost kernel: [ 1.344357] meson_vid_pll_div_recalc_rate: Invalid config value for vid_pll_div Feb 18 11:46:51 localhost kernel: [ 1.346340] soc soc0: Amlogic Meson GXBB (S905) Revision 1f:c (0:1) Detected Feb 18 11:46:51 localhost kernel: [ 1.347424] c81004c0.serial: ttyAML0 at MMIO 0xc81004c0 (irq = 13, base_baud = 1500000) is a meson_uart Feb 18 11:46:51 localhost kernel: [ 2.072919] printk: console [ttyAML0] enabled Feb 18 11:46:51 localhost kernel: [ 2.084602] loop: module loaded Feb 18 11:46:51 localhost kernel: [ 2.084960] zram: Added device: zram0 Feb 18 11:46:51 localhost kernel: [ 2.086244] mtdoops: mtd device (mtddev=name/number) must be supplied Feb 18 11:46:51 localhost kernel: [ 2.092460] libphy: Fixed MDIO Bus: probed Feb 18 11:46:51 localhost kernel: [ 2.096253] tun: Universal TUN/TAP device driver, 1.6 Feb 18 11:46:51 localhost kernel: [ 2.101949] meson8b-dwmac c9410000.ethernet: PTP uses main clock Feb 18 11:46:51 localhost kernel: [ 2.107147] meson8b-dwmac c9410000.ethernet: no reset control found Feb 18 11:46:51 localhost kernel: [ 2.113763] meson8b-dwmac c9410000.ethernet: User ID: 0x11, Synopsys ID: 0x37 Feb 18 11:46:51 localhost kernel: [ 2.120427] meson8b-dwmac c9410000.ethernet: DWMAC1000 Feb 18 11:46:51 localhost kernel: [ 2.125597] meson8b-dwmac c9410000.ethernet: DMA HW capability register supported Feb 18 11:46:51 localhost kernel: [ 2.133013] meson8b-dwmac c9410000.ethernet: RX Checksum Offload Engine supported Feb 18 11:46:51 localhost kernel: [ 2.140430] meson8b-dwmac c9410000.ethernet: COE Type 2 Feb 18 11:46:51 localhost kernel: [ 2.145605] meson8b-dwmac c9410000.ethernet: TX Checksum insertion supported Feb 18 11:46:51 localhost kernel: [ 2.152590] meson8b-dwmac c9410000.ethernet: Wake-Up On Lan supported Feb 18 11:46:51 localhost kernel: [ 2.159001] meson8b-dwmac c9410000.ethernet: Normal descriptors Feb 18 11:46:51 localhost kernel: [ 2.164840] meson8b-dwmac c9410000.ethernet: Ring mode enabled Feb 18 11:46:51 localhost kernel: [ 2.170617] meson8b-dwmac c9410000.ethernet: Enable RX Mitigation via HW Watchdog Timer Feb 18 11:46:51 localhost kernel: [ 3.232114] libphy: stmmac: probed Feb 18 11:46:51 localhost kernel: [ 3.233792] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver Feb 18 11:46:51 localhost kernel: [ 3.236364] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver Feb 18 11:46:51 localhost kernel: [ 3.242549] usbcore: registered new interface driver usb-storage Feb 18 11:46:51 localhost kernel: [ 3.248500] usbcore: registered new interface driver usbserial_generic Feb 18 11:46:51 localhost kernel: [ 3.254921] usbserial: USB Serial support registered for generic Feb 18 11:46:51 localhost kernel: [ 3.261073] mousedev: PS/2 mouse device common for all mice Feb 18 11:46:51 localhost kernel: [ 3.266541] i2c /dev entries driver Feb 18 11:46:51 localhost kernel: [ 3.270425] IR Sharp protocol handler initialized Feb 18 11:46:51 localhost kernel: [ 3.274485] IR XMP protocol handler initialized Feb 18 11:46:51 localhost kernel: [ 3.279110] Registered IR keymap rc-empty Feb 18 11:46:51 localhost kernel: [ 3.282980] rc rc0: meson-ir as /devices/platform/soc/c8100000.bus/c8100580.ir/rc/rc0 Feb 18 11:46:51 localhost kernel: [ 3.290940] input: meson-ir as /devices/platform/soc/c8100000.bus/c8100580.ir/rc/rc0/input0 Feb 18 11:46:51 localhost kernel: [ 3.299277] meson-ir c8100580.ir: receiver initialized Feb 18 11:46:51 localhost kernel: [ 3.304652] softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0) Feb 18 11:46:51 localhost kernel: [ 3.313334] meson-gx-mmc d0074000.mmc: Linked as a consumer to regulator.2 Feb 18 11:46:51 localhost kernel: [ 3.319326] meson-gx-mmc d0074000.mmc: Linked as a consumer to regulator.1 Feb 18 11:46:51 localhost kernel: [ 3.326101] meson-gx-mmc d0074000.mmc: allocated mmc-pwrseq Feb 18 11:46:51 localhost kernel: [ 3.359935] ledtrig-cpu: registered to indicate activity on CPUs Feb 18 11:46:51 localhost kernel: [ 3.360577] meson-sm: secure-monitor enabled Feb 18 11:46:51 localhost kernel: [ 3.364943] usbcore: registered new interface driver usbhid Feb 18 11:46:51 localhost kernel: [ 3.370121] usbhid: USB HID core driver Feb 18 11:46:51 localhost kernel: [ 3.374139] meson-saradc c1108680.adc: Linked as a consumer to regulator.1 Feb 18 11:46:51 localhost kernel: [ 3.382165] GACT probability on Feb 18 11:46:51 localhost kernel: [ 3.383808] Mirror/redirect action on Feb 18 11:46:51 localhost kernel: [ 3.387470] u32 classifier Feb 18 11:46:51 localhost kernel: [ 3.390060] Performance counters on Feb 18 11:46:51 localhost kernel: [ 3.393848] input device check on Feb 18 11:46:51 localhost kernel: [ 3.397471] Actions configured Feb 18 11:46:51 localhost kernel: [ 3.401436] NET: Registered protocol family 10 Feb 18 11:46:51 localhost kernel: [ 3.406348] Segment Routing with IPv6 Feb 18 11:46:51 localhost kernel: [ 3.409084] mip6: Mobile IPv6 Feb 18 11:46:51 localhost kernel: [ 3.411784] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver Feb 18 11:46:51 localhost kernel: [ 3.418417] NET: Registered protocol family 17 Feb 18 11:46:51 localhost kernel: [ 3.422075] NET: Registered protocol family 15 Feb 18 11:46:51 localhost kernel: [ 3.426552] Bridge firewalling registered Feb 18 11:46:51 localhost kernel: [ 3.430445] NET: Registered protocol family 35 Feb 18 11:46:51 localhost kernel: [ 3.434965] 8021q: 802.1Q VLAN Support v1.8 Feb 18 11:46:51 localhost kernel: [ 3.438999] Key type dns_resolver registered Feb 18 11:46:51 localhost kernel: [ 3.443787] registered taskstats version 1 Feb 18 11:46:51 localhost kernel: [ 3.447241] Loading compiled-in X.509 certificates Feb 18 11:46:51 localhost kernel: [ 3.453393] Btrfs loaded, crc32c=crc32c-generic Feb 18 11:46:51 localhost kernel: [ 3.456524] AppArmor: AppArmor sha1 policy hashing enabled Feb 18 11:46:51 localhost kernel: [ 3.471968] phy phy-c0000000.phy.0: Linked as a consumer to regulator.3 Feb 18 11:46:51 localhost kernel: [ 3.473181] phy phy-c0000020.phy.1: Linked as a consumer to regulator.3 Feb 18 11:46:51 localhost kernel: [ 3.479822] meson-drm d0100000.vpu: Queued 2 outputs on vpu Feb 18 11:46:51 localhost kernel: [ 3.485215] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Feb 18 11:46:51 localhost kernel: [ 3.491563] [drm] No driver support for vblank timestamp query. Feb 18 11:46:51 localhost kernel: [ 3.497510] meson-drm d0100000.vpu: CVBS Output connector not available Feb 18 11:46:51 localhost kernel: [ 3.532126] meson-dw-hdmi c883a000.hdmi-tx: Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy) Feb 18 11:46:51 localhost kernel: [ 3.536599] meson-dw-hdmi c883a000.hdmi-tx: registered DesignWare HDMI I2C bus driver Feb 18 11:46:51 localhost kernel: [ 3.544281] meson-drm d0100000.vpu: bound c883a000.hdmi-tx (ops 0xffffff8010a01668) Feb 18 11:46:51 localhost kernel: [ 3.551960] [drm] Initialized meson 1.0.0 20161109 for d0100000.vpu on minor 0 Feb 18 11:46:51 localhost kernel: [ 3.558842] [drm] Cannot find any crtc or sizes Feb 18 11:46:51 localhost kernel: [ 3.563528] dwc2 c9000000.usb: c9000000.usb supply vusb_d not found, using dummy regulator Feb 18 11:46:51 localhost kernel: [ 3.571511] dwc2 c9000000.usb: Linked as a consumer to regulator.0 Feb 18 11:46:51 localhost kernel: [ 3.577601] dwc2 c9000000.usb: c9000000.usb supply vusb_a not found, using dummy regulator Feb 18 11:46:51 localhost kernel: [ 3.585911] [drm] Cannot find any crtc or sizes Feb 18 11:46:51 localhost kernel: [ 3.591361] phy phy-c0000000.phy.0: USB ID detect failed! Feb 18 11:46:51 localhost kernel: [ 3.595627] phy phy-c0000000.phy.0: phy poweron failed --> -22 Feb 18 11:46:51 localhost kernel: [ 3.601446] WARNING: CPU: 1 PID: 31 at _regulator_put.part.12+0x118/0x120 Feb 18 11:46:51 localhost kernel: [ 3.608124] Modules linked in: Feb 18 11:46:51 localhost kernel: [ 3.611146] CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 5.0.0-rc7+ #1 Feb 18 11:46:51 localhost kernel: [ 3.617611] Hardware name: Hardkernel ODROID-C2 (DT) Feb 18 11:46:51 localhost kernel: [ 3.622535] Workqueue: events deferred_probe_work_func Feb 18 11:46:51 localhost kernel: [ 3.627617] pstate: 80000005 (Nzcv daif -PAN -UAO) Feb 18 11:46:51 localhost kernel: [ 3.632361] pc : _regulator_put.part.12+0x118/0x120 Feb 18 11:46:51 localhost kernel: [ 3.637190] lr : regulator_put+0x34/0x50 Feb 18 11:46:51 localhost kernel: [ 3.641071] sp : ffffff8010ea3a90 Feb 18 11:46:51 localhost kernel: [ 3.644348] x29: ffffff8010ea3a90 x28: ffffffc064ce77a8 Feb 18 11:46:51 localhost kernel: [ 3.649609] x27: ffffffc064ce77a8 x26: ffffff80105c6248 Feb 18 11:46:51 localhost kernel: [ 3.654871] x25: ffffff80105c6250 x24: 0000000000000009 Feb 18 11:46:51 localhost kernel: [ 3.660132] x23: ffffffc064ce7510 x22: ffffff8010ea3b88 Feb 18 11:46:51 localhost kernel: [ 3.665393] x21: 0000000000000000 x20: ffffffc064b40600 Feb 18 11:46:51 localhost kernel: [ 3.670654] x19: ffffffc064b40600 x18: ffffffffffffffff Feb 18 11:46:51 localhost kernel: [ 3.675915] x17: 000000001d2524e2 x16: 000000005fbbb809 Feb 18 11:46:51 localhost kernel: [ 3.681177] x15: ffffff8010c3c648 x14: ffffff8090ea3787 Feb 18 11:46:51 localhost kernel: [ 3.686438] x13: ff00000000000000 x12: ffffffffffffffff Feb 18 11:46:51 localhost kernel: [ 3.691699] x11: 0000000000000038 x10: 0000000000000006 Feb 18 11:46:51 localhost kernel: [ 3.696960] x9 : 0000000000000040 x8 : ffffffc064b40b7f Feb 18 11:46:51 localhost kernel: [ 3.702222] x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000000 Feb 18 11:46:51 localhost kernel: [ 3.707483] x5 : 0000000000000000 x4 : 0000000000000000 Feb 18 11:46:51 localhost kernel: [ 3.712744] x3 : 0000000000000000 x2 : 0000000000000000 Feb 18 11:46:51 localhost kernel: [ 3.718005] x1 : ffffffc064c67000 x0 : 0000000000000001 Feb 18 11:46:51 localhost kernel: [ 3.723267] Call trace: Feb 18 11:46:51 localhost kernel: [ 3.725684] _regulator_put.part.12+0x118/0x120 Feb 18 11:46:51 localhost kernel: [ 3.730168] regulator_put+0x34/0x50 Feb 18 11:46:51 localhost kernel: [ 3.733705] regulator_bulk_free+0x34/0x50 Feb 18 11:46:51 localhost kernel: [ 3.737759] devm_regulator_bulk_release+0x18/0x20 Feb 18 11:46:51 localhost kernel: [ 3.742503] release_nodes+0x17c/0x2f8 Feb 18 11:46:51 localhost kernel: [ 3.746211] devres_release_all+0x58/0x88 Feb 18 11:46:51 localhost kernel: [ 3.750178] really_probe+0xc4/0x2c0 Feb 18 11:46:51 localhost kernel: [ 3.753714] driver_probe_device+0x58/0x100 Feb 18 11:46:51 localhost kernel: [ 3.757854] __device_attach_driver+0x9c/0xf8 Feb 18 11:46:51 localhost kernel: [ 3.762168] bus_for_each_drv+0x70/0xc8 Feb 18 11:46:51 localhost kernel: [ 3.765961] __device_attach+0xe0/0x140 Feb 18 11:46:51 localhost kernel: [ 3.769757] device_initial_probe+0x10/0x18 Feb 18 11:46:51 localhost kernel: [ 3.773896] bus_probe_device+0x94/0xa0 Feb 18 11:46:51 localhost kernel: [ 3.777692] deferred_probe_work_func+0x80/0xb8 Feb 18 11:46:51 localhost kernel: [ 3.782179] process_one_work+0x1b0/0x348 Feb 18 11:46:51 localhost kernel: [ 3.786144] worker_thread+0x224/0x448 Feb 18 11:46:51 localhost kernel: [ 3.789854] kthread+0xf8/0x128 Feb 18 11:46:51 localhost kernel: [ 3.792959] ret_from_fork+0x10/0x1c Feb 18 11:46:51 localhost kernel: [ 3.796494] ---[ end trace 24c7cc78b2f976b6 ]--- Feb 18 11:46:51 localhost kernel: [ 3.801132] WARNING: CPU: 1 PID: 31 at _regulator_put.part.12+0x118/0x120 Feb 18 11:46:51 localhost kernel: [ 3.807792] Modules linked in: Feb 18 11:46:51 localhost kernel: [ 3.810813] CPU: 1 PID: 31 Comm: kworker/1:1 Tainted: G W 5.0.0-rc7+ #1 Feb 18 11:46:51 localhost kernel: [ 3.818659] Hardware name: Hardkernel ODROID-C2 (DT) Feb 18 11:46:51 localhost kernel: [ 3.823578] Workqueue: events deferred_probe_work_func Feb 18 11:46:51 localhost kernel: [ 3.828665] pstate: 80000005 (Nzcv daif -PAN -UAO) Feb 18 11:46:51 localhost kernel: [ 3.833409] pc : _regulator_put.part.12+0x118/0x120 Feb 18 11:46:51 localhost kernel: [ 3.838239] lr : regulator_put+0x34/0x50 Feb 18 11:46:51 localhost kernel: [ 3.842119] sp : ffffff8010ea3a90 Feb 18 11:46:51 localhost kernel: [ 3.845397] x29: ffffff8010ea3a90 x28: ffffffc064ce77a8 Feb 18 11:46:51 localhost kernel: [ 3.850658] x27: ffffffc064ce77a8 x26: ffffff80105c6248 Feb 18 11:46:51 localhost kernel: [ 3.855919] x25: ffffff80105c6250 x24: 0000000000000009 Feb 18 11:46:51 localhost kernel: [ 3.861180] x23: ffffffc064ce7510 x22: ffffff8010ea3b88 Feb 18 11:46:51 localhost kernel: [ 3.866442] x21: 0000000000000000 x20: ffffffc064b40d80 Feb 18 11:46:51 localhost kernel: [ 3.871703] x19: ffffffc064b40d80 x18: 000000000000003a Feb 18 11:46:51 localhost kernel: [ 3.876964] x17: 000000001d2524e2 x16: 000000005fbbb809 Feb 18 11:46:51 localhost kernel: [ 3.882226] x15: ffffff8010c3c648 x14: ffffffc005335e10 Feb 18 11:46:51 localhost kernel: [ 3.887487] x13: ffffffc06510a1e8 x12: 0000000000000000 Feb 18 11:46:51 localhost kernel: [ 3.892748] x11: ffffffc065109ff0 x10: 0000000000000000 Feb 18 11:46:51 localhost kernel: [ 3.898009] x9 : 0000000000000040 x8 : ffffffc064b406ff Feb 18 11:46:51 localhost kernel: [ 3.903270] x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000000 Feb 18 11:46:51 localhost kernel: [ 3.908532] x5 : 0000000000000000 x4 : 0000000000000000 Feb 18 11:46:51 localhost kernel: [ 3.913793] x3 : 0000000000000000 x2 : 0000000000000000 Feb 18 11:46:51 localhost kernel: [ 3.919054] x1 : ffffffc064c67000 x0 : 0000000000000001 Feb 18 11:46:51 localhost kernel: [ 3.924315] Call trace: Feb 18 11:46:51 localhost kernel: [ 3.926732] _regulator_put.part.12+0x118/0x120 Feb 18 11:46:51 localhost kernel: [ 3.931217] regulator_put+0x34/0x50 Feb 18 11:46:51 localhost kernel: [ 3.934753] regulator_bulk_free+0x34/0x50 Feb 18 11:46:51 localhost kernel: [ 3.938807] devm_regulator_bulk_release+0x18/0x20 Feb 18 11:46:51 localhost kernel: [ 3.943551] release_nodes+0x17c/0x2f8 Feb 18 11:46:51 localhost kernel: [ 3.947260] devres_release_all+0x58/0x88 Feb 18 11:46:51 localhost kernel: [ 3.951226] really_probe+0xc4/0x2c0 Feb 18 11:46:51 localhost kernel: [ 3.954763] driver_probe_device+0x58/0x100 Feb 18 11:46:51 localhost kernel: [ 3.958903] __device_attach_driver+0x9c/0xf8 Feb 18 11:46:51 localhost kernel: [ 3.963216] bus_for_each_drv+0x70/0xc8 Feb 18 11:46:51 localhost kernel: [ 3.967010] __device_attach+0xe0/0x140 Feb 18 11:46:51 localhost kernel: [ 3.970805] device_initial_probe+0x10/0x18 Feb 18 11:46:51 localhost kernel: [ 3.974945] bus_probe_device+0x94/0xa0 Feb 18 11:46:51 localhost kernel: [ 3.978740] deferred_probe_work_func+0x80/0xb8 Feb 18 11:46:51 localhost kernel: [ 3.983226] process_one_work+0x1b0/0x348 Feb 18 11:46:51 localhost kernel: [ 3.987193] worker_thread+0x224/0x448 Feb 18 11:46:51 localhost kernel: [ 3.990901] kthread+0xf8/0x128 Feb 18 11:46:51 localhost kernel: [ 3.994007] ret_from_fork+0x10/0x1c Feb 18 11:46:51 localhost kernel: [ 3.997542] ---[ end trace 24c7cc78b2f976b7 ]--- Feb 18 11:46:51 localhost kernel: [ 4.002169] dwc2: probe of c9000000.usb failed with error -22 Feb 18 11:46:51 localhost kernel: [ 4.008026] dwc2 c9100000.usb: c9100000.usb supply vusb_d not found, using dummy regulator Feb 18 11:46:51 localhost kernel: [ 4.016047] dwc2 c9100000.usb: Linked as a consumer to regulator.0 Feb 18 11:46:51 localhost kernel: [ 4.022134] dwc2 c9100000.usb: c9100000.usb supply vusb_a not found, using dummy regulator Feb 18 11:46:51 localhost kernel: [ 4.088105] dwc2 c9100000.usb: dwc2_check_params: Invalid parameter lpm=1 Feb 18 11:46:51 localhost kernel: [ 4.089237] dwc2 c9100000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1 Feb 18 11:46:51 localhost kernel: [ 4.097093] dwc2 c9100000.usb: dwc2_check_params: Invalid parameter besl=1 Feb 18 11:46:51 localhost kernel: [ 4.103904] dwc2 c9100000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1 Feb 18 11:46:51 localhost kernel: [ 4.112771] dwc2 c9100000.usb: DWC OTG Controller Feb 18 11:46:51 localhost kernel: [ 4.116515] dwc2 c9100000.usb: new USB bus registered, assigned bus number 1 Feb 18 11:46:51 localhost kernel: [ 4.123501] dwc2 c9100000.usb: irq 34, io mem 0xc9100000 Feb 18 11:46:51 localhost kernel: [ 4.129298] hub 1-0:1.0: USB hub found Feb 18 11:46:51 localhost kernel: [ 4.132476] hub 1-0:1.0: 1 port detected Feb 18 11:46:51 localhost kernel: [ 4.137026] meson-gx-mmc d0072000.mmc: Linked as a consumer to regulator.4 Feb 18 11:46:51 localhost kernel: [ 4.143186] meson-gx-mmc d0072000.mmc: Linked as a consumer to regulator.5 Feb 18 11:46:51 localhost kernel: [ 4.150005] meson-gx-mmc d0072000.mmc: Got CD GPIO Feb 18 11:46:51 localhost kernel: [ 4.183006] hctosys: unable to open rtc device (rtc0) Feb 18 11:46:51 localhost kernel: [ 4.183222] VCC3V3: disabling Feb 18 11:46:51 localhost kernel: [ 4.185377] ALSA device list: Feb 18 11:46:51 localhost kernel: [ 4.188289] No soundcards found. Feb 18 11:46:51 localhost kernel: [ 4.197437] Waiting for root device /dev/mmcblk1p2... Feb 18 11:46:51 localhost kernel: [ 4.262003] mmc1: new high speed SDHC card at address 0007 Feb 18 11:46:51 localhost kernel: [ 4.263999] mmcblk1: mmc1:0007 SL16G 14.5 GiB Feb 18 11:46:51 localhost kernel: [ 4.267797] mmcblk1: p1 p2 Feb 18 11:46:51 localhost kernel: [ 4.277852] EXT4-fs (mmcblk1p2): Mount option "data=writeback" incompatible with ext2 Feb 18 11:46:51 localhost kernel: [ 4.334315] EXT4-fs (mmcblk1p2): mounted filesystem with writeback data mode. Opts: data=writeback Feb 18 11:46:51 localhost kernel: [ 4.337667] VFS: Mounted root (ext4 filesystem) on device 179:2. Feb 18 11:46:51 localhost kernel: [ 4.351271] devtmpfs: mounted Feb 18 11:46:51 localhost kernel: [ 4.351572] Freeing unused kernel memory: 448K Feb 18 11:46:51 localhost kernel: [ 4.365622] Checked W+X mappings: passed, no W+X pages found Feb 18 11:46:51 localhost kernel: [ 4.365654] Run /sbin/init as init process Feb 18 11:46:51 localhost kernel: [ 4.532108] usb 1-1: new high-speed USB device number 2 using dwc2 Feb 18 11:46:51 localhost kernel: [ 4.658829] random: fast init done Feb 18 11:46:51 localhost kernel: [ 4.746005] hub 1-1:1.0: USB hub found Feb 18 11:46:51 localhost kernel: [ 4.746306] hub 1-1:1.0: 4 ports detected Feb 18 11:46:51 localhost kernel: [ 5.036118] usb 1-1.1: new high-speed USB device number 3 using dwc2 Feb 18 11:46:51 localhost kernel: [ 5.039979] random: systemd: uninitialized urandom read (16 bytes read) Feb 18 11:46:51 localhost kernel: [ 5.058891] random: systemd: uninitialized urandom read (16 bytes read) Feb 18 11:46:51 localhost kernel: [ 5.059894] random: systemd: uninitialized urandom read (16 bytes read) Feb 18 11:46:51 localhost kernel: [ 5.216153] usb 1-1.2: new high-speed USB device number 4 using dwc2 Feb 18 11:46:51 localhost kernel: [ 5.801536] RPC: Registered named UNIX socket transport module. Feb 18 11:46:51 localhost kernel: [ 5.801807] RPC: Registered udp transport module. Feb 18 11:46:51 localhost kernel: [ 5.806494] RPC: Registered tcp transport module. Feb 18 11:46:51 localhost kernel: [ 5.811150] RPC: Registered tcp NFSv4.1 backchannel transport module. Feb 18 11:46:51 localhost kernel: [ 6.024862] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Feb 18 11:46:51 localhost kernel: [ 6.252942] EXT4-fs (mmcblk1p2): re-mounted. Opts: commit=600,errors=remount-ro Feb 18 11:46:51 localhost kernel: [ 6.418283] random: crng init done Feb 18 11:46:51 localhost kernel: [ 6.418307] random: 7 urandom warning(s) missed due to ratelimiting Feb 18 11:46:51 localhost kernel: [ 6.617477] synth uevent: /devices/platform/soc/c8100000.bus/c8100580.ir/rc/rc0/input0: failed to send uevent Feb 18 11:46:51 localhost kernel: [ 6.617485] input input0: uevent: failed to send synthetic uevent Feb 18 11:46:51 localhost kernel: [ 6.896620] cfg80211: Loading compiled-in X.509 certificates for regulatory database Feb 18 11:46:51 localhost kernel: [ 6.906516] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' Feb 18 11:46:51 localhost kernel: [ 6.951852] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 Feb 18 11:46:51 localhost kernel: [ 6.954831] cfg80211: failed to load regulatory.db Feb 18 11:46:51 localhost kernel: [ 7.192131] usb 1-1.2: reset high-speed USB device number 4 using dwc2 Feb 18 11:46:51 localhost kernel: [ 7.231399] 88XXau: loading out-of-tree module taints kernel. Feb 18 11:46:51 localhost kernel: [ 7.301805] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 2872, rev 0202 detected Feb 18 11:46:51 localhost kernel: [ 7.358349] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0001 detected Feb 18 11:46:51 localhost kernel: [ 7.360121] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Feb 18 11:46:51 localhost kernel: [ 7.361507] usbcore: registered new interface driver rt2800usb Feb 18 11:46:51 localhost kernel: [ 7.838102] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' Feb 18 11:46:51 localhost kernel: [ 7.851084] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 Feb 18 11:46:51 localhost kernel: [ 8.116152] usb 1-1.1: reset high-speed USB device number 3 using dwc2 Feb 18 11:46:51 localhost kernel: [ 8.208043] zram0: detected capacity change from 0 to 52428800 Feb 18 11:46:51 localhost kernel: [ 8.216588] usb 1-1.1: device firmware changed Feb 18 11:46:51 localhost kernel: [ 8.217146] usbcore: registered new interface driver rtl88xxau Feb 18 11:46:51 localhost kernel: [ 8.217797] usb 1-1.1: USB disconnect, device number 3 Feb 18 11:46:51 localhost kernel: [ 8.304167] usb 1-1.1: new high-speed USB device number 5 using dwc2 Feb 18 11:46:51 localhost kernel: [ 8.524535] new mount options do not match the existing superblock, will be ignored Feb 18 11:46:51 localhost kernel: [ 8.588572] fuse init (API version 7.28) Feb 18 11:46:51 localhost kernel: [ 8.769188] rtl88xxau 1-1.1:1.0 wlan2: renamed from wlan1 Feb 18 11:46:53 localhost kernel: [ 10.925761] Generic PHY stmmac-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=stmmac-0:00, irq=POLL) Feb 18 11:46:53 localhost kernel: [ 10.935282] meson8b-dwmac c9410000.ethernet eth0: No Safety Features support found Feb 18 11:46:53 localhost kernel: [ 10.937821] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW Feb 18 11:46:53 localhost kernel: [ 10.946511] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off Feb 18 11:46:53 localhost kernel: [ 10.953817] br-lan: port 1(eth0.3) entered blocking state Feb 18 11:46:53 localhost kernel: [ 10.958287] br-lan: port 1(eth0.3) entered disabled state Feb 18 11:46:53 localhost kernel: [ 10.963761] device eth0.3 entered promiscuous mode Feb 18 11:46:53 localhost kernel: [ 10.970798] device eth0 entered promiscuous mode Feb 18 11:46:53 localhost kernel: [ 10.976708] br-lan: port 1(eth0.3) entered blocking state Feb 18 11:46:53 localhost kernel: [ 10.978151] br-lan: port 1(eth0.3) entered forwarding state Feb 18 11:46:57 localhost kernel: [ 14.806275] br-dmz: port 1(eth0.2) entered blocking state Feb 18 11:46:57 localhost kernel: [ 14.806311] br-dmz: port 1(eth0.2) entered disabled state Feb 18 11:46:57 localhost kernel: [ 14.812050] device eth0.2 entered promiscuous mode Feb 18 11:46:57 localhost kernel: [ 14.823518] br-dmz: port 1(eth0.2) entered blocking state Feb 18 11:46:57 localhost kernel: [ 14.823556] br-dmz: port 1(eth0.2) entered forwarding state Feb 18 11:46:58 localhost kernel: [ 15.510373] br-iot: port 1(eth0.5) entered blocking state Feb 18 11:46:58 localhost kernel: [ 15.510412] br-iot: port 1(eth0.5) entered disabled state Feb 18 11:46:58 localhost kernel: [ 15.515949] device eth0.5 entered promiscuous mode Feb 18 11:46:58 localhost kernel: [ 15.527027] br-iot: port 1(eth0.5) entered blocking state Feb 18 11:46:58 localhost kernel: [ 15.527065] br-iot: port 1(eth0.5) entered forwarding state Feb 18 11:47:04 localhost kernel: [ 21.506842] input: lircd-uinput as /devices/virtual/input/input1 Feb 18 11:47:04 localhost kernel: [ 21.547599] CIFS: Attempting to mount //10.10.30.136/USBStick Feb 18 11:47:04 localhost kernel: [ 21.547782] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. Feb 18 11:47:04 localhost kernel: [ 21.548420] CIFS: Attempting to mount //10.10.30.136/Public Feb 18 11:47:04 localhost kernel: [ 21.548589] CIFS: Attempting to mount //10.10.30.136/Multimedia Feb 18 11:47:04 localhost kernel: [ 21.548645] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. Feb 18 11:47:04 localhost kernel: [ 21.604538] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. Feb 18 11:47:04 localhost kernel: [ 21.786540] cryptd: max_cpu_qlen set to 1000 Feb 18 11:47:04 localhost kernel: [ 21.999665] input: meson-ir (lircd bypass) as /devices/virtual/input/input2 Feb 18 11:47:05 localhost kernel: [ 22.094842] br-guest: port 1(wlan0) entered blocking state Feb 18 11:47:05 localhost kernel: [ 22.094885] br-guest: port 1(wlan0) entered disabled state Feb 18 11:47:05 localhost kernel: [ 22.100490] device wlan0 entered promiscuous mode Feb 18 11:47:05 localhost kernel: [ 22.360066] br-guest: port 1(wlan0) entered blocking state Feb 18 11:47:05 localhost kernel: [ 22.360123] br-guest: port 1(wlan0) entered forwarding state Feb 18 11:47:05 localhost kernel: [ 22.427280] br-lan: port 2(wlan0_1) entered blocking state Feb 18 11:47:05 localhost kernel: [ 22.427317] br-lan: port 2(wlan0_1) entered disabled state Feb 18 11:47:05 localhost kernel: [ 22.432906] device wlan0_1 entered promiscuous mode Feb 18 11:47:05 localhost kernel: [ 22.445448] br-lan: port 2(wlan0_1) entered blocking state Feb 18 11:47:05 localhost kernel: [ 22.447573] br-lan: port 2(wlan0_1) entered forwarding state Feb 18 11:47:06 localhost kernel: [ 23.395620] br-lan: port 3(wlan2) entered blocking state Feb 18 11:47:06 localhost kernel: [ 23.395650] br-lan: port 3(wlan2) entered disabled state Feb 18 11:47:06 localhost kernel: [ 23.400925] device wlan2 entered promiscuous mode Feb 18 11:47:06 localhost kernel: [ 23.405405] br-lan: port 3(wlan2) entered blocking state Feb 18 11:47:06 localhost kernel: [ 23.410492] br-lan: port 3(wlan2) entered forwarding state Feb 18 11:47:06 localhost kernel: [ 23.670879] ip_local_port_range: prefer different parity for start/end values. Feb 18 11:47:55 localhost kernel: [ 42.556330] lxcbr0: port 1(veth9EM448) entered blocking state Feb 18 11:47:55 localhost kernel: [ 42.556436] lxcbr0: port 1(veth9EM448) entered disabled state Feb 18 11:47:55 localhost kernel: [ 42.562513] device veth9EM448 entered promiscuous mode Feb 18 11:47:55 localhost kernel: [ 42.567430] lxcbr0: port 1(veth9EM448) entered blocking state Feb 18 11:47:55 localhost kernel: [ 42.572935] lxcbr0: port 1(veth9EM448) entered forwarding state Feb 18 11:47:55 localhost kernel: [ 42.579121] lxcbr0: port 1(veth9EM448) entered disabled state Feb 18 11:47:55 localhost kernel: [ 42.612516] eth0: renamed from veth9EM448p Feb 18 11:47:55 localhost kernel: [ 42.636847] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Feb 18 11:47:55 localhost kernel: [ 42.637655] lxcbr0: port 1(veth9EM448) entered blocking state Feb 18 11:47:55 localhost kernel: [ 42.643231] lxcbr0: port 1(veth9EM448) entered forwarding state Feb 18 12:23:25 localhost kernel: [ 2172.247913] rc rc0: two consecutive events of type space Feb 18 13:01:20 localhost kernel: [ 4447.681291] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - ChHltd set, but reason is unknown Feb 18 13:01:20 localhost kernel: [ 4447.684848] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 14:02:48 localhost kernel: [ 8135.126496] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but reason is unknown Feb 18 14:02:48 localhost kernel: [ 8135.130136] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 14:02:48 localhost kernel: [ 8135.233948] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 13 - ChHltd set, but reason is unknown Feb 18 14:02:48 localhost kernel: [ 8135.237588] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 14:02:48 localhost kernel: [ 8135.331297] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but reason is unknown Feb 18 14:02:48 localhost kernel: [ 8135.334850] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 14:02:48 localhost kernel: [ 8135.433698] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason is unknown Feb 18 14:02:48 localhost kernel: [ 8135.437258] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 14:02:48 localhost kernel: [ 8135.536104] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but reason is unknown Feb 18 14:02:48 localhost kernel: [ 8135.539746] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 14:02:48 localhost kernel: [ 8135.638487] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd set, but reason is unknown Feb 18 14:02:48 localhost kernel: [ 8135.642047] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 16:27:45 localhost kernel: [16831.705241] meson8b-dwmac c9410000.ethernet eth0: Link is Down Feb 18 16:27:45 localhost kernel: [16831.706004] br-dmz: port 1(eth0.2) entered disabled state Feb 18 16:27:45 localhost kernel: [16831.711134] br-lan: port 1(eth0.3) entered disabled state Feb 18 16:27:45 localhost kernel: [16831.717690] br-iot: port 1(eth0.5) entered disabled state Feb 18 16:27:48 localhost kernel: [16834.777189] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off Feb 18 16:27:48 localhost kernel: [16834.780197] br-dmz: port 1(eth0.2) entered blocking state Feb 18 16:27:48 localhost kernel: [16834.785349] br-dmz: port 1(eth0.2) entered forwarding state Feb 18 16:27:48 localhost kernel: [16834.791181] br-lan: port 1(eth0.3) entered blocking state Feb 18 16:27:48 localhost kernel: [16834.796222] br-lan: port 1(eth0.3) entered forwarding state Feb 18 16:27:48 localhost kernel: [16834.801983] br-iot: port 1(eth0.5) entered blocking state Feb 18 16:27:48 localhost kernel: [16834.807077] br-iot: port 1(eth0.5) entered forwarding state Feb 18 16:48:04 localhost kernel: [18051.138700] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but reason is unknown Feb 18 16:48:04 localhost kernel: [18051.142256] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 16:48:04 localhost kernel: [18051.148432] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason is unknown Feb 18 16:48:04 localhost kernel: [18051.157523] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 16:48:04 localhost kernel: [18051.238751] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd set, but reason is unknown Feb 18 16:48:04 localhost kernel: [18051.242305] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 16:59:39 localhost kernel: [18745.905563] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd set, but reason is unknown Feb 18 16:59:39 localhost kernel: [18745.909118] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 16:59:39 localhost kernel: [18745.915281] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 13 - ChHltd set, but reason is unknown Feb 18 16:59:39 localhost kernel: [18745.924468] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 16:59:39 localhost kernel: [18745.930625] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 9 - ChHltd set, but reason is unknown Feb 18 16:59:39 localhost kernel: [18745.939737] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 16:59:39 localhost kernel: [18745.962107] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but reason is unknown Feb 18 16:59:39 localhost kernel: [18745.965663] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 Feb 18 17:38:15 localhost kernel: [21061.884216] dwc2 c9100000.usb: dwc2_hc_chhltd_intr_dma: Channel 9 - ChHltd set, but reason is unknown Feb 18 17:38:15 localhost kernel: [21061.887770] dwc2 c9100000.usb: hcint 0x00000002, intsts 0x04600009 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 16:51 ` Simon Huelck @ 2019-02-18 17:05 ` Jose Abreu 2019-02-18 18:05 ` Simon Huelck 0 siblings, 1 reply; 48+ messages in thread From: Jose Abreu @ 2019-02-18 17:05 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev On 2/18/2019 4:51 PM, Simon Huelck wrote: > Hi, > > no im testing vanilla mainline kernel and against 4.14. where > performance was ok. but turning off EEE via ethtool should have same > results than removal of that patch. > > But, since it was mainlined recently , not long ago, i think this was > tested ?? The thing is that phy_init_eee() is called by stmmac and this function does not take into account the broken modes if it's called too early which will cause driver to enable LPI in MAC. And anyway, if you have lpi values in the ethtool stats then EEE is being enabled by stmmac. Please try the change I suggested. Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 17:05 ` Jose Abreu @ 2019-02-18 18:05 ` Simon Huelck 2019-02-19 8:47 ` Jose Abreu 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-18 18:05 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev [-- Attachment #1: Type: text/plain, Size: 2787 bytes --] Am 18.02.2019 um 18:05 schrieb Jose Abreu: > On 2/18/2019 4:51 PM, Simon Huelck wrote: >> Hi, >> >> no im testing vanilla mainline kernel and against 4.14. where >> performance was ok. but turning off EEE via ethtool should have same >> results than removal of that patch. >> >> But, since it was mainlined recently , not long ago, i think this was >> tested ?? > The thing is that phy_init_eee() is called by stmmac and this > function does not take into account the broken modes if it's > called too early which will cause driver to enable LPI in MAC. > > And anyway, if you have lpi values in the ethtool stats then EEE > is being enabled by stmmac. > > Please try the change I suggested. > > Thanks, > Jose Miguel Abreu Hi, disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ), the results are the same. I can confirm the LPI counters are zero or one only after the test..... C:\Users\Simon\Downloads\iperf-2.0.9-win64>iperf -c 10.10.11.1 -i1 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 208 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 10.10.11.1, TCP port 5001 TCP window size: 208 KByte (default) ------------------------------------------------------------ [ 4] local 10.10.11.100 port 56114 connected with 10.10.11.1 port 5001 [ 5] local 10.10.11.100 port 5001 connected with 10.10.11.1 port 47866 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 20.1 MBytes 169 Mbits/sec [ 5] 0.0- 1.0 sec 75.8 MBytes 635 Mbits/sec [ 4] 1.0- 2.0 sec 18.1 MBytes 152 Mbits/sec [ 5] 1.0- 2.0 sec 69.0 MBytes 579 Mbits/sec [ 4] 2.0- 3.0 sec 15.6 MBytes 131 Mbits/sec [ 5] 2.0- 3.0 sec 70.7 MBytes 593 Mbits/sec [ 4] 3.0- 4.0 sec 15.9 MBytes 133 Mbits/sec [ 5] 3.0- 4.0 sec 70.3 MBytes 590 Mbits/sec [ 4] 4.0- 5.0 sec 16.4 MBytes 137 Mbits/sec [ 5] 4.0- 5.0 sec 69.5 MBytes 583 Mbits/sec [ 4] 5.0- 6.0 sec 16.5 MBytes 138 Mbits/sec [ 5] 5.0- 6.0 sec 69.0 MBytes 579 Mbits/sec [ 4] 6.0- 7.0 sec 18.2 MBytes 153 Mbits/sec [ 5] 6.0- 7.0 sec 69.8 MBytes 585 Mbits/sec [ 4] 7.0- 8.0 sec 15.6 MBytes 131 Mbits/sec [ 5] 7.0- 8.0 sec 70.0 MBytes 587 Mbits/sec [ 4] 8.0- 9.0 sec 16.2 MBytes 136 Mbits/sec [ 5] 8.0- 9.0 sec 69.6 MBytes 583 Mbits/sec [ 4] 9.0-10.0 sec 17.1 MBytes 144 Mbits/sec [ 4] 0.0-10.0 sec 170 MBytes 142 Mbits/sec [ 5] 9.0-10.0 sec 69.1 MBytes 580 Mbits/sec [ 5] 0.0-10.0 sec 703 MBytes 589 Mbits/sec regards, Simon [-- Attachment #2: ethtool_test2.txt --] [-- Type: text/plain, Size: 5373 bytes --] NIC statistics: mmc_tx_octetcount_gb: 0 mmc_tx_framecount_gb: 0 mmc_tx_broadcastframe_g: 0 mmc_tx_multicastframe_g: 0 mmc_tx_64_octets_gb: 0 mmc_tx_65_to_127_octets_gb: 0 mmc_tx_128_to_255_octets_gb: 0 mmc_tx_256_to_511_octets_gb: 0 mmc_tx_512_to_1023_octets_gb: 0 mmc_tx_1024_to_max_octets_gb: 0 mmc_tx_unicast_gb: 0 mmc_tx_multicast_gb: 0 mmc_tx_broadcast_gb: 0 mmc_tx_underflow_error: 0 mmc_tx_singlecol_g: 0 mmc_tx_multicol_g: 0 mmc_tx_deferred: 0 mmc_tx_latecol: 0 mmc_tx_exesscol: 0 mmc_tx_carrier_error: 0 mmc_tx_octetcount_g: 0 mmc_tx_framecount_g: 0 mmc_tx_excessdef: 0 mmc_tx_pause_frame: 0 mmc_tx_vlan_frame_g: 0 mmc_rx_framecount_gb: 2348653 mmc_rx_octetcount_gb: 3299190414 mmc_rx_octetcount_g: 3299190413 mmc_rx_broadcastframe_g: 92816 mmc_rx_multicastframe_g: 249 mmc_rx_crc_error: 2 mmc_rx_align_error: 0 mmc_rx_run_error: 2 mmc_rx_jabber_error: 0 mmc_rx_undersize_g: 0 mmc_rx_oversize_g: 0 mmc_rx_64_octets_gb: 0 mmc_rx_65_to_127_octets_gb: 172809 mmc_rx_128_to_255_octets_gb: 15902 mmc_rx_256_to_511_octets_gb: 659 mmc_rx_512_to_1023_octets_gb: 370 mmc_rx_1024_to_max_octets_gb: 2158911 mmc_rx_unicast_g: 2255586 mmc_rx_length_error: 2 mmc_rx_autofrangetype: 0 mmc_rx_pause_frames: 0 mmc_rx_fifo_overflow: 2924 mmc_rx_vlan_frames_gb: 2348591 mmc_rx_watchdog_error: 0 mmc_rx_ipc_intr_mask: 4294377460 mmc_rx_ipc_intr: 0 mmc_rx_ipv4_gd: 2255929 mmc_rx_ipv4_hderr: 0 mmc_rx_ipv4_nopay: 21 mmc_rx_ipv4_frag: 0 mmc_rx_ipv4_udsbl: 1 mmc_rx_ipv4_gd_octets: 3242768541 mmc_rx_ipv4_hderr_octets: 0 mmc_rx_ipv4_nopay_octets: 982 mmc_rx_ipv4_frag_octets: 0 mmc_rx_ipv4_udsbl_octets: 12 mmc_rx_ipv6_gd_octets: 20851 mmc_rx_ipv6_hderr_octets: 0 mmc_rx_ipv6_nopay_octets: 0 mmc_rx_ipv6_gd: 93 mmc_rx_ipv6_hderr: 0 mmc_rx_ipv6_nopay: 0 mmc_rx_udp_gd: 1942 mmc_rx_udp_err: 0 mmc_rx_tcp_gd: 2254045 mmc_rx_tcp_err: 0 mmc_rx_icmp_gd: 34 mmc_rx_icmp_err: 0 mmc_rx_udp_gd_octets: 885355 mmc_rx_udp_err_octets: 0 mmc_rx_tcp_gd_octets: 3196780259 mmc_rx_tcp_err_octets: 0 mmc_rx_icmp_gd_octets: 1300 mmc_rx_icmp_err_octets: 0 tx_underflow: 0 tx_carrier: 0 tx_losscarrier: 0 vlan_tag: 2345667 tx_deferred: 0 tx_vlan: 655982 tx_jabber: 0 tx_frame_flushed: 0 tx_payload_error: 0 tx_ip_header_error: 0 rx_desc: 0 sa_filter_fail: 0 overflow_error: 0 ipc_csum_error: 0 rx_collision: 0 rx_crc_errors: 0 dribbling_bit: 0 rx_length: 0 rx_mii: 0 rx_multicast: 0 rx_gmac_overflow: 0 rx_watchdog: 0 da_rx_filter_fail: 0 sa_rx_filter_fail: 0 rx_missed_cntr: 0 rx_overflow_cntr: 0 rx_vlan: 0 tx_undeflow_irq: 0 tx_process_stopped_irq: 0 tx_jabber_irq: 0 rx_overflow_irq: 0 rx_buf_unav_irq: 0 rx_process_stopped_irq: 0 rx_watchdog_irq: 0 tx_early_irq: 0 fatal_bus_error_irq: 0 rx_early_irq: 20521 threshold: 1 tx_pkt_n: 655982 rx_pkt_n: 2345727 normal_irq_n: 227466 rx_normal_irq_n: 195493 napi_poll: 227438 tx_normal_irq_n: 28972 tx_clean: 227438 tx_set_ic_bit: 26239 irq_receive_pmt_irq_n: 0 mmc_tx_irq_n: 0 mmc_rx_irq_n: 0 mmc_rx_csum_offload_irq_n: 0 irq_tx_path_in_lpi_mode_n: 0 irq_tx_path_exit_lpi_mode_n: 0 irq_rx_path_in_lpi_mode_n: 1 irq_rx_path_exit_lpi_mode_n: 1 phy_eee_wakeup_error_n: 0 ip_hdr_err: 0 ip_payload_err: 0 ip_csum_bypassed: 0 ipv4_pkt_rcvd: 0 ipv6_pkt_rcvd: 0 no_ptp_rx_msg_type_ext: 0 ptp_rx_msg_type_sync: 0 ptp_rx_msg_type_follow_up: 0 ptp_rx_msg_type_delay_req: 0 ptp_rx_msg_type_delay_resp: 0 ptp_rx_msg_type_pdelay_req: 0 ptp_rx_msg_type_pdelay_resp: 0 ptp_rx_msg_type_pdelay_follow_up: 0 ptp_rx_msg_type_announce: 0 ptp_rx_msg_type_management: 0 ptp_rx_msg_pkt_reserved_type: 0 ptp_frame_type: 0 ptp_ver: 0 timestamp_dropped: 0 av_pkt_rcvd: 0 av_tagged_pkt_rcvd: 0 vlan_tag_priority_val: 0 l3_filter_match: 0 l4_filter_match: 0 l3_l4_filter_no_match: 0 irq_pcs_ane_n: 0 irq_pcs_link_n: 0 irq_rgmii_n: 0 mtl_tx_status_fifo_full: 0 mtl_tx_fifo_not_empty: 0 mmtl_fifo_ctrl: 0 mtl_tx_fifo_read_ctrl_write: 0 mtl_tx_fifo_read_ctrl_wait: 0 mtl_tx_fifo_read_ctrl_read: 0 mtl_tx_fifo_read_ctrl_idle: 0 mac_tx_in_pause: 0 mac_tx_frame_ctrl_xfer: 0 mac_tx_frame_ctrl_idle: 0 mac_tx_frame_ctrl_wait: 0 mac_tx_frame_ctrl_pause: 0 mac_gmii_tx_proto_engine: 0 mtl_rx_fifo_fill_level_full: 0 mtl_rx_fifo_fill_above_thresh: 0 mtl_rx_fifo_fill_below_thresh: 0 mtl_rx_fifo_fill_level_empty: 0 mtl_rx_fifo_read_ctrl_flush: 0 mtl_rx_fifo_read_ctrl_read_data: 0 mtl_rx_fifo_read_ctrl_status: 0 mtl_rx_fifo_read_ctrl_idle: 0 mtl_rx_fifo_ctrl_active: 0 mac_rx_frame_ctrl_fifo: 0 mac_gmii_rx_proto_engine: 0 tx_tso_frames: 0 tx_tso_nfrags: 0 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 18:05 ` Simon Huelck @ 2019-02-19 8:47 ` Jose Abreu 2019-02-19 19:41 ` Simon Huelck 0 siblings, 1 reply; 48+ messages in thread From: Jose Abreu @ 2019-02-19 8:47 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Hi Simon, On 2/18/2019 6:05 PM, Simon Huelck wrote: > disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ), > the results are the same. I can confirm the LPI counters are zero or one > only after the test..... It's interesting to see that you have a lot of RX packets but few RX interrupts. This can either be due to mis-configuration of interrupt flags or RX Watchdog. 1. For interrupt flags you should be using LEVEL triggered IRQ. 2. For RX Watchdog you can try disabling it by adding the following in your platform wrapper driver (which will be "dwmac-meson8b.c", at probe): "plat_data->force_sf_dma_mode = 1;" and "plat_data->riwt_off = 1;" Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-19 8:47 ` Jose Abreu @ 2019-02-19 19:41 ` Simon Huelck 2019-02-21 14:21 ` Jerome Brunet 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-19 19:41 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev Am 19.02.2019 um 09:47 schrieb Jose Abreu: > Hi Simon, > > On 2/18/2019 6:05 PM, Simon Huelck wrote: >> disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ), >> the results are the same. I can confirm the LPI counters are zero or one >> only after the test..... > It's interesting to see that you have a lot of RX packets but few > RX interrupts. This can either be due to mis-configuration of > interrupt flags or RX Watchdog. > > 1. For interrupt flags you should be using LEVEL triggered IRQ. > 2. For RX Watchdog you can try disabling it by adding the > following in your platform wrapper driver (which will be > "dwmac-meson8b.c", at probe): > "plat_data->force_sf_dma_mode = 1;" and > "plat_data->riwt_off = 1;" > > Thanks, > Jose Miguel Abreu Hi, are you aware that odroid c2 dts is using level irq ? at which numbers do you estimage that RX irqs are low in numbers ? regards, Simon ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-19 19:41 ` Simon Huelck @ 2019-02-21 14:21 ` Jerome Brunet 2019-02-21 17:27 ` Simon Huelck 0 siblings, 1 reply; 48+ messages in thread From: Jerome Brunet @ 2019-02-21 14:21 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, netdev, alexandre.torgue, Emiliano Ingrassia, Gpeppe.cavallaro On Tue, 2019-02-19 at 20:41 +0100, Simon Huelck wrote: > Am 19.02.2019 um 09:47 schrieb Jose Abreu: > > Hi Simon, > > > > On 2/18/2019 6:05 PM, Simon Huelck wrote: > > > disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ), > > > the results are the same. I can confirm the LPI counters are zero or one > > > only after the test..... > > It's interesting to see that you have a lot of RX packets but few > > RX interrupts. This can either be due to mis-configuration of > > interrupt flags or RX Watchdog. > > > > 1. For interrupt flags you should be using LEVEL triggered IRQ. > > 2. For RX Watchdog you can try disabling it by adding the > > following in your platform wrapper driver (which will be > > "dwmac-meson8b.c", at probe): > > "plat_data->force_sf_dma_mode = 1;" and > > "plat_data->riwt_off = 1;" > > > > Thanks, > > Jose Miguel Abreu > > Hi, > > > are you aware that odroid c2 dts is using level irq ? The odroid-c2 (meson-gxl) is using level triggered irq, indeed. For a reason that still eludes me, The odroid-c1 (meson8b) isn't. This is confusing since both boards have been mentionned in this thread. > > at which numbers do you estimage that RX irqs are low in numbers ? > > > regards, > > Simon > > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-21 14:21 ` Jerome Brunet @ 2019-02-21 17:27 ` Simon Huelck 2019-02-21 17:46 ` Jerome Brunet 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-21 17:27 UTC (permalink / raw) To: Jerome Brunet, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, netdev, alexandre.torgue, Emiliano Ingrassia, Gpeppe.cavallaro Am 21.02.2019 um 15:21 schrieb Jerome Brunet: > On Tue, 2019-02-19 at 20:41 +0100, Simon Huelck wrote: >> Am 19.02.2019 um 09:47 schrieb Jose Abreu: >>> Hi Simon, >>> >>> On 2/18/2019 6:05 PM, Simon Huelck wrote: >>>> disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ), >>>> the results are the same. I can confirm the LPI counters are zero or one >>>> only after the test..... >>> It's interesting to see that you have a lot of RX packets but few >>> RX interrupts. This can either be due to mis-configuration of >>> interrupt flags or RX Watchdog. >>> >>> 1. For interrupt flags you should be using LEVEL triggered IRQ. >>> 2. For RX Watchdog you can try disabling it by adding the >>> following in your platform wrapper driver (which will be >>> "dwmac-meson8b.c", at probe): >>> "plat_data->force_sf_dma_mode = 1;" and >>> "plat_data->riwt_off = 1;" >>> >>> Thanks, >>> Jose Miguel Abreu >> Hi, >> >> >> are you aware that odroid c2 dts is using level irq ? > The odroid-c2 (meson-gxl) is using level triggered irq, indeed. > For a reason that still eludes me, The odroid-c1 (meson8b) isn't. > > This is confusing since both boards have been mentionned in this thread. > >> at which numbers do you estimage that RX irqs are low in numbers ? >> >> >> regards, >> >> Simon >> >> >> _______________________________________________ >> linux-amlogic mailing list >> linux-amlogic@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-amlogic > Hi, this was changed recently, with a patch for the EEE stuff , see here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e955c53e61c154ba26b9bb15da6b858 before that the IRQ stuff was differently. I tried to revert this patch via git locally, but had no success ( i guess git tried to revert this patch on the server :-P) regards, Simon ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-21 17:27 ` Simon Huelck @ 2019-02-21 17:46 ` Jerome Brunet 2019-02-21 19:34 ` Simon Huelck 2019-02-24 15:00 ` Simon Huelck 0 siblings, 2 replies; 48+ messages in thread From: Jerome Brunet @ 2019-02-21 17:46 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote: > Hi, > > > > this was changed recently, with a patch for the EEE stuff , see here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e955c53e61c154ba26b9bb15da6b858 Hu, I was not aware this finally went through. Good ! As explained in the patch and by Jose, the GMAC should be using IRQ_LEVEL. The realtek PHY has EEE enabled by default. Having this enabled generates a lot of (Low Power) Interrupts. Previously, when the GMAC used IRQ_EDGE. Because it is wrong, we would eventually miss an IRQ and the interface would just die. Unfortunately, it was not that easy find out. 2 years ago, we just noticed that disabling EEE would make the failure go away. Forcing this EEE feature off through DT was merely a work around. Now that the real cause of the problem is known, there is no reason to keep this hack around. Whether EEE adds a performance penality and why, is another topic. As Jose pointed out, you can disable EEE at runtime, using ethtool. Jerome ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-21 17:46 ` Jerome Brunet @ 2019-02-21 19:34 ` Simon Huelck 2019-02-22 17:21 ` Anand Moon 2019-02-24 15:00 ` Simon Huelck 1 sibling, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-21 19:34 UTC (permalink / raw) To: Jerome Brunet, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Am 21.02.2019 um 18:46 schrieb Jerome Brunet: > On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote: >> Hi, >> >> >> >> this was changed recently, with a patch for the EEE stuff , see here: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e955c53e61c154ba26b9bb15da6b858 > Hu, I was not aware this finally went through. Good ! > As explained in the patch and by Jose, the GMAC should be using IRQ_LEVEL. > > The realtek PHY has EEE enabled by default. Having this enabled generates a > lot of (Low Power) Interrupts. > > Previously, when the GMAC used IRQ_EDGE. Because it is wrong, we would > eventually miss an IRQ and the interface would just die. Unfortunately, it was > not that easy find out. > > 2 years ago, we just noticed that disabling EEE would make the failure go > away. Forcing this EEE feature off through DT was merely a work around. > > Now that the real cause of the problem is known, there is no reason to keep > this hack around. > > Whether EEE adds a performance penality and why, is another topic. > As Jose pointed out, you can disable EEE at runtime, using ethtool. > > Jerome > Hi, i disabled EEE via ethtool and via the .dtb , but the performance penalty stays. Kernel 4.14 still gives me the former "good" performance. regards, Simon ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-21 19:34 ` Simon Huelck @ 2019-02-22 17:21 ` Anand Moon 0 siblings, 0 replies; 48+ messages in thread From: Anand Moon @ 2019-02-22 17:21 UTC (permalink / raw) To: Simon Huelck Cc: Jerome Brunet, Jose Abreu, Martin Blumenstingl, linux-amlogic, netdev, Alexandre TORGUE, Emiliano Ingrassia, Gpeppe.cavallaro Hi All, On Fri, 22 Feb 2019 at 01:05, Simon Huelck <simonmail@gmx.de> wrote: > > Am 21.02.2019 um 18:46 schrieb Jerome Brunet: > > On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote: > >> Hi, > >> > >> > >> > >> this was changed recently, with a patch for the EEE stuff , see here: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e955c53e61c154ba26b9bb15da6b858 > > Hu, I was not aware this finally went through. Good ! > > As explained in the patch and by Jose, the GMAC should be using IRQ_LEVEL. > > > > The realtek PHY has EEE enabled by default. Having this enabled generates a > > lot of (Low Power) Interrupts. > > > > Previously, when the GMAC used IRQ_EDGE. Because it is wrong, we would > > eventually miss an IRQ and the interface would just die. Unfortunately, it was > > not that easy find out. > > > > 2 years ago, we just noticed that disabling EEE would make the failure go > > away. Forcing this EEE feature off through DT was merely a work around. > > > > Now that the real cause of the problem is known, there is no reason to keep > > this hack around. > > > > Whether EEE adds a performance penality and why, is another topic. > > As Jose pointed out, you can disable EEE at runtime, using ethtool. > > > > Jerome > > > Hi, > > > > i disabled EEE via ethtool and via the .dtb , but the performance > penalty stays. Kernel 4.14 still gives me the former "good" performance. > > > > regards, > > Simon > > Sorry this is off the topic. I am using Archlinux on Odroid C1+ and the latest kernel loads with no issue. only issue is I have is the each time their is random MAC address so I get new IP from dhcp server. How can I avoid this. I have tried to enable eFuse driver but with no success. On Odroid C2 I dont have any issue, it always retained the unique MAC address. Best Regards -Anand ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-21 17:46 ` Jerome Brunet 2019-02-21 19:34 ` Simon Huelck @ 2019-02-24 15:00 ` Simon Huelck 2019-02-24 15:02 ` Simon Huelck 2019-02-24 19:42 ` Sebastian Gottschall 1 sibling, 2 replies; 48+ messages in thread From: Simon Huelck @ 2019-02-24 15:00 UTC (permalink / raw) To: Jerome Brunet, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Am 21.02.2019 um 18:46 schrieb Jerome Brunet: > On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote: >> Hi, >> >> >> >> this was changed recently, with a patch for the EEE stuff , see here: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e955c53e61c154ba26b9bb15da6b858 > Hu, I was not aware this finally went through. Good ! > As explained in the patch and by Jose, the GMAC should be using IRQ_LEVEL. > > The realtek PHY has EEE enabled by default. Having this enabled generates a > lot of (Low Power) Interrupts. > > Previously, when the GMAC used IRQ_EDGE. Because it is wrong, we would > eventually miss an IRQ and the interface would just die. Unfortunately, it was > not that easy find out. > > 2 years ago, we just noticed that disabling EEE would make the failure go > away. Forcing this EEE feature off through DT was merely a work around. > > Now that the real cause of the problem is known, there is no reason to keep > this hack around. > > Whether EEE adds a performance penality and why, is another topic. > As Jose pointed out, you can disable EEE at runtime, using ethtool. > > Jerome > Hi, i tested the latest patches of **next-20190222, there were some stmmac improvements.** ** ** **For the topic i got , the performance stayed identical.** **C:\Users\Simon\Downloads\iperf3.6_64bit\iperf3.6_64bit>iperf3.exe -c 10.10.11.1 -i1 warning: Ignoring nonsense TCP MSS 0 Connecting to host 10.10.11.1, port 5201 [ 5] local 10.10.11.100 port 50830 connected to 10.10.11.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 78.9 MBytes 661 Mbits/sec [ 5] 1.00-2.00 sec 79.1 MBytes 664 Mbits/sec [ 5] 2.00-3.00 sec 79.4 MBytes 666 Mbits/sec [ 5] 3.00-4.00 sec 34.4 MBytes 288 Mbits/sec [ 5] 4.00-5.00 sec 16.1 MBytes 135 Mbits/sec [ 5] 5.00-6.00 sec 15.8 MBytes 132 Mbits/sec [ 5] 6.00-7.00 sec 14.2 MBytes 120 Mbits/sec [ 5] 7.00-8.00 sec 15.6 MBytes 131 Mbits/sec [ 5] 8.00-9.00 sec 14.9 MBytes 125 Mbits/sec [ 5] 9.00-10.00 sec 15.0 MBytes 126 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 363 MBytes 305 Mbits/sec sender [ 5] 0.00-10.04 sec 363 MBytes 303 Mbits/sec receiver ** **its clearly visible when i activated the other stream for getting duplex load ... The highest rate also stays alot under the possible 930MBits that i have seen earlier with 4.14. ** ** ** **the parallel stream reached around 450Mbits , which almost sums up to 660Mbits. This is what i meant when i said that duplex might be broken. ** ** ** **Connecting to host 10.10.11.100, port 5201 [ 5] local 10.10.11.1 port 38658 connected to 10.10.11.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 62.9 MBytes 528 Mbits/sec 0 65.6 KBytes [ 5] 1.00-2.00 sec 56.9 MBytes 477 Mbits/sec 0 65.6 KBytes [ 5] 2.00-3.00 sec 55.9 MBytes 469 Mbits/sec 0 65.6 KBytes [ 5] 3.00-4.00 sec 53.0 MBytes 445 Mbits/sec 0 65.6 KBytes [ 5] 4.00-5.00 sec 54.3 MBytes 455 Mbits/sec 0 65.6 KBytes [ 5] 5.00-6.00 sec 54.8 MBytes 460 Mbits/sec 0 65.6 KBytes [ 5] 6.00-7.00 sec 45.3 MBytes 380 Mbits/sec 0 65.6 KBytes [ 5] 7.00-8.00 sec 51.2 MBytes 429 Mbits/sec 0 65.6 KBytes [ 5] 8.00-9.00 sec 56.1 MBytes 470 Mbits/sec 0 65.6 KBytes [ 5] 9.00-10.00 sec 55.3 MBytes 464 Mbits/sec 0 65.6 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 546 MBytes 458 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 545 MBytes 457 Mbits/sec receiver** ** ** **regards,** **Simon ** ** ** ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-24 15:00 ` Simon Huelck @ 2019-02-24 15:02 ` Simon Huelck 2019-02-24 19:42 ` Sebastian Gottschall 1 sibling, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-02-24 15:02 UTC (permalink / raw) To: Jerome Brunet, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Am 24.02.2019 um 16:00 schrieb Simon Huelck: > Am 21.02.2019 um 18:46 schrieb Jerome Brunet: >> On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote: >>> Hi, >>> >>> >>> >>> this was changed recently, with a patch for the EEE stuff , see here: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e955c53e61c154ba26b9bb15da6b858 >> Hu, I was not aware this finally went through. Good ! >> As explained in the patch and by Jose, the GMAC should be using IRQ_LEVEL. >> >> The realtek PHY has EEE enabled by default. Having this enabled generates a >> lot of (Low Power) Interrupts. >> >> Previously, when the GMAC used IRQ_EDGE. Because it is wrong, we would >> eventually miss an IRQ and the interface would just die. Unfortunately, it was >> not that easy find out. >> >> 2 years ago, we just noticed that disabling EEE would make the failure go >> away. Forcing this EEE feature off through DT was merely a work around. >> >> Now that the real cause of the problem is known, there is no reason to keep >> this hack around. >> >> Whether EEE adds a performance penality and why, is another topic. >> As Jose pointed out, you can disable EEE at runtime, using ethtool. >> >> Jerome >> > Hi, > > > i tested the latest patches of **next-20190222, there were some stmmac > improvements.** > > ** > ** > > **For the topic i got , the performance stayed identical.** > > **C:\Users\Simon\Downloads\iperf3.6_64bit\iperf3.6_64bit>iperf3.exe -c > 10.10.11.1 -i1 > warning: Ignoring nonsense TCP MSS 0 > Connecting to host 10.10.11.1, port 5201 > [ 5] local 10.10.11.100 port 50830 connected to 10.10.11.1 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 78.9 MBytes 661 Mbits/sec > [ 5] 1.00-2.00 sec 79.1 MBytes 664 Mbits/sec > [ 5] 2.00-3.00 sec 79.4 MBytes 666 Mbits/sec > [ 5] 3.00-4.00 sec 34.4 MBytes 288 Mbits/sec > [ 5] 4.00-5.00 sec 16.1 MBytes 135 Mbits/sec > [ 5] 5.00-6.00 sec 15.8 MBytes 132 Mbits/sec > [ 5] 6.00-7.00 sec 14.2 MBytes 120 Mbits/sec > [ 5] 7.00-8.00 sec 15.6 MBytes 131 Mbits/sec > [ 5] 8.00-9.00 sec 14.9 MBytes 125 Mbits/sec > [ 5] 9.00-10.00 sec 15.0 MBytes 126 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate > [ 5] 0.00-10.00 sec 363 MBytes 305 Mbits/sec sender > [ 5] 0.00-10.04 sec 363 MBytes 303 Mbits/sec > receiver > > ** > > **its clearly visible when i activated the other stream for getting > duplex load ... The highest rate also stays alot under the possible > 930MBits that i have seen earlier with 4.14. > ** > > ** > ** > > **the parallel stream reached around 450Mbits , which almost sums up to > 660Mbits. This is what i meant when i said that duplex might be broken. > ** > > ** > ** > > **Connecting to host 10.10.11.100, port 5201 > [ 5] local 10.10.11.1 port 38658 connected to 10.10.11.100 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 62.9 MBytes 528 Mbits/sec 0 65.6 KBytes > [ 5] 1.00-2.00 sec 56.9 MBytes 477 Mbits/sec 0 65.6 KBytes > [ 5] 2.00-3.00 sec 55.9 MBytes 469 Mbits/sec 0 65.6 KBytes > [ 5] 3.00-4.00 sec 53.0 MBytes 445 Mbits/sec 0 65.6 KBytes > [ 5] 4.00-5.00 sec 54.3 MBytes 455 Mbits/sec 0 65.6 KBytes > [ 5] 5.00-6.00 sec 54.8 MBytes 460 Mbits/sec 0 65.6 KBytes > [ 5] 6.00-7.00 sec 45.3 MBytes 380 Mbits/sec 0 65.6 KBytes > [ 5] 7.00-8.00 sec 51.2 MBytes 429 Mbits/sec 0 65.6 KBytes > [ 5] 8.00-9.00 sec 56.1 MBytes 470 Mbits/sec 0 65.6 KBytes > [ 5] 9.00-10.00 sec 55.3 MBytes 464 Mbits/sec 0 65.6 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 546 MBytes 458 Mbits/sec 0 sender > [ 5] 0.00-10.00 sec 545 MBytes 457 Mbits/sec > receiver** > > ** > ** > > **regards,** > > **Simon > ** > > ** > ** > Hi, and another thing that i recognized , TX from my odroid stays around 450 Mbits ( is not affected by RX). but RX suffers alot from the TX stuff ( the max sum of RX/TX seems to be the magical 650MBits) regards, Simon ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-24 15:00 ` Simon Huelck 2019-02-24 15:02 ` Simon Huelck @ 2019-02-24 19:42 ` Sebastian Gottschall 2019-02-24 20:34 ` Simon Huelck 1 sibling, 1 reply; 48+ messages in thread From: Sebastian Gottschall @ 2019-02-24 19:42 UTC (permalink / raw) To: Simon Huelck, Jerome Brunet, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev > ** > > **its clearly visible when i activated the other stream for getting > duplex load ... The highest rate also stays alot under the possible > 930MBits that i have seen earlier with 4.14. > ** > > ** > ** > > **the parallel stream reached around 450Mbits , which almost sums up to > 660Mbits. This is what i meant when i said that duplex might be broken. > ** > > ** > ** > > **Connecting to host 10.10.11.100, port 5201 > [ 5] local 10.10.11.1 port 38658 connected to 10.10.11.100 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 62.9 MBytes 528 Mbits/sec 0 65.6 KBytes > [ 5] 1.00-2.00 sec 56.9 MBytes 477 Mbits/sec 0 65.6 KBytes > [ 5] 2.00-3.00 sec 55.9 MBytes 469 Mbits/sec 0 65.6 KBytes > [ 5] 3.00-4.00 sec 53.0 MBytes 445 Mbits/sec 0 65.6 KBytes > [ 5] 4.00-5.00 sec 54.3 MBytes 455 Mbits/sec 0 65.6 KBytes > [ 5] 5.00-6.00 sec 54.8 MBytes 460 Mbits/sec 0 65.6 KBytes > [ 5] 6.00-7.00 sec 45.3 MBytes 380 Mbits/sec 0 65.6 KBytes > [ 5] 7.00-8.00 sec 51.2 MBytes 429 Mbits/sec 0 65.6 KBytes > [ 5] 8.00-9.00 sec 56.1 MBytes 470 Mbits/sec 0 65.6 KBytes > [ 5] 9.00-10.00 sec 55.3 MBytes 464 Mbits/sec 0 65.6 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 546 MBytes 458 Mbits/sec 0 sender > [ 5] 0.00-10.00 sec 545 MBytes 457 Mbits/sec > receiver** > > ** > ** > > **regards,** > > **Simon > ** > > ** > ** which stmac device are you talking about? its not your windows pc. if its a ipq8064 based device or something like that you should look on a very different location. this platform like the r7800 has stmac performance problems since the kernel clk code for this device is lets say "very wrong". so alot of clocks arent correct and so the ethernet performance will suffer. i can tell you that i'm able to get 930 mbit on a stmmac based device. but as i said. the kernel needs other numerous fixes to get a good performance root@TEW827:~# iperf3 -c 10.88.193.134 -i 1 Connecting to host 10.88.193.134, port 5201 [ 5] local 10.88.193.90 port 36024 connected to 10.88.193.134 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 108 MBytes 903 Mbits/sec 0 5.17 MBytes [ 5] 1.00-2.00 sec 112 MBytes 943 Mbits/sec 0 5.17 MBytes [ 5] 2.00-3.00 sec 109 MBytes 913 Mbits/sec 0 6.02 MBytes [ 5] 3.00-4.00 sec 112 MBytes 944 Mbits/sec 0 6.02 MBytes [ 5] 4.00-5.00 sec 109 MBytes 910 Mbits/sec 1 6.02 MBytes [ 5] 5.00-6.00 sec 111 MBytes 935 Mbits/sec 0 6.02 MBytes [ 5] 6.00-7.00 sec 109 MBytes 912 Mbits/sec 1 6.02 MBytes ^C[ 5] 7.00-7.51 sec 56.2 MBytes 935 Mbits/sec 0 6.02 MBytes > > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-24 19:42 ` Sebastian Gottschall @ 2019-02-24 20:34 ` Simon Huelck 2019-02-27 11:09 ` Jose Abreu 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-24 20:34 UTC (permalink / raw) To: Sebastian Gottschall, Jerome Brunet, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Am 24.02.2019 um 20:42 schrieb Sebastian Gottschall: > vice are you talking about? its not your windows pc. if its a ipq8064 > based device or something like that you should look > on a very different location. this platform like the r7800 has stmac > performance problems since the kernel clk code for this device is lets > say "very wrong". > so alot of clocks arent correct and so the ethernet performance will > suffer. > > i can tell you that i'm able to get 930 mbit on a stmmac based device. > but as i said. the kernel needs other numerous fixes to get a good > performance Hi, the topic is about ODROID C2 / Amlogic S905X since the start. we have a performance regression since 4.14. regards, Simon ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-24 20:34 ` Simon Huelck @ 2019-02-27 11:09 ` Jose Abreu 2019-02-27 19:02 ` Simon Huelck 2019-02-27 21:03 ` Simon Huelck 0 siblings, 2 replies; 48+ messages in thread From: Jose Abreu @ 2019-02-27 11:09 UTC (permalink / raw) To: Simon Huelck, Sebastian Gottschall, Jerome Brunet, Jose Abreu, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi Simon, On 2/24/2019 8:34 PM, Simon Huelck wrote: > the topic is about ODROID C2 / Amlogic S905X since the start. we have a > performance regression since 4.14. As we are not advancing in this topic I suggest you try bisecting the offending commit. Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-27 11:09 ` Jose Abreu @ 2019-02-27 19:02 ` Simon Huelck 2019-03-01 9:23 ` Jose Abreu 2019-02-27 21:03 ` Simon Huelck 1 sibling, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-02-27 19:02 UTC (permalink / raw) To: Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi, the thing is , that im not a stmmac developer. Yes , maybe i can bissect it and yes you are lucky since im a C-developer since a long time for embedded systems. The problem is that i dont understand the structure of stmmac and im not aware of any documentation about the driver structure nor the underlying ethernet hardware ( even though im used to ethernet hardware in embedded environment ). So how shall i recognize the relevant change between 4.14.29 and 5.0rc8 ? Is it in the DTS/DTB, wrong hardware description ? Is it in the code ? how is the duplex hardware working on this piece ? I can try to support you the best i can, but i have little chances to analyze it myself. At which measurements / counters is it possible to see that duplex is fully working ? Why did even the non-duplex bandwidth regress from 900MBits to 650 ? Why is that 650 MBits dividing up to TX and RX in summary when doing duplex ? Why is TX not starving in duplex but RX ? From my point of view should be the following things given: - the non duplex bandwidth should be somewhere around 900MBits , the HW is capable of that - TX should not influence RX or vice versa in duplex - the duplex bandwidth should be 900MBits in both directions ( maybe a bit asymetric when buffers in both dirs are not same ) I guess we need some profiling on stmmac and ( at least i need ) more knowledge of the hardware and stmmac itself. Can someone point me to the driver documentation, describing the functions in the code and the structure ? How can i profile stmmac ( usually im using hardware / JTAG debuggers at work, but here @home i got nothing like that ) So how do we continue ? regards, Simon Am 27.02.2019 um 12:09 schrieb Jose Abreu: > Hi Simon, > > On 2/24/2019 8:34 PM, Simon Huelck wrote: >> the topic is about ODROID C2 / Amlogic S905X since the start. we have a >> performance regression since 4.14. > As we are not advancing in this topic I suggest you try bisecting > the offending commit. > > Thanks, > Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-27 19:02 ` Simon Huelck @ 2019-03-01 9:23 ` Jose Abreu 2019-03-05 9:55 ` Simon Huelck 2019-05-11 14:53 ` Simon Huelck 0 siblings, 2 replies; 48+ messages in thread From: Jose Abreu @ 2019-03-01 9:23 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi Simon, On 2/27/2019 7:02 PM, Simon Huelck wrote: > Hi, > > > the thing is , that im not a stmmac developer. Yes , maybe i can bissect > it and yes you are lucky since im a C-developer since a long time for > embedded systems. > > The problem is that i dont understand the structure of stmmac and im not > aware of any documentation about the driver structure nor the underlying > ethernet hardware ( even though im used to ethernet hardware in embedded > environment ). So how shall i recognize the relevant change between > 4.14.29 and 5.0rc8 ? > > > Is it in the DTS/DTB, wrong hardware description ? Is it in the code ? > how is the duplex hardware working on this piece ? > > I can try to support you the best i can, but i have little chances to > analyze it myself. At which measurements / counters is it possible to > see that duplex is fully working ? Why did even the non-duplex > bandwidth regress from 900MBits to 650 ? Why is that 650 MBits dividing > up to TX and RX in summary when doing duplex ? Why is TX not starving in > duplex but RX ? > > From my point of view should be the following things given: > - the non duplex bandwidth should be somewhere around 900MBits , the HW > is capable of that > - TX should not influence RX or vice versa in duplex > - the duplex bandwidth should be 900MBits in both directions ( maybe a > bit asymetric when buffers in both dirs are not same ) > > I guess we need some profiling on stmmac and ( at least i need ) more > knowledge of the hardware and stmmac itself. Can someone point me to the > driver documentation, describing the functions in the code and the > structure ? How can i profile stmmac ( usually im using hardware / JTAG > debuggers at work, but here @home i got nothing like that ) > > So how do we continue ? When I said bissect I was meaning GIT Bissect [1]. You shouldn't need any development background for this. You just have to start bissect, compile, test and check if commit is good or not. I'm not very familiar with this feature but I think you can bissect pretty fast if you say you just want stmmac commits, check ("Cutting down bisection by giving more parameters to bisect start") on previous link ... In your case it would be stmmac changes, dts, and phy. [1] https://git-scm.com/docs/git-bisect Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-03-01 9:23 ` Jose Abreu @ 2019-03-05 9:55 ` Simon Huelck 2019-03-06 11:35 ` Simon Huelck 2019-05-11 14:53 ` Simon Huelck 1 sibling, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-03-05 9:55 UTC (permalink / raw) To: Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi guys, 1. i discovered something strange. when i never configure my external VLAN interface UP ( firewall doesnt start, traffic shaper CAKE doesnt start), my non duplex iperf bandwidth increases from 600MBits to 930. 2. duplex isnt working, TX is totally starving RX, the total bandwidth is 900MBits, whats going on there ? 3. i had a MTU issue ( was set to 1500, but due to VLANs etc 1450 would be better ) but this didnt change performance 4. even when i up eth0.4, then i down eth0.4, then flush iptables and shaper were never added, i drop to 600MBits .... questions: - why is duplex still not working even so the kernel says so ? - why is TX totally starving RX, even so duplex is "on" - when i flush all my iptable rules, and the traffic shaper, still im bond to 600MBits ... very strange, someone got an idea ? upping eth0.4 is cutting the performance, even when other VLAN IFs like eth0.3, eth0.2, eth0.5 are up and bridged ( eth0.4 isnt bridged somewhere ) my setup: br-dmz 8000.7ef0fd9b157f no eth0.2 br-guest 8000.001f1fbbbd60 no wlan0 br-iot 8000.7ef0fd9b157f no eth0.5 br-lan 8000.001f1fbbbd61 no eth0.3 wlan0_1 wlan2 eth0.4 is my uplink all the bridges are internally , eth0.4 is externally C:\Users\Simon\Downloads\iperf3.6_64bit\iperf3.6_64bit>iperf3.exe -c 10.10.11.1 -i1 warning: Ignoring nonsense TCP MSS 0 Connecting to host 10.10.11.1, port 5201 [ 5] local 10.10.11.100 port 52173 connected to 10.10.11.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 384 KBytes 3.14 Mbits/sec [ 5] 1.00-2.00 sec 384 KBytes 3.15 Mbits/sec [ 5] 2.00-3.00 sec 1.12 MBytes 9.44 Mbits/sec [ 5] 3.00-4.00 sec 2.00 MBytes 16.8 Mbits/sec [ 5] 4.00-5.00 sec 2.38 MBytes 19.9 Mbits/sec [ 5] 5.00-6.00 sec 3.12 MBytes 26.2 Mbits/sec [ 5] 6.00-7.00 sec 4.75 MBytes 39.8 Mbits/sec [ 5] 7.00-8.00 sec 68.4 MBytes 574 Mbits/sec [ 5] 8.00-9.00 sec 104 MBytes 875 Mbits/sec [ 5] 9.00-10.00 sec 105 MBytes 881 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 292 MBytes 245 Mbits/sec sender [ 5] 0.00-10.04 sec 292 MBytes 244 Mbits/sec receiver iperf Done. root@odroidc2:~# iperf3 -c 10.10.11.100 -i1 Connecting to host 10.10.11.100, port 5201 [ 5] local 10.10.11.1 port 60022 connected to 10.10.11.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 0 417 KBytes [ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 487 KBytes [ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec 0 487 KBytes [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 512 KBytes [ 5] 4.00-5.01 sec 109 MBytes 907 Mbits/sec 0 543 KBytes [ 5] 5.01-6.01 sec 109 MBytes 911 Mbits/sec 0 543 KBytes [ 5] 6.01-7.01 sec 108 MBytes 902 Mbits/sec 0 543 KBytes [ 5] 7.01-8.01 sec 108 MBytes 905 Mbits/sec 0 543 KBytes [ 5] 8.01-9.00 sec 106 MBytes 895 Mbits/sec 0 543 KBytes [ 5] 9.00-10.00 sec 106 MBytes 891 Mbits/sec 0 543 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec 0 sender [ 5] 0.00-10.04 sec 1.07 GBytes 915 Mbits/sec receiver -- Mar 5 09:46:03 localhost kernel: [ 105.534204] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off iperf Done. root@odroidc2:~# regards, Simon Am 01.03.2019 um 10:23 schrieb Jose Abreu: > Hi Simon, > > On 2/27/2019 7:02 PM, Simon Huelck wrote: >> Hi, >> >> >> the thing is , that im not a stmmac developer. Yes , maybe i can bissect >> it and yes you are lucky since im a C-developer since a long time for >> embedded systems. >> >> The problem is that i dont understand the structure of stmmac and im not >> aware of any documentation about the driver structure nor the underlying >> ethernet hardware ( even though im used to ethernet hardware in embedded >> environment ). So how shall i recognize the relevant change between >> 4.14.29 and 5.0rc8 ? >> >> >> Is it in the DTS/DTB, wrong hardware description ? Is it in the code ? >> how is the duplex hardware working on this piece ? >> >> I can try to support you the best i can, but i have little chances to >> analyze it myself. At which measurements / counters is it possible to >> see that duplex is fully working ? Why did even the non-duplex >> bandwidth regress from 900MBits to 650 ? Why is that 650 MBits dividing >> up to TX and RX in summary when doing duplex ? Why is TX not starving in >> duplex but RX ? >> >> From my point of view should be the following things given: >> - the non duplex bandwidth should be somewhere around 900MBits , the HW >> is capable of that >> - TX should not influence RX or vice versa in duplex >> - the duplex bandwidth should be 900MBits in both directions ( maybe a >> bit asymetric when buffers in both dirs are not same ) >> >> I guess we need some profiling on stmmac and ( at least i need ) more >> knowledge of the hardware and stmmac itself. Can someone point me to the >> driver documentation, describing the functions in the code and the >> structure ? How can i profile stmmac ( usually im using hardware / JTAG >> debuggers at work, but here @home i got nothing like that ) >> >> So how do we continue ? > When I said bissect I was meaning GIT Bissect [1]. You shouldn't > need any development background for this. You just have to start > bissect, compile, test and check if commit is good or not. > > I'm not very familiar with this feature but I think you can > bissect pretty fast if you say you just want stmmac commits, > check ("Cutting down bisection by giving more parameters to > bisect start") on previous link ... In your case it would be > stmmac changes, dts, and phy. > > [1] https://git-scm.com/docs/git-bisect > > Thanks, > Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-03-05 9:55 ` Simon Huelck @ 2019-03-06 11:35 ` Simon Huelck 2019-03-06 11:45 ` Simon Huelck 0 siblings, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-03-06 11:35 UTC (permalink / raw) To: Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi, i sorted out some more things: - i did not activate tcp window scaling , with this , iperf3 is reaching 930MBits now, this was related to my firewall and therefore my uplink. so the remaining topic is ( and im currently testing with next-20190306 ) TX is starving RX and the total bandwith seem to be limited to 930MBits instead of something like 930MBits * 2 for duplex. @Jose, do you have some hints on that ? i saw that you introduced patches for that , but somehow RX/TX are not equally sharing the NAPI budget. But i wonder why the TX queue and RX queue collide at all, shouldnt they be indipendent ? regards, Simon > Hi guys, > > > 1. i discovered something strange. when i never configure my external > VLAN interface UP ( firewall doesnt start, traffic shaper CAKE doesnt > start), my non duplex iperf bandwidth increases from 600MBits to 930. > > 2. duplex isnt working, TX is totally starving RX, the total bandwidth > is 900MBits, whats going on there ? > > 3. i had a MTU issue ( was set to 1500, but due to VLANs etc 1450 would > be better ) but this didnt change performance > 4. even when i up eth0.4, then i down eth0.4, then flush iptables and > shaper were never added, i drop to 600MBits .... > > questions: > - why is duplex still not working even so the kernel says so ? > - why is TX totally starving RX, even so duplex is "on" > - when i flush all my iptable rules, and the traffic shaper, still im > bond to 600MBits ... very strange, someone got an idea ? upping eth0.4 > is cutting the performance, even when other VLAN IFs like eth0.3, > eth0.2, eth0.5 are up and bridged ( eth0.4 isnt bridged somewhere ) > > > > my setup: > > br-dmz 8000.7ef0fd9b157f no eth0.2 > br-guest 8000.001f1fbbbd60 no wlan0 > br-iot 8000.7ef0fd9b157f no eth0.5 > br-lan 8000.001f1fbbbd61 no eth0.3 > wlan0_1 > wlan2 > > eth0.4 is my uplink > > all the bridges are internally , eth0.4 is externally > > > C:\Users\Simon\Downloads\iperf3.6_64bit\iperf3.6_64bit>iperf3.exe -c > 10.10.11.1 -i1 > warning: Ignoring nonsense TCP MSS 0 > Connecting to host 10.10.11.1, port 5201 > [ 5] local 10.10.11.100 port 52173 connected to 10.10.11.1 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 384 KBytes 3.14 Mbits/sec > [ 5] 1.00-2.00 sec 384 KBytes 3.15 Mbits/sec > [ 5] 2.00-3.00 sec 1.12 MBytes 9.44 Mbits/sec > [ 5] 3.00-4.00 sec 2.00 MBytes 16.8 Mbits/sec > [ 5] 4.00-5.00 sec 2.38 MBytes 19.9 Mbits/sec > [ 5] 5.00-6.00 sec 3.12 MBytes 26.2 Mbits/sec > [ 5] 6.00-7.00 sec 4.75 MBytes 39.8 Mbits/sec > [ 5] 7.00-8.00 sec 68.4 MBytes 574 Mbits/sec > [ 5] 8.00-9.00 sec 104 MBytes 875 Mbits/sec > [ 5] 9.00-10.00 sec 105 MBytes 881 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate > [ 5] 0.00-10.00 sec 292 MBytes 245 Mbits/sec sender > [ 5] 0.00-10.04 sec 292 MBytes 244 Mbits/sec > receiver > > iperf Done. > > > root@odroidc2:~# iperf3 -c 10.10.11.100 -i1 > Connecting to host 10.10.11.100, port 5201 > [ 5] local 10.10.11.1 port 60022 connected to 10.10.11.100 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 0 417 KBytes > [ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 487 KBytes > [ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec 0 487 KBytes > [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 512 KBytes > [ 5] 4.00-5.01 sec 109 MBytes 907 Mbits/sec 0 543 KBytes > [ 5] 5.01-6.01 sec 109 MBytes 911 Mbits/sec 0 543 KBytes > [ 5] 6.01-7.01 sec 108 MBytes 902 Mbits/sec 0 543 KBytes > [ 5] 7.01-8.01 sec 108 MBytes 905 Mbits/sec 0 543 KBytes > [ 5] 8.01-9.00 sec 106 MBytes 895 Mbits/sec 0 543 KBytes > [ 5] 9.00-10.00 sec 106 MBytes 891 Mbits/sec 0 543 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec 0 sender > [ 5] 0.00-10.04 sec 1.07 GBytes 915 Mbits/sec > receiver > > -- > > > Mar 5 09:46:03 localhost kernel: [ 105.534204] meson8b-dwmac > c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off > > iperf Done. > root@odroidc2:~# > > > > > regards, > Simon > > Am 01.03.2019 um 10:23 schrieb Jose Abreu: >> Hi Simon, >> >> On 2/27/2019 7:02 PM, Simon Huelck wrote: >>> Hi, >>> >>> >>> the thing is , that im not a stmmac developer. Yes , maybe i can bissect >>> it and yes you are lucky since im a C-developer since a long time for >>> embedded systems. >>> >>> The problem is that i dont understand the structure of stmmac and im not >>> aware of any documentation about the driver structure nor the underlying >>> ethernet hardware ( even though im used to ethernet hardware in embedded >>> environment ). So how shall i recognize the relevant change between >>> 4.14.29 and 5.0rc8 ? >>> >>> >>> Is it in the DTS/DTB, wrong hardware description ? Is it in the code ? >>> how is the duplex hardware working on this piece ? >>> >>> I can try to support you the best i can, but i have little chances to >>> analyze it myself. At which measurements / counters is it possible to >>> see that duplex is fully working ? Why did even the non-duplex >>> bandwidth regress from 900MBits to 650 ? Why is that 650 MBits dividing >>> up to TX and RX in summary when doing duplex ? Why is TX not starving in >>> duplex but RX ? >>> >>> From my point of view should be the following things given: >>> - the non duplex bandwidth should be somewhere around 900MBits , the HW >>> is capable of that >>> - TX should not influence RX or vice versa in duplex >>> - the duplex bandwidth should be 900MBits in both directions ( maybe a >>> bit asymetric when buffers in both dirs are not same ) >>> >>> I guess we need some profiling on stmmac and ( at least i need ) more >>> knowledge of the hardware and stmmac itself. Can someone point me to the >>> driver documentation, describing the functions in the code and the >>> structure ? How can i profile stmmac ( usually im using hardware / JTAG >>> debuggers at work, but here @home i got nothing like that ) >>> >>> So how do we continue ? >> When I said bissect I was meaning GIT Bissect [1]. You shouldn't >> need any development background for this. You just have to start >> bissect, compile, test and check if commit is good or not. >> >> I'm not very familiar with this feature but I think you can >> bissect pretty fast if you say you just want stmmac commits, >> check ("Cutting down bisection by giving more parameters to >> bisect start") on previous link ... In your case it would be >> stmmac changes, dts, and phy. >> >> [1] https://git-scm.com/docs/git-bisect >> >> Thanks, >> Jose Miguel Abreu > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-03-06 11:35 ` Simon Huelck @ 2019-03-06 11:45 ` Simon Huelck 0 siblings, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-03-06 11:45 UTC (permalink / raw) To: Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi, RX is starving TX i guess ... so the other way around. a transfer was ongoing from 10.10.11.100 to 10.10.11.1 when i triggered this command on 10.10.11.1 root@odroidc2:~# iperf3 -c 10.10.11.100 -i1 Connecting to host 10.10.11.100, port 5201 [ 5] local 10.10.11.1 port 51652 connected to 10.10.11.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 371 KBytes 3.04 Mbits/sec 0 14.3 KBytes [ 5] 1.00-2.00 sec 331 KBytes 2.71 Mbits/sec 0 22.8 KBytes [ 5] 2.00-3.00 sec 314 KBytes 2.57 Mbits/sec 0 22.8 KBytes [ 5] 3.00-4.00 sec 314 KBytes 2.57 Mbits/sec 0 22.8 KBytes [ 5] 4.00-5.00 sec 314 KBytes 2.57 Mbits/sec 0 22.8 KBytes [ 5] 5.00-6.00 sec 314 KBytes 2.57 Mbits/sec 0 22.8 KBytes [ 5] 6.00-7.01 sec 48.0 MBytes 400 Mbits/sec 0 552 KBytes [ 5] 7.01-8.00 sec 106 MBytes 896 Mbits/sec 0 874 KBytes [ 5] 8.00-9.01 sec 110 MBytes 917 Mbits/sec 0 874 KBytes [ 5] 9.01-10.00 sec 98.8 MBytes 833 Mbits/sec 94 637 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 365 MBytes 306 Mbits/sec 94 sender [ 5] 0.00-10.02 sec 362 MBytes 304 Mbits/sec receiver -- root@odroidc2:~# ethtool -S eth0 NIC statistics: mmc_tx_octetcount_gb: 0 mmc_tx_framecount_gb: 0 mmc_tx_broadcastframe_g: 0 mmc_tx_multicastframe_g: 0 mmc_tx_64_octets_gb: 0 mmc_tx_65_to_127_octets_gb: 0 mmc_tx_128_to_255_octets_gb: 0 mmc_tx_256_to_511_octets_gb: 0 mmc_tx_512_to_1023_octets_gb: 0 mmc_tx_1024_to_max_octets_gb: 0 mmc_tx_unicast_gb: 0 mmc_tx_multicast_gb: 0 mmc_tx_broadcast_gb: 0 mmc_tx_underflow_error: 0 mmc_tx_singlecol_g: 0 mmc_tx_multicol_g: 0 mmc_tx_deferred: 0 mmc_tx_latecol: 0 mmc_tx_exesscol: 0 mmc_tx_carrier_error: 0 mmc_tx_octetcount_g: 0 mmc_tx_framecount_g: 0 mmc_tx_excessdef: 0 mmc_tx_pause_frame: 0 mmc_tx_vlan_frame_g: 0 mmc_rx_framecount_gb: 2039534 mmc_rx_octetcount_gb: 2808094903 mmc_rx_octetcount_g: 2808094903 mmc_rx_broadcastframe_g: 29673 mmc_rx_multicastframe_g: 67 mmc_rx_crc_error: 0 mmc_rx_align_error: 0 mmc_rx_run_error: 0 mmc_rx_jabber_error: 0 mmc_rx_undersize_g: 0 mmc_rx_oversize_g: 0 mmc_rx_64_octets_gb: 0 mmc_rx_65_to_127_octets_gb: 201563 mmc_rx_128_to_255_octets_gb: 656 mmc_rx_256_to_511_octets_gb: 1020 mmc_rx_512_to_1023_octets_gb: 448 mmc_rx_1024_to_max_octets_gb: 1835847 mmc_rx_unicast_g: 2009794 mmc_rx_length_error: 0 mmc_rx_autofrangetype: 0 mmc_rx_pause_frames: 0 mmc_rx_fifo_overflow: 315 mmc_rx_vlan_frames_gb: 2039517 mmc_rx_watchdog_error: 0 mmc_rx_ipc_intr_mask: 1073692671 mmc_rx_ipc_intr: 0 mmc_rx_ipv4_gd: 2010329 mmc_rx_ipv4_hderr: 0 mmc_rx_ipv4_nopay: 0 mmc_rx_ipv4_frag: 0 mmc_rx_ipv4_udsbl: 0 mmc_rx_ipv4_gd_octets: 2760880445 mmc_rx_ipv4_hderr_octets: 0 mmc_rx_ipv4_nopay_octets: 0 mmc_rx_ipv4_frag_octets: 0 mmc_rx_ipv4_udsbl_octets: 0 mmc_rx_ipv6_gd_octets: 10047 mmc_rx_ipv6_hderr_octets: 0 mmc_rx_ipv6_nopay_octets: 0 mmc_rx_ipv6_gd: 22 mmc_rx_ipv6_hderr: 0 mmc_rx_ipv6_nopay: 0 mmc_rx_udp_gd: 7642 mmc_rx_udp_err: 0 mmc_rx_tcp_gd: 2002692 mmc_rx_tcp_err: 0 mmc_rx_icmp_gd: 17 mmc_rx_icmp_err: 0 mmc_rx_udp_gd_octets: 666460 mmc_rx_udp_err_octets: 0 mmc_rx_tcp_gd_octets: 2720015720 mmc_rx_tcp_err_octets: 0 mmc_rx_icmp_gd_octets: 852 mmc_rx_icmp_err_octets: 0 tx_underflow: 0 tx_carrier: 0 tx_losscarrier: 0 vlan_tag: 2039202 tx_deferred: 0 tx_vlan: 1114175 tx_jabber: 0 tx_frame_flushed: 0 tx_payload_error: 0 tx_ip_header_error: 0 rx_desc: 0 sa_filter_fail: 0 overflow_error: 0 ipc_csum_error: 0 rx_collision: 0 rx_crc_errors: 0 dribbling_bit: 0 rx_length: 0 rx_mii: 0 rx_multicast: 0 rx_gmac_overflow: 0 rx_watchdog: 0 da_rx_filter_fail: 0 sa_rx_filter_fail: 0 rx_missed_cntr: 0 rx_overflow_cntr: 0 rx_vlan: 0 tx_undeflow_irq: 0 tx_process_stopped_irq: 0 tx_jabber_irq: 0 rx_overflow_irq: 0 rx_buf_unav_irq: 0 rx_process_stopped_irq: 0 rx_watchdog_irq: 0 tx_early_irq: 0 fatal_bus_error_irq: 0 rx_early_irq: 29321 threshold: 1 tx_pkt_n: 1114175 rx_pkt_n: 2039219 normal_irq_n: 167679 rx_normal_irq_n: 128772 napi_poll: 184569 tx_normal_irq_n: 42982 tx_clean: 55788 tx_set_ic_bit: 44567 irq_receive_pmt_irq_n: 0 mmc_tx_irq_n: 0 mmc_rx_irq_n: 0 mmc_rx_csum_offload_irq_n: 0 irq_tx_path_in_lpi_mode_n: 15749 irq_tx_path_exit_lpi_mode_n: 15748 irq_rx_path_in_lpi_mode_n: 0 irq_rx_path_exit_lpi_mode_n: 0 phy_eee_wakeup_error_n: 0 ip_hdr_err: 0 ip_payload_err: 0 ip_csum_bypassed: 0 ipv4_pkt_rcvd: 0 ipv6_pkt_rcvd: 0 no_ptp_rx_msg_type_ext: 0 ptp_rx_msg_type_sync: 0 ptp_rx_msg_type_follow_up: 0 ptp_rx_msg_type_delay_req: 0 ptp_rx_msg_type_delay_resp: 0 ptp_rx_msg_type_pdelay_req: 0 ptp_rx_msg_type_pdelay_resp: 0 ptp_rx_msg_type_pdelay_follow_up: 0 ptp_rx_msg_type_announce: 0 ptp_rx_msg_type_management: 0 ptp_rx_msg_pkt_reserved_type: 0 ptp_frame_type: 0 ptp_ver: 0 timestamp_dropped: 0 av_pkt_rcvd: 0 av_tagged_pkt_rcvd: 0 vlan_tag_priority_val: 0 l3_filter_match: 0 l4_filter_match: 0 l3_l4_filter_no_match: 0 irq_pcs_ane_n: 0 irq_pcs_link_n: 0 irq_rgmii_n: 0 mtl_tx_status_fifo_full: 0 mtl_tx_fifo_not_empty: 0 mmtl_fifo_ctrl: 0 mtl_tx_fifo_read_ctrl_write: 0 mtl_tx_fifo_read_ctrl_wait: 0 mtl_tx_fifo_read_ctrl_read: 0 mtl_tx_fifo_read_ctrl_idle: 0 mac_tx_in_pause: 0 mac_tx_frame_ctrl_xfer: 0 mac_tx_frame_ctrl_idle: 0 mac_tx_frame_ctrl_wait: 0 mac_tx_frame_ctrl_pause: 0 mac_gmii_tx_proto_engine: 0 mtl_rx_fifo_fill_level_full: 0 mtl_rx_fifo_fill_above_thresh: 0 mtl_rx_fifo_fill_below_thresh: 0 mtl_rx_fifo_fill_level_empty: 0 mtl_rx_fifo_read_ctrl_flush: 0 mtl_rx_fifo_read_ctrl_read_data: 0 mtl_rx_fifo_read_ctrl_status: 0 mtl_rx_fifo_read_ctrl_idle: 0 mtl_rx_fifo_ctrl_active: 0 mac_rx_frame_ctrl_fifo: 0 mac_gmii_rx_proto_engine: 0 tx_tso_frames: 0 tx_tso_nfrags: 0 regards, Simon Am 06.03.2019 um 12:35 schrieb Simon Huelck: > Hi, > > i sorted out some more things: > > - i did not activate tcp window scaling , with this , iperf3 is reaching > 930MBits now, this was related to my firewall and therefore my uplink. > > so the remaining topic is ( and im currently testing with next-20190306 ) > > TX is starving RX and the total bandwith seem to be limited to 930MBits > instead of something like 930MBits * 2 for duplex. > > @Jose, do you have some hints on that ? i saw that you introduced > patches for that , but somehow RX/TX are not equally sharing the NAPI > budget. But i wonder why the TX queue and RX queue collide at all, > shouldnt they be indipendent ? > > regards, > Simon >> Hi guys, >> >> >> 1. i discovered something strange. when i never configure my external >> VLAN interface UP ( firewall doesnt start, traffic shaper CAKE doesnt >> start), my non duplex iperf bandwidth increases from 600MBits to 930. >> >> 2. duplex isnt working, TX is totally starving RX, the total bandwidth >> is 900MBits, whats going on there ? >> >> 3. i had a MTU issue ( was set to 1500, but due to VLANs etc 1450 would >> be better ) but this didnt change performance >> 4. even when i up eth0.4, then i down eth0.4, then flush iptables and >> shaper were never added, i drop to 600MBits .... >> >> questions: >> - why is duplex still not working even so the kernel says so ? >> - why is TX totally starving RX, even so duplex is "on" >> - when i flush all my iptable rules, and the traffic shaper, still im >> bond to 600MBits ... very strange, someone got an idea ? upping eth0.4 >> is cutting the performance, even when other VLAN IFs like eth0.3, >> eth0.2, eth0.5 are up and bridged ( eth0.4 isnt bridged somewhere ) >> >> >> >> my setup: >> >> br-dmz 8000.7ef0fd9b157f no eth0.2 >> br-guest 8000.001f1fbbbd60 no wlan0 >> br-iot 8000.7ef0fd9b157f no eth0.5 >> br-lan 8000.001f1fbbbd61 no eth0.3 >> wlan0_1 >> wlan2 >> >> eth0.4 is my uplink >> >> all the bridges are internally , eth0.4 is externally >> >> >> C:\Users\Simon\Downloads\iperf3.6_64bit\iperf3.6_64bit>iperf3.exe -c >> 10.10.11.1 -i1 >> warning: Ignoring nonsense TCP MSS 0 >> Connecting to host 10.10.11.1, port 5201 >> [ 5] local 10.10.11.100 port 52173 connected to 10.10.11.1 port 5201 >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-1.00 sec 384 KBytes 3.14 Mbits/sec >> [ 5] 1.00-2.00 sec 384 KBytes 3.15 Mbits/sec >> [ 5] 2.00-3.00 sec 1.12 MBytes 9.44 Mbits/sec >> [ 5] 3.00-4.00 sec 2.00 MBytes 16.8 Mbits/sec >> [ 5] 4.00-5.00 sec 2.38 MBytes 19.9 Mbits/sec >> [ 5] 5.00-6.00 sec 3.12 MBytes 26.2 Mbits/sec >> [ 5] 6.00-7.00 sec 4.75 MBytes 39.8 Mbits/sec >> [ 5] 7.00-8.00 sec 68.4 MBytes 574 Mbits/sec >> [ 5] 8.00-9.00 sec 104 MBytes 875 Mbits/sec >> [ 5] 9.00-10.00 sec 105 MBytes 881 Mbits/sec >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-10.00 sec 292 MBytes 245 Mbits/sec sender >> [ 5] 0.00-10.04 sec 292 MBytes 244 Mbits/sec >> receiver >> >> iperf Done. >> >> >> root@odroidc2:~# iperf3 -c 10.10.11.100 -i1 >> Connecting to host 10.10.11.100, port 5201 >> [ 5] local 10.10.11.1 port 60022 connected to 10.10.11.100 port 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 0 417 KBytes >> [ 5] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 487 KBytes >> [ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec 0 487 KBytes >> [ 5] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 512 KBytes >> [ 5] 4.00-5.01 sec 109 MBytes 907 Mbits/sec 0 543 KBytes >> [ 5] 5.01-6.01 sec 109 MBytes 911 Mbits/sec 0 543 KBytes >> [ 5] 6.01-7.01 sec 108 MBytes 902 Mbits/sec 0 543 KBytes >> [ 5] 7.01-8.01 sec 108 MBytes 905 Mbits/sec 0 543 KBytes >> [ 5] 8.01-9.00 sec 106 MBytes 895 Mbits/sec 0 543 KBytes >> [ 5] 9.00-10.00 sec 106 MBytes 891 Mbits/sec 0 543 KBytes >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec 0 sender >> [ 5] 0.00-10.04 sec 1.07 GBytes 915 Mbits/sec >> receiver >> >> -- >> >> >> Mar 5 09:46:03 localhost kernel: [ 105.534204] meson8b-dwmac >> c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off >> >> iperf Done. >> root@odroidc2:~# >> >> >> >> >> regards, >> Simon >> >> Am 01.03.2019 um 10:23 schrieb Jose Abreu: >>> Hi Simon, >>> >>> On 2/27/2019 7:02 PM, Simon Huelck wrote: >>>> Hi, >>>> >>>> >>>> the thing is , that im not a stmmac developer. Yes , maybe i can bissect >>>> it and yes you are lucky since im a C-developer since a long time for >>>> embedded systems. >>>> >>>> The problem is that i dont understand the structure of stmmac and im not >>>> aware of any documentation about the driver structure nor the underlying >>>> ethernet hardware ( even though im used to ethernet hardware in embedded >>>> environment ). So how shall i recognize the relevant change between >>>> 4.14.29 and 5.0rc8 ? >>>> >>>> >>>> Is it in the DTS/DTB, wrong hardware description ? Is it in the code ? >>>> how is the duplex hardware working on this piece ? >>>> >>>> I can try to support you the best i can, but i have little chances to >>>> analyze it myself. At which measurements / counters is it possible to >>>> see that duplex is fully working ? Why did even the non-duplex >>>> bandwidth regress from 900MBits to 650 ? Why is that 650 MBits dividing >>>> up to TX and RX in summary when doing duplex ? Why is TX not starving in >>>> duplex but RX ? >>>> >>>> From my point of view should be the following things given: >>>> - the non duplex bandwidth should be somewhere around 900MBits , the HW >>>> is capable of that >>>> - TX should not influence RX or vice versa in duplex >>>> - the duplex bandwidth should be 900MBits in both directions ( maybe a >>>> bit asymetric when buffers in both dirs are not same ) >>>> >>>> I guess we need some profiling on stmmac and ( at least i need ) more >>>> knowledge of the hardware and stmmac itself. Can someone point me to the >>>> driver documentation, describing the functions in the code and the >>>> structure ? How can i profile stmmac ( usually im using hardware / JTAG >>>> debuggers at work, but here @home i got nothing like that ) >>>> >>>> So how do we continue ? >>> When I said bissect I was meaning GIT Bissect [1]. You shouldn't >>> need any development background for this. You just have to start >>> bissect, compile, test and check if commit is good or not. >>> >>> I'm not very familiar with this feature but I think you can >>> bissect pretty fast if you say you just want stmmac commits, >>> check ("Cutting down bisection by giving more parameters to >>> bisect start") on previous link ... In your case it would be >>> stmmac changes, dts, and phy. >>> >>> [1] https://git-scm.com/docs/git-bisect >>> >>> Thanks, >>> Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-03-01 9:23 ` Jose Abreu 2019-03-05 9:55 ` Simon Huelck @ 2019-05-11 14:53 ` Simon Huelck 2019-05-13 9:07 ` Jose Abreu 1 sibling, 1 reply; 48+ messages in thread From: Simon Huelck @ 2019-05-11 14:53 UTC (permalink / raw) To: Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi guys, on 5.1+ the story keeps being the same. 950 Mbits in each direction, but when in duplex RX is starving to ~70 MBits.. ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i didnt recognize before. Do we have new ideas / new direction to dig for ? regards, Simon Am 01.03.2019 um 10:23 schrieb Jose Abreu: > Hi Simon, > > On 2/27/2019 7:02 PM, Simon Huelck wrote: >> Hi, >> >> >> the thing is , that im not a stmmac developer. Yes , maybe i can bissect >> it and yes you are lucky since im a C-developer since a long time for >> embedded systems. >> >> The problem is that i dont understand the structure of stmmac and im not >> aware of any documentation about the driver structure nor the underlying >> ethernet hardware ( even though im used to ethernet hardware in embedded >> environment ). So how shall i recognize the relevant change between >> 4.14.29 and 5.0rc8 ? >> >> >> Is it in the DTS/DTB, wrong hardware description ? Is it in the code ? >> how is the duplex hardware working on this piece ? >> >> I can try to support you the best i can, but i have little chances to >> analyze it myself. At which measurements / counters is it possible to >> see that duplex is fully working ? Why did even the non-duplex >> bandwidth regress from 900MBits to 650 ? Why is that 650 MBits dividing >> up to TX and RX in summary when doing duplex ? Why is TX not starving in >> duplex but RX ? >> >> From my point of view should be the following things given: >> - the non duplex bandwidth should be somewhere around 900MBits , the HW >> is capable of that >> - TX should not influence RX or vice versa in duplex >> - the duplex bandwidth should be 900MBits in both directions ( maybe a >> bit asymetric when buffers in both dirs are not same ) >> >> I guess we need some profiling on stmmac and ( at least i need ) more >> knowledge of the hardware and stmmac itself. Can someone point me to the >> driver documentation, describing the functions in the code and the >> structure ? How can i profile stmmac ( usually im using hardware / JTAG >> debuggers at work, but here @home i got nothing like that ) >> >> So how do we continue ? > When I said bissect I was meaning GIT Bissect [1]. You shouldn't > need any development background for this. You just have to start > bissect, compile, test and check if commit is good or not. > > I'm not very familiar with this feature but I think you can > bissect pretty fast if you say you just want stmmac commits, > check ("Cutting down bisection by giving more parameters to > bisect start") on previous link ... In your case it would be > stmmac changes, dts, and phy. > > [1] https://git-scm.com/docs/git-bisect > > Thanks, > Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: stmmac / meson8b-dwmac 2019-05-11 14:53 ` Simon Huelck @ 2019-05-13 9:07 ` Jose Abreu 2019-05-22 12:48 ` Simon Huelck 2019-05-22 14:02 ` Neil Armstrong 0 siblings, 2 replies; 48+ messages in thread From: Jose Abreu @ 2019-05-13 9:07 UTC (permalink / raw) To: Simon Huelck, Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev From: Simon Huelck <simonmail@gmx.de> Date: Sat, May 11, 2019 at 15:53:34 > ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i didnt > recognize before. Flow Control can prevent this to happen. Please check if your DT FIFO bindings are >= 4096. > Do we have new ideas / new direction to dig for ? GIT Bisect is the best direction to follow. Thanks, Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-05-13 9:07 ` Jose Abreu @ 2019-05-22 12:48 ` Simon Huelck 2019-05-22 14:02 ` Neil Armstrong 1 sibling, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-05-22 12:48 UTC (permalink / raw) To: Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi, what exactly do you mean with this DT binding ? i cant find this for meson gxbb somewhere in the DTS ? regards, Simon Am 13.05.2019 um 11:07 schrieb Jose Abreu: > From: Simon Huelck <simonmail@gmx.de> > Date: Sat, May 11, 2019 at 15:53:34 > >> ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i didnt >> recognize before. > Flow Control can prevent this to happen. Please check if your DT FIFO > bindings are >= 4096. > >> Do we have new ideas / new direction to dig for ? > GIT Bisect is the best direction to follow. > > Thanks, > Jose Miguel Abreu ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-05-13 9:07 ` Jose Abreu 2019-05-22 12:48 ` Simon Huelck @ 2019-05-22 14:02 ` Neil Armstrong 1 sibling, 0 replies; 48+ messages in thread From: Neil Armstrong @ 2019-05-22 14:02 UTC (permalink / raw) To: Jose Abreu, Simon Huelck, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, netdev, alexandre.torgue, Emiliano Ingrassia, Gpeppe.cavallaro Hi Jose, On 13/05/2019 11:07, Jose Abreu wrote: > From: Simon Huelck <simonmail@gmx.de> > Date: Sat, May 11, 2019 at 15:53:34 > >> ethtool -S gave me some counts for mmc_rx_fifo_overflow, which i didnt >> recognize before. > > Flow Control can prevent this to happen. Please check if your DT FIFO > bindings are >= 4096. Actually our DT node minimalist : ethmac: ethernet@c9410000 { compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac-3.710", "snps,dwmac"; reg = <0x0 0xc9410000 0x0 0x10000 0x0 0xc8834540 0x0 0x4>; interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq"; }; (I removed pinctrl, clocks and reset) The dwmac bindings are quite complex, and we aren't sure how to describe correctly the HW. Could you point us on the right direction ? Thanks, Neil > >> Do we have new ideas / new direction to dig for ? > > GIT Bisect is the best direction to follow. > > Thanks, > Jose Miguel Abreu > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-27 11:09 ` Jose Abreu 2019-02-27 19:02 ` Simon Huelck @ 2019-02-27 21:03 ` Simon Huelck 1 sibling, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-02-27 21:03 UTC (permalink / raw) To: Jose Abreu, Sebastian Gottschall, Jerome Brunet, Martin Blumenstingl Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue, Emiliano Ingrassia, netdev Hi, i got another question about NAPI and irq assignment. my ethernet IRQ is assigned to CPU3: CPU0 CPU1 CPU2 CPU3 1: 0 0 0 0 GICv2 25 Level vgic 3: 7265279 3145278 4626601 2454147 GICv2 30 Level arch_timer 4: 0 0 0 0 GICv2 27 Level kvm guest vtimer 6: 0 0 0 0 GICv2 169 Level arm-pmu 7: 0 0 0 0 GICv2 170 Level arm-pmu 8: 0 0 0 0 GICv2 185 Level arm-pmu 9: 0 0 0 0 GICv2 186 Level arm-pmu 10: 0 0 0 0 GICv2 53 Edge c1108500.i2c 11: 3 0 0 0 GICv2 105 Edge c1108680.adc 13: 1229 0 0 0 GICv2 225 Edge ttyAML0 14: 334 0 0 0 GICv2 228 Edge c8100580.ir --> 18: 498 0 104034 19348144 GICv2 40 Level eth0 19: 4500 331407 0 0 GICv2 249 Edge d0072000.mmc 20: 13 0 0 0 GICv2 250 Edge d0074000.mmc 31: 0 0 0 0 GICv2 35 Edge meson 32: 0 0 0 0 GICv2 89 Edge dw_hdmi_top_irq, c883a000.hdmi-tx 34: 140014 0 2264814045 0 GICv2 63 Level c9100000.usb, dwc2_hsotg:usb1 IPI0: 3195735 3384376 2748050 4076544 Rescheduling interrupts IPI1: 1683557 683651 15136522 135 Function call interrupts IPI2: 0 0 0 0 CPU stop interrupts IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts IPI4: 0 0 0 0 Timer broadcast interrupts IPI5: 6 20 517 0 IRQ work interrupts IPI6: 0 0 0 0 CPU wake-up interrupts Err: 0 but when checking the softirqs i see that work is distributed over all CPUs, is this normal ? CPU0 CPU1 CPU2 CPU3 HI: 0 0 0 1 TIMER: 6513467 1258789 1058072 2181809 NET_TX: 574886 708816 1820739 140379 NET_RX: 1882454 920141 15537594 34834596 BLOCK: 3369 14936 3008 2389 IRQ_POLL: 0 0 0 0 TASKLET: 512404 626201 20054827 192419 SCHED: 5946453 1067624 777568 1916812 HRTIMER: 0 0 0 0 RCU: 1934215 719530 867003 876727 regards, Simon ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: stmmac / meson8b-dwmac 2019-02-18 16:43 ` Jose Abreu 2019-02-18 16:51 ` Simon Huelck @ 2019-02-18 17:05 ` Simon Huelck 1 sibling, 0 replies; 48+ messages in thread From: Simon Huelck @ 2019-02-18 17:05 UTC (permalink / raw) To: Jose Abreu, Martin Blumenstingl Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev [-- Attachment #1: Type: text/plain, Size: 2242 bytes --] Hi, here directly after reboot and a first iperf test C:\Users\Simon\Downloads\iperf-2.0.9-win64>iperf.exe -c 10.10.11.1 -i1 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 208 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 10.10.11.1, TCP port 5001 TCP window size: 208 KByte (default) ------------------------------------------------------------ [ 4] local 10.10.11.100 port 56062 connected with 10.10.11.1 port 5001 [ 5] local 10.10.11.100 port 5001 connected with 10.10.11.1 port 42552 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 16.2 MBytes 136 Mbits/sec [ 5] 0.0- 1.0 sec 70.5 MBytes 591 Mbits/sec [ 4] 1.0- 2.0 sec 14.4 MBytes 121 Mbits/sec [ 5] 1.0- 2.0 sec 63.9 MBytes 536 Mbits/sec [ 4] 2.0- 3.0 sec 13.4 MBytes 112 Mbits/sec [ 5] 2.0- 3.0 sec 67.6 MBytes 567 Mbits/sec [ 5] 3.0- 4.0 sec 68.6 MBytes 575 Mbits/sec [ 4] 3.0- 4.0 sec 15.9 MBytes 133 Mbits/sec [ 4] 4.0- 5.0 sec 13.9 MBytes 116 Mbits/sec [ 5] 4.0- 5.0 sec 65.2 MBytes 547 Mbits/sec [ 4] 5.0- 6.0 sec 16.8 MBytes 141 Mbits/sec [ 5] 5.0- 6.0 sec 67.1 MBytes 562 Mbits/sec [ 4] 6.0- 7.0 sec 17.2 MBytes 145 Mbits/sec [ 5] 6.0- 7.0 sec 65.7 MBytes 552 Mbits/sec [ 4] 7.0- 8.0 sec 16.0 MBytes 134 Mbits/sec [ 5] 7.0- 8.0 sec 67.0 MBytes 562 Mbits/sec [ 4] 8.0- 9.0 sec 15.6 MBytes 131 Mbits/sec [ 5] 8.0- 9.0 sec 66.5 MBytes 558 Mbits/sec [ 4] 9.0-10.0 sec 13.2 MBytes 111 Mbits/sec [ 4] 0.0-10.0 sec 153 MBytes 128 Mbits/sec [ 5] 9.0-10.0 sec 67.6 MBytes 567 Mbits/sec [ 5] 0.0-10.0 sec 670 MBytes 562 Mbits/sec regards, Simon Am 18.02.2019 um 17:43 schrieb Jose Abreu: > On 2/18/2019 4:40 PM, Simon Huelck wrote: >> Hi, >> >> EEE is enabled for odroid - c2 and should be working in 5.0-rc7 afaik ? > Oops, I was seeing in the wrong version, sorry. > > And did you test without that patch ? > > Thanks, > Jose Miguel Abreu [-- Attachment #2: ethtool.txt --] [-- Type: text/plain, Size: 5308 bytes --] NIC statistics: mmc_tx_octetcount_gb: 0 mmc_tx_framecount_gb: 0 mmc_tx_broadcastframe_g: 0 mmc_tx_multicastframe_g: 0 mmc_tx_64_octets_gb: 0 mmc_tx_65_to_127_octets_gb: 0 mmc_tx_128_to_255_octets_gb: 0 mmc_tx_256_to_511_octets_gb: 0 mmc_tx_512_to_1023_octets_gb: 0 mmc_tx_1024_to_max_octets_gb: 0 mmc_tx_unicast_gb: 0 mmc_tx_multicast_gb: 0 mmc_tx_broadcast_gb: 0 mmc_tx_underflow_error: 0 mmc_tx_singlecol_g: 0 mmc_tx_multicol_g: 0 mmc_tx_deferred: 0 mmc_tx_latecol: 0 mmc_tx_exesscol: 0 mmc_tx_carrier_error: 0 mmc_tx_octetcount_g: 0 mmc_tx_framecount_g: 0 mmc_tx_excessdef: 0 mmc_tx_pause_frame: 0 mmc_tx_vlan_frame_g: 0 mmc_rx_framecount_gb: 8658 mmc_rx_octetcount_gb: 2708759 mmc_rx_octetcount_g: 2708759 mmc_rx_broadcastframe_g: 4283 mmc_rx_multicastframe_g: 18 mmc_rx_crc_error: 0 mmc_rx_align_error: 0 mmc_rx_run_error: 0 mmc_rx_jabber_error: 0 mmc_rx_undersize_g: 0 mmc_rx_oversize_g: 0 mmc_rx_64_octets_gb: 0 mmc_rx_65_to_127_octets_gb: 5879 mmc_rx_128_to_255_octets_gb: 979 mmc_rx_256_to_511_octets_gb: 455 mmc_rx_512_to_1023_octets_gb: 125 mmc_rx_1024_to_max_octets_gb: 1220 mmc_rx_unicast_g: 4357 mmc_rx_length_error: 0 mmc_rx_autofrangetype: 0 mmc_rx_pause_frames: 0 mmc_rx_fifo_overflow: 0 mmc_rx_vlan_frames_gb: 8656 mmc_rx_watchdog_error: 0 mmc_rx_ipc_intr_mask: 2147385342 mmc_rx_ipc_intr: 0 mmc_rx_ipv4_gd: 4451 mmc_rx_ipv4_hderr: 0 mmc_rx_ipv4_nopay: 0 mmc_rx_ipv4_frag: 0 mmc_rx_ipv4_udsbl: 0 mmc_rx_ipv4_gd_octets: 2319576 mmc_rx_ipv4_hderr_octets: 0 mmc_rx_ipv4_nopay_octets: 0 mmc_rx_ipv4_frag_octets: 0 mmc_rx_ipv4_udsbl_octets: 0 mmc_rx_ipv6_gd_octets: 726 mmc_rx_ipv6_hderr_octets: 0 mmc_rx_ipv6_nopay_octets: 0 mmc_rx_ipv6_gd: 6 mmc_rx_ipv6_hderr: 0 mmc_rx_ipv6_nopay: 0 mmc_rx_udp_gd: 1542 mmc_rx_udp_err: 0 mmc_rx_tcp_gd: 2844 mmc_rx_tcp_err: 0 mmc_rx_icmp_gd: 71 mmc_rx_icmp_err: 0 mmc_rx_udp_gd_octets: 299070 mmc_rx_udp_err_octets: 0 mmc_rx_tcp_gd_octets: 1929132 mmc_rx_tcp_err_octets: 0 mmc_rx_icmp_gd_octets: 2840 mmc_rx_icmp_err_octets: 0 tx_underflow: 0 tx_carrier: 0 tx_losscarrier: 0 vlan_tag: 8656 tx_deferred: 0 tx_vlan: 4007 tx_jabber: 0 tx_frame_flushed: 0 tx_payload_error: 0 tx_ip_header_error: 0 rx_desc: 0 sa_filter_fail: 0 overflow_error: 0 ipc_csum_error: 0 rx_collision: 0 rx_crc_errors: 0 dribbling_bit: 0 rx_length: 0 rx_mii: 0 rx_multicast: 0 rx_gmac_overflow: 0 rx_watchdog: 0 da_rx_filter_fail: 0 sa_rx_filter_fail: 0 rx_missed_cntr: 0 rx_overflow_cntr: 0 rx_vlan: 0 tx_undeflow_irq: 0 tx_process_stopped_irq: 0 tx_jabber_irq: 0 rx_overflow_irq: 0 rx_buf_unav_irq: 0 rx_process_stopped_irq: 0 rx_watchdog_irq: 0 tx_early_irq: 0 fatal_bus_error_irq: 0 rx_early_irq: 30 threshold: 1 tx_pkt_n: 4007 rx_pkt_n: 8658 normal_irq_n: 7266 rx_normal_irq_n: 7106 napi_poll: 8677 tx_normal_irq_n: 159 tx_clean: 8677 tx_set_ic_bit: 160 irq_receive_pmt_irq_n: 0 mmc_tx_irq_n: 0 mmc_rx_irq_n: 0 mmc_rx_csum_offload_irq_n: 0 irq_tx_path_in_lpi_mode_n: 2421 irq_tx_path_exit_lpi_mode_n: 2420 irq_rx_path_in_lpi_mode_n: 0 irq_rx_path_exit_lpi_mode_n: 0 phy_eee_wakeup_error_n: 0 ip_hdr_err: 0 ip_payload_err: 0 ip_csum_bypassed: 0 ipv4_pkt_rcvd: 0 ipv6_pkt_rcvd: 0 no_ptp_rx_msg_type_ext: 0 ptp_rx_msg_type_sync: 0 ptp_rx_msg_type_follow_up: 0 ptp_rx_msg_type_delay_req: 0 ptp_rx_msg_type_delay_resp: 0 ptp_rx_msg_type_pdelay_req: 0 ptp_rx_msg_type_pdelay_resp: 0 ptp_rx_msg_type_pdelay_follow_up: 0 ptp_rx_msg_type_announce: 0 ptp_rx_msg_type_management: 0 ptp_rx_msg_pkt_reserved_type: 0 ptp_frame_type: 0 ptp_ver: 0 timestamp_dropped: 0 av_pkt_rcvd: 0 av_tagged_pkt_rcvd: 0 vlan_tag_priority_val: 0 l3_filter_match: 0 l4_filter_match: 0 l3_l4_filter_no_match: 0 irq_pcs_ane_n: 0 irq_pcs_link_n: 0 irq_rgmii_n: 0 mtl_tx_status_fifo_full: 0 mtl_tx_fifo_not_empty: 0 mmtl_fifo_ctrl: 0 mtl_tx_fifo_read_ctrl_write: 0 mtl_tx_fifo_read_ctrl_wait: 0 mtl_tx_fifo_read_ctrl_read: 0 mtl_tx_fifo_read_ctrl_idle: 0 mac_tx_in_pause: 0 mac_tx_frame_ctrl_xfer: 0 mac_tx_frame_ctrl_idle: 0 mac_tx_frame_ctrl_wait: 0 mac_tx_frame_ctrl_pause: 0 mac_gmii_tx_proto_engine: 0 mtl_rx_fifo_fill_level_full: 0 mtl_rx_fifo_fill_above_thresh: 0 mtl_rx_fifo_fill_below_thresh: 0 mtl_rx_fifo_fill_level_empty: 0 mtl_rx_fifo_read_ctrl_flush: 0 mtl_rx_fifo_read_ctrl_read_data: 0 mtl_rx_fifo_read_ctrl_status: 0 mtl_rx_fifo_read_ctrl_idle: 0 mtl_rx_fifo_ctrl_active: 0 mac_rx_frame_ctrl_fifo: 0 mac_gmii_rx_proto_engine: 0 tx_tso_frames: 0 tx_tso_nfrags: 0 [-- Attachment #3: kern.log --] [-- Type: text/plain, Size: 40656 bytes --] Feb 18 17:59:55 localhost kernel: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] Feb 18 17:59:55 localhost kernel: [ 0.000000] Linux version 5.0.0-rc7+ (root@odroidc2) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Mon Feb 18 08:12:57 CET 2019 Feb 18 17:59:55 localhost kernel: [ 0.000000] Machine model: Hardkernel ODROID-C2 Feb 18 17:59:55 localhost kernel: [ 0.000000] Reserved memory: created CMA memory pool at 0x0000000068000000, size 256 MiB Feb 18 17:59:55 localhost kernel: [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool Feb 18 17:59:55 localhost kernel: [ 0.000000] On node 0 totalpages: 486144 Feb 18 17:59:55 localhost kernel: [ 0.000000] DMA32 zone: 7616 pages used for memmap Feb 18 17:59:55 localhost kernel: [ 0.000000] DMA32 zone: 0 pages reserved Feb 18 17:59:55 localhost kernel: [ 0.000000] DMA32 zone: 486144 pages, LIFO batch:63 Feb 18 17:59:55 localhost kernel: [ 0.000000] psci: probing for conduit method from DT. Feb 18 17:59:55 localhost kernel: [ 0.000000] psci: PSCIv0.2 detected in firmware. Feb 18 17:59:55 localhost kernel: [ 0.000000] psci: Using standard PSCI v0.2 function IDs Feb 18 17:59:55 localhost kernel: [ 0.000000] psci: Trusted OS migration not required Feb 18 17:59:55 localhost kernel: [ 0.000000] random: get_random_bytes called from start_kernel+0xa4/0x448 with crng_init=0 Feb 18 17:59:55 localhost kernel: [ 0.000000] percpu: Embedded 23 pages/cpu @(____ptrval____) s53528 r8192 d32488 u94208 Feb 18 17:59:55 localhost kernel: [ 0.000000] pcpu-alloc: s53528 r8192 d32488 u94208 alloc=23*4096 Feb 18 17:59:55 localhost kernel: [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Feb 18 17:59:55 localhost kernel: [ 0.000000] Detected VIPT I-cache on CPU0 Feb 18 17:59:55 localhost kernel: [ 0.000000] CPU features: detected: ARM erratum 843419 Feb 18 17:59:55 localhost kernel: [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 478528 Feb 18 17:59:55 localhost kernel: [ 0.000000] Kernel command line: console=ttyAML0,115200 root=/dev/mmcblk1p2 rootwait rootflags=data=writeback rw slub_debug=P page_poison=1 slab_nomerge Feb 18 17:59:55 localhost kernel: [ 0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Feb 18 17:59:55 localhost kernel: [ 0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Feb 18 17:59:55 localhost kernel: [ 0.000000] Memory: 1626632K/1944576K available (9150K kernel code, 650K rwdata, 2288K rodata, 448K init, 1101K bss, 55800K reserved, 262144K cma-reserved) Feb 18 17:59:55 localhost kernel: [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Feb 18 17:59:55 localhost kernel: [ 0.000000] rcu: Hierarchical RCU implementation. Feb 18 17:59:55 localhost kernel: [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. Feb 18 17:59:55 localhost kernel: [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 Feb 18 17:59:55 localhost kernel: [ 0.000000] GIC: Using split EOI/Deactivate mode Feb 18 17:59:55 localhost kernel: [ 0.000000] irq_meson_gpio: 133 to 8 gpio interrupt mux initialized Feb 18 17:59:55 localhost kernel: [ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys). Feb 18 17:59:55 localhost kernel: [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns Feb 18 17:59:55 localhost kernel: [ 0.000002] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns Feb 18 17:59:55 localhost kernel: [ 0.000225] Console: colour dummy device 80x25 Feb 18 17:59:55 localhost kernel: [ 0.000252] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000) Feb 18 17:59:55 localhost kernel: [ 0.000258] pid_max: default: 32768 minimum: 301 Feb 18 17:59:55 localhost kernel: [ 0.000388] LSM: Security Framework initializing Feb 18 17:59:55 localhost kernel: [ 0.000517] AppArmor: AppArmor initialized Feb 18 17:59:55 localhost kernel: [ 0.000571] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) Feb 18 17:59:55 localhost kernel: [ 0.000577] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes) Feb 18 17:59:55 localhost kernel: [ 0.001752] ASID allocator initialised with 65536 entries Feb 18 17:59:55 localhost kernel: [ 0.001810] rcu: Hierarchical SRCU implementation. Feb 18 17:59:55 localhost kernel: [ 0.002265] smp: Bringing up secondary CPUs ... Feb 18 17:59:55 localhost kernel: [ 0.003167] Detected VIPT I-cache on CPU1 Feb 18 17:59:55 localhost kernel: [ 0.003211] CPU1: Booted secondary processor 0x0000000001 [0x410fd034] Feb 18 17:59:55 localhost kernel: [ 0.004117] Detected VIPT I-cache on CPU2 Feb 18 17:59:55 localhost kernel: [ 0.004138] CPU2: Booted secondary processor 0x0000000002 [0x410fd034] Feb 18 17:59:55 localhost kernel: [ 0.005029] Detected VIPT I-cache on CPU3 Feb 18 17:59:55 localhost kernel: [ 0.005046] CPU3: Booted secondary processor 0x0000000003 [0x410fd034] Feb 18 17:59:55 localhost kernel: [ 0.005088] smp: Brought up 1 node, 4 CPUs Feb 18 17:59:55 localhost kernel: [ 0.005098] SMP: Total of 4 processors activated. Feb 18 17:59:55 localhost kernel: [ 0.005103] CPU features: detected: 32-bit EL0 Support Feb 18 17:59:55 localhost kernel: [ 0.005107] CPU features: detected: CRC32 instructions Feb 18 17:59:55 localhost kernel: [ 0.005229] CPU: All CPU(s) started at EL2 Feb 18 17:59:55 localhost kernel: [ 0.005243] alternatives: patching kernel code Feb 18 17:59:55 localhost kernel: [ 0.006001] devtmpfs: initialized Feb 18 17:59:55 localhost kernel: [ 0.011301] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns Feb 18 17:59:55 localhost kernel: [ 0.011319] futex hash table entries: 1024 (order: 4, 65536 bytes) Feb 18 17:59:55 localhost kernel: [ 0.089843] xor: measuring software checksum speed Feb 18 17:59:55 localhost kernel: [ 0.128142] 8regs : 2947.000 MB/sec Feb 18 17:59:55 localhost kernel: [ 0.168165] 32regs : 3491.000 MB/sec Feb 18 17:59:55 localhost kernel: [ 0.208189] arm64_neon: 3199.000 MB/sec Feb 18 17:59:55 localhost kernel: [ 0.208192] xor: using function: 32regs (3491.000 MB/sec) Feb 18 17:59:55 localhost kernel: [ 0.208203] pinctrl core: initialized pinctrl subsystem Feb 18 17:59:55 localhost kernel: [ 0.209116] NET: Registered protocol family 16 Feb 18 17:59:55 localhost kernel: [ 0.209429] audit: initializing netlink subsys (disabled) Feb 18 17:59:55 localhost kernel: [ 0.209579] audit: type=2000 audit(0.208:1): state=initialized audit_enabled=0 res=1 Feb 18 17:59:55 localhost kernel: [ 0.210098] vdso: 2 pages (1 code @ (____ptrval____), 1 data @ (____ptrval____)) Feb 18 17:59:55 localhost kernel: [ 0.210105] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. Feb 18 17:59:55 localhost kernel: [ 0.212710] DMA: preallocated 256 KiB pool for atomic allocations Feb 18 17:59:55 localhost kernel: [ 0.212754] Serial: AMBA PL011 UART driver Feb 18 17:59:55 localhost kernel: [ 0.221756] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages Feb 18 17:59:55 localhost kernel: [ 0.221765] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages Feb 18 17:59:55 localhost kernel: [ 0.221768] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages Feb 18 17:59:55 localhost kernel: [ 0.221772] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages Feb 18 17:59:55 localhost kernel: [ 0.288287] raid6: neonx8 gen() 2048 MB/s Feb 18 17:59:55 localhost kernel: [ 0.356332] raid6: neonx8 xor() 1940 MB/s Feb 18 17:59:55 localhost kernel: [ 0.424411] raid6: neonx4 gen() 1940 MB/s Feb 18 17:59:55 localhost kernel: [ 0.492446] raid6: neonx4 xor() 1862 MB/s Feb 18 17:59:55 localhost kernel: [ 0.560488] raid6: neonx2 gen() 1495 MB/s Feb 18 17:59:55 localhost kernel: [ 0.628536] raid6: neonx2 xor() 1559 MB/s Feb 18 17:59:55 localhost kernel: [ 0.696599] raid6: neonx1 gen() 933 MB/s Feb 18 17:59:55 localhost kernel: [ 0.764656] raid6: neonx1 xor() 1104 MB/s Feb 18 17:59:55 localhost kernel: [ 0.832726] raid6: int64x8 gen() 1414 MB/s Feb 18 17:59:55 localhost kernel: [ 0.900767] raid6: int64x8 xor() 937 MB/s Feb 18 17:59:55 localhost kernel: [ 0.968808] raid6: int64x4 gen() 1268 MB/s Feb 18 17:59:55 localhost kernel: [ 1.036851] raid6: int64x4 xor() 976 MB/s Feb 18 17:59:55 localhost kernel: [ 1.104910] raid6: int64x2 gen() 844 MB/s Feb 18 17:59:55 localhost kernel: [ 1.172990] raid6: int64x2 xor() 769 MB/s Feb 18 17:59:55 localhost kernel: [ 1.241028] raid6: int64x1 gen() 531 MB/s Feb 18 17:59:55 localhost kernel: [ 1.309084] raid6: int64x1 xor() 574 MB/s Feb 18 17:59:55 localhost kernel: [ 1.309088] raid6: using algorithm neonx8 gen() 2048 MB/s Feb 18 17:59:55 localhost kernel: [ 1.309090] raid6: .... xor() 1940 MB/s, rmw enabled Feb 18 17:59:55 localhost kernel: [ 1.309094] raid6: using neon recovery algorithm Feb 18 17:59:55 localhost kernel: [ 1.310489] SCSI subsystem initialized Feb 18 17:59:55 localhost kernel: [ 1.310673] libata version 3.00 loaded. Feb 18 17:59:55 localhost kernel: [ 1.310819] usbcore: registered new interface driver usbfs Feb 18 17:59:55 localhost kernel: [ 1.310850] usbcore: registered new interface driver hub Feb 18 17:59:55 localhost kernel: [ 1.310891] usbcore: registered new device driver usb Feb 18 17:59:55 localhost kernel: [ 1.310978] pps_core: LinuxPPS API ver. 1 registered Feb 18 17:59:55 localhost kernel: [ 1.310981] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> Feb 18 17:59:55 localhost kernel: [ 1.310993] PTP clock support registered Feb 18 17:59:55 localhost kernel: [ 1.311367] Advanced Linux Sound Architecture Driver Initialized. Feb 18 17:59:55 localhost kernel: [ 1.311743] NetLabel: Initializing Feb 18 17:59:55 localhost kernel: [ 1.311746] NetLabel: domain hash size = 128 Feb 18 17:59:55 localhost kernel: [ 1.311749] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO Feb 18 17:59:55 localhost kernel: [ 1.311823] NetLabel: unlabeled traffic allowed by default Feb 18 17:59:55 localhost kernel: [ 1.312093] clocksource: Switched to clocksource arch_sys_counter Feb 18 17:59:55 localhost kernel: [ 1.312217] VFS: Disk quotas dquot_6.6.0 Feb 18 17:59:55 localhost kernel: [ 1.312267] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) Feb 18 17:59:55 localhost kernel: [ 1.312352] FS-Cache: Loaded Feb 18 17:59:55 localhost kernel: [ 1.312561] CacheFiles: Loaded Feb 18 17:59:55 localhost kernel: [ 1.312894] AppArmor: AppArmor Filesystem Enabled Feb 18 17:59:55 localhost kernel: [ 1.317960] NET: Registered protocol family 2 Feb 18 17:59:55 localhost kernel: [ 1.318447] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes) Feb 18 17:59:55 localhost kernel: [ 1.318480] TCP established hash table entries: 16384 (order: 5, 131072 bytes) Feb 18 17:59:55 localhost kernel: [ 1.318565] TCP bind hash table entries: 16384 (order: 6, 262144 bytes) Feb 18 17:59:55 localhost kernel: [ 1.318736] TCP: Hash tables configured (established 16384 bind 16384) Feb 18 17:59:55 localhost kernel: [ 1.318820] UDP hash table entries: 1024 (order: 3, 32768 bytes) Feb 18 17:59:55 localhost kernel: [ 1.318858] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes) Feb 18 17:59:55 localhost kernel: [ 1.319026] NET: Registered protocol family 1 Feb 18 17:59:55 localhost kernel: [ 1.319757] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available Feb 18 17:59:55 localhost kernel: [ 1.319953] kvm [1]: 8-bit VMID Feb 18 17:59:55 localhost kernel: [ 1.319957] kvm [1]: IPA Size Limit: 40bits Feb 18 17:59:55 localhost kernel: [ 1.320247] kvm [1]: vgic interrupt IRQ1 Feb 18 17:59:55 localhost kernel: [ 1.320327] kvm [1]: Hyp mode initialized successfully Feb 18 17:59:55 localhost kernel: [ 1.321264] Initialise system trusted keyrings Feb 18 17:59:55 localhost kernel: [ 1.321421] workingset: timestamp_bits=46 max_order=19 bucket_order=0 Feb 18 17:59:55 localhost kernel: [ 1.334597] Key type asymmetric registered Feb 18 17:59:55 localhost kernel: [ 1.334608] Asymmetric key parser 'x509' registered Feb 18 17:59:55 localhost kernel: [ 1.334665] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) Feb 18 17:59:55 localhost kernel: [ 1.334765] io scheduler mq-deadline registered Feb 18 17:59:55 localhost kernel: [ 1.334770] io scheduler kyber registered Feb 18 17:59:55 localhost kernel: [ 1.335983] GPIO line 501 (usb-hub-reset) hogged as output/high Feb 18 17:59:55 localhost kernel: [ 1.344176] meson_vid_pll_div_recalc_rate: Invalid config value for vid_pll_div Feb 18 17:59:55 localhost kernel: [ 1.346163] soc soc0: Amlogic Meson GXBB (S905) Revision 1f:c (0:1) Detected Feb 18 17:59:55 localhost kernel: [ 1.347227] c81004c0.serial: ttyAML0 at MMIO 0xc81004c0 (irq = 13, base_baud = 1500000) is a meson_uart Feb 18 17:59:55 localhost kernel: [ 2.072721] printk: console [ttyAML0] enabled Feb 18 17:59:55 localhost kernel: [ 2.084406] loop: module loaded Feb 18 17:59:55 localhost kernel: [ 2.084757] zram: Added device: zram0 Feb 18 17:59:55 localhost kernel: [ 2.086038] mtdoops: mtd device (mtddev=name/number) must be supplied Feb 18 17:59:55 localhost kernel: [ 2.092259] libphy: Fixed MDIO Bus: probed Feb 18 17:59:55 localhost kernel: [ 2.096044] tun: Universal TUN/TAP device driver, 1.6 Feb 18 17:59:55 localhost kernel: [ 2.101735] meson8b-dwmac c9410000.ethernet: PTP uses main clock Feb 18 17:59:55 localhost kernel: [ 2.106950] meson8b-dwmac c9410000.ethernet: no reset control found Feb 18 17:59:55 localhost kernel: [ 2.113570] meson8b-dwmac c9410000.ethernet: User ID: 0x11, Synopsys ID: 0x37 Feb 18 17:59:55 localhost kernel: [ 2.120230] meson8b-dwmac c9410000.ethernet: DWMAC1000 Feb 18 17:59:55 localhost kernel: [ 2.125399] meson8b-dwmac c9410000.ethernet: DMA HW capability register supported Feb 18 17:59:55 localhost kernel: [ 2.132816] meson8b-dwmac c9410000.ethernet: RX Checksum Offload Engine supported Feb 18 17:59:55 localhost kernel: [ 2.140233] meson8b-dwmac c9410000.ethernet: COE Type 2 Feb 18 17:59:55 localhost kernel: [ 2.145407] meson8b-dwmac c9410000.ethernet: TX Checksum insertion supported Feb 18 17:59:55 localhost kernel: [ 2.152393] meson8b-dwmac c9410000.ethernet: Wake-Up On Lan supported Feb 18 17:59:55 localhost kernel: [ 2.158803] meson8b-dwmac c9410000.ethernet: Normal descriptors Feb 18 17:59:55 localhost kernel: [ 2.164643] meson8b-dwmac c9410000.ethernet: Ring mode enabled Feb 18 17:59:55 localhost kernel: [ 2.170420] meson8b-dwmac c9410000.ethernet: Enable RX Mitigation via HW Watchdog Timer Feb 18 17:59:55 localhost kernel: [ 3.232112] libphy: stmmac: probed Feb 18 17:59:55 localhost kernel: [ 3.233745] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver Feb 18 17:59:55 localhost kernel: [ 3.236357] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver Feb 18 17:59:55 localhost kernel: [ 3.242541] usbcore: registered new interface driver usb-storage Feb 18 17:59:55 localhost kernel: [ 3.248496] usbcore: registered new interface driver usbserial_generic Feb 18 17:59:55 localhost kernel: [ 3.254910] usbserial: USB Serial support registered for generic Feb 18 17:59:55 localhost kernel: [ 3.261063] mousedev: PS/2 mouse device common for all mice Feb 18 17:59:55 localhost kernel: [ 3.266534] i2c /dev entries driver Feb 18 17:59:55 localhost kernel: [ 3.270421] IR Sharp protocol handler initialized Feb 18 17:59:55 localhost kernel: [ 3.274478] IR XMP protocol handler initialized Feb 18 17:59:55 localhost kernel: [ 3.279101] Registered IR keymap rc-empty Feb 18 17:59:55 localhost kernel: [ 3.282971] rc rc0: meson-ir as /devices/platform/soc/c8100000.bus/c8100580.ir/rc/rc0 Feb 18 17:59:55 localhost kernel: [ 3.290928] input: meson-ir as /devices/platform/soc/c8100000.bus/c8100580.ir/rc/rc0/input0 Feb 18 17:59:55 localhost kernel: [ 3.299261] meson-ir c8100580.ir: receiver initialized Feb 18 17:59:55 localhost kernel: [ 3.304627] softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0) Feb 18 17:59:55 localhost kernel: [ 3.313299] meson-gx-mmc d0074000.mmc: Linked as a consumer to regulator.2 Feb 18 17:59:55 localhost kernel: [ 3.319313] meson-gx-mmc d0074000.mmc: Linked as a consumer to regulator.1 Feb 18 17:59:55 localhost kernel: [ 3.326098] meson-gx-mmc d0074000.mmc: allocated mmc-pwrseq Feb 18 17:59:55 localhost kernel: [ 3.359962] ledtrig-cpu: registered to indicate activity on CPUs Feb 18 17:59:55 localhost kernel: [ 3.360601] meson-sm: secure-monitor enabled Feb 18 17:59:55 localhost kernel: [ 3.364975] usbcore: registered new interface driver usbhid Feb 18 17:59:55 localhost kernel: [ 3.370147] usbhid: USB HID core driver Feb 18 17:59:55 localhost kernel: [ 3.374156] meson-saradc c1108680.adc: Linked as a consumer to regulator.1 Feb 18 17:59:55 localhost kernel: [ 3.382191] GACT probability on Feb 18 17:59:55 localhost kernel: [ 3.383832] Mirror/redirect action on Feb 18 17:59:55 localhost kernel: [ 3.387490] u32 classifier Feb 18 17:59:55 localhost kernel: [ 3.390080] Performance counters on Feb 18 17:59:55 localhost kernel: [ 3.393874] input device check on Feb 18 17:59:55 localhost kernel: [ 3.397497] Actions configured Feb 18 17:59:55 localhost kernel: [ 3.401466] NET: Registered protocol family 10 Feb 18 17:59:55 localhost kernel: [ 3.406328] Segment Routing with IPv6 Feb 18 17:59:55 localhost kernel: [ 3.409106] mip6: Mobile IPv6 Feb 18 17:59:55 localhost kernel: [ 3.411812] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver Feb 18 17:59:55 localhost kernel: [ 3.418438] NET: Registered protocol family 17 Feb 18 17:59:55 localhost kernel: [ 3.422102] NET: Registered protocol family 15 Feb 18 17:59:55 localhost kernel: [ 3.426581] Bridge firewalling registered Feb 18 17:59:55 localhost kernel: [ 3.430472] NET: Registered protocol family 35 Feb 18 17:59:55 localhost kernel: [ 3.434996] 8021q: 802.1Q VLAN Support v1.8 Feb 18 17:59:55 localhost kernel: [ 3.439022] Key type dns_resolver registered Feb 18 17:59:55 localhost kernel: [ 3.443790] registered taskstats version 1 Feb 18 17:59:55 localhost kernel: [ 3.447358] Loading compiled-in X.509 certificates Feb 18 17:59:55 localhost kernel: [ 3.453507] Btrfs loaded, crc32c=crc32c-generic Feb 18 17:59:55 localhost kernel: [ 3.456633] AppArmor: AppArmor sha1 policy hashing enabled Feb 18 17:59:55 localhost kernel: [ 3.472209] phy phy-c0000000.phy.0: Linked as a consumer to regulator.3 Feb 18 17:59:55 localhost kernel: [ 3.473381] phy phy-c0000020.phy.1: Linked as a consumer to regulator.3 Feb 18 17:59:55 localhost kernel: [ 3.480055] meson-drm d0100000.vpu: Queued 2 outputs on vpu Feb 18 17:59:55 localhost kernel: [ 3.485552] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Feb 18 17:59:55 localhost kernel: [ 3.491890] [drm] No driver support for vblank timestamp query. Feb 18 17:59:55 localhost kernel: [ 3.497756] meson-drm d0100000.vpu: CVBS Output connector not available Feb 18 17:59:55 localhost kernel: [ 3.532127] meson-dw-hdmi c883a000.hdmi-tx: Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy) Feb 18 17:59:55 localhost kernel: [ 3.536619] meson-dw-hdmi c883a000.hdmi-tx: registered DesignWare HDMI I2C bus driver Feb 18 17:59:55 localhost kernel: [ 3.544287] meson-drm d0100000.vpu: bound c883a000.hdmi-tx (ops 0xffffff8010a01668) Feb 18 17:59:55 localhost kernel: [ 3.551959] [drm] Initialized meson 1.0.0 20161109 for d0100000.vpu on minor 0 Feb 18 17:59:55 localhost kernel: [ 3.558843] [drm] Cannot find any crtc or sizes Feb 18 17:59:55 localhost kernel: [ 3.563526] dwc2 c9000000.usb: c9000000.usb supply vusb_d not found, using dummy regulator Feb 18 17:59:55 localhost kernel: [ 3.571514] dwc2 c9000000.usb: Linked as a consumer to regulator.0 Feb 18 17:59:55 localhost kernel: [ 3.577601] dwc2 c9000000.usb: c9000000.usb supply vusb_a not found, using dummy regulator Feb 18 17:59:55 localhost kernel: [ 3.585910] [drm] Cannot find any crtc or sizes Feb 18 17:59:55 localhost kernel: [ 3.591361] phy phy-c0000000.phy.0: USB ID detect failed! Feb 18 17:59:55 localhost kernel: [ 3.595629] phy phy-c0000000.phy.0: phy poweron failed --> -22 Feb 18 17:59:55 localhost kernel: [ 3.601446] WARNING: CPU: 0 PID: 32 at _regulator_put.part.12+0x118/0x120 Feb 18 17:59:55 localhost kernel: [ 3.608125] Modules linked in: Feb 18 17:59:55 localhost kernel: [ 3.611146] CPU: 0 PID: 32 Comm: kworker/0:1 Not tainted 5.0.0-rc7+ #1 Feb 18 17:59:55 localhost kernel: [ 3.617612] Hardware name: Hardkernel ODROID-C2 (DT) Feb 18 17:59:55 localhost kernel: [ 3.622536] Workqueue: events deferred_probe_work_func Feb 18 17:59:55 localhost kernel: [ 3.627618] pstate: 80000005 (Nzcv daif -PAN -UAO) Feb 18 17:59:55 localhost kernel: [ 3.632362] pc : _regulator_put.part.12+0x118/0x120 Feb 18 17:59:55 localhost kernel: [ 3.637192] lr : regulator_put+0x34/0x50 Feb 18 17:59:55 localhost kernel: [ 3.641072] sp : ffffff8010eaba90 Feb 18 17:59:55 localhost kernel: [ 3.644349] x29: ffffff8010eaba90 x28: ffffffc064ce7328 Feb 18 17:59:55 localhost kernel: [ 3.649610] x27: ffffffc064ce7328 x26: ffffff80105c6248 Feb 18 17:59:55 localhost kernel: [ 3.654872] x25: ffffff80105c6250 x24: 0000000000000009 Feb 18 17:59:55 localhost kernel: [ 3.660133] x23: ffffffc064ce7090 x22: ffffff8010eabb88 Feb 18 17:59:55 localhost kernel: [ 3.665394] x21: 0000000000000000 x20: ffffffc06400a900 Feb 18 17:59:55 localhost kernel: [ 3.670655] x19: ffffffc06400a900 x18: ffffffffffffffff Feb 18 17:59:55 localhost kernel: [ 3.675917] x17: 000000008b9b3fdd x16: 00000000e39dafd8 Feb 18 17:59:55 localhost kernel: [ 3.681178] x15: ffffff8010c3c648 x14: ffffff8090eab787 Feb 18 17:59:55 localhost kernel: [ 3.686439] x13: ff00000000000000 x12: ffffffffffffffff Feb 18 17:59:55 localhost kernel: [ 3.691700] x11: 0000000000000038 x10: 0000000000000006 Feb 18 17:59:55 localhost kernel: [ 3.696961] x9 : 0000000000000040 x8 : ffffffc06400bbff Feb 18 17:59:55 localhost kernel: [ 3.702223] x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000000 Feb 18 17:59:55 localhost kernel: [ 3.707484] x5 : 0000000000000000 x4 : 0000000000000000 Feb 18 17:59:55 localhost kernel: [ 3.712745] x3 : 0000000000000000 x2 : 0000000000000000 Feb 18 17:59:55 localhost kernel: [ 3.718006] x1 : ffffffc064c63800 x0 : 0000000000000001 Feb 18 17:59:55 localhost kernel: [ 3.723268] Call trace: Feb 18 17:59:55 localhost kernel: [ 3.725685] _regulator_put.part.12+0x118/0x120 Feb 18 17:59:55 localhost kernel: [ 3.730169] regulator_put+0x34/0x50 Feb 18 17:59:55 localhost kernel: [ 3.733705] regulator_bulk_free+0x34/0x50 Feb 18 17:59:55 localhost kernel: [ 3.737760] devm_regulator_bulk_release+0x18/0x20 Feb 18 17:59:55 localhost kernel: [ 3.742504] release_nodes+0x17c/0x2f8 Feb 18 17:59:55 localhost kernel: [ 3.746212] devres_release_all+0x58/0x88 Feb 18 17:59:55 localhost kernel: [ 3.750179] really_probe+0xc4/0x2c0 Feb 18 17:59:55 localhost kernel: [ 3.753715] driver_probe_device+0x58/0x100 Feb 18 17:59:55 localhost kernel: [ 3.757855] __device_attach_driver+0x9c/0xf8 Feb 18 17:59:55 localhost kernel: [ 3.762170] bus_for_each_drv+0x70/0xc8 Feb 18 17:59:55 localhost kernel: [ 3.765962] __device_attach+0xe0/0x140 Feb 18 17:59:55 localhost kernel: [ 3.769758] device_initial_probe+0x10/0x18 Feb 18 17:59:55 localhost kernel: [ 3.773897] bus_probe_device+0x94/0xa0 Feb 18 17:59:55 localhost kernel: [ 3.777693] deferred_probe_work_func+0x80/0xb8 Feb 18 17:59:55 localhost kernel: [ 3.782181] process_one_work+0x1b0/0x348 Feb 18 17:59:55 localhost kernel: [ 3.786146] worker_thread+0x224/0x448 Feb 18 17:59:55 localhost kernel: [ 3.789855] kthread+0xf8/0x128 Feb 18 17:59:55 localhost kernel: [ 3.792960] ret_from_fork+0x10/0x1c Feb 18 17:59:55 localhost kernel: [ 3.796495] ---[ end trace d139d5a470185e84 ]--- Feb 18 17:59:55 localhost kernel: [ 3.801135] WARNING: CPU: 0 PID: 32 at _regulator_put.part.12+0x118/0x120 Feb 18 17:59:55 localhost kernel: [ 3.807793] Modules linked in: Feb 18 17:59:55 localhost kernel: [ 3.810814] CPU: 0 PID: 32 Comm: kworker/0:1 Tainted: G W 5.0.0-rc7+ #1 Feb 18 17:59:55 localhost kernel: [ 3.818661] Hardware name: Hardkernel ODROID-C2 (DT) Feb 18 17:59:55 localhost kernel: [ 3.823579] Workqueue: events deferred_probe_work_func Feb 18 17:59:55 localhost kernel: [ 3.828666] pstate: 80000005 (Nzcv daif -PAN -UAO) Feb 18 17:59:55 localhost kernel: [ 3.833410] pc : _regulator_put.part.12+0x118/0x120 Feb 18 17:59:55 localhost kernel: [ 3.838240] lr : regulator_put+0x34/0x50 Feb 18 17:59:55 localhost kernel: [ 3.842120] sp : ffffff8010eaba90 Feb 18 17:59:55 localhost kernel: [ 3.845398] x29: ffffff8010eaba90 x28: ffffffc064ce7328 Feb 18 17:59:55 localhost kernel: [ 3.850659] x27: ffffffc064ce7328 x26: ffffff80105c6248 Feb 18 17:59:55 localhost kernel: [ 3.855920] x25: ffffff80105c6250 x24: 0000000000000009 Feb 18 17:59:55 localhost kernel: [ 3.861182] x23: ffffffc064ce7090 x22: ffffff8010eabb88 Feb 18 17:59:55 localhost kernel: [ 3.866443] x21: 0000000000000000 x20: ffffffc06400bc80 Feb 18 17:59:55 localhost kernel: [ 3.871704] x19: ffffffc06400bc80 x18: 0000000000000039 Feb 18 17:59:55 localhost kernel: [ 3.876965] x17: 000000008b9b3fdd x16: 00000000e39dafd8 Feb 18 17:59:55 localhost kernel: [ 3.882227] x15: ffffff8010c3c648 x14: ffffffc005335e10 Feb 18 17:59:55 localhost kernel: [ 3.887488] x13: ffffffc065109430 x12: 0000000000000000 Feb 18 17:59:55 localhost kernel: [ 3.892749] x11: ffffffc065109240 x10: 0000000000000000 Feb 18 17:59:55 localhost kernel: [ 3.898010] x9 : 0000000000000040 x8 : ffffffc06400a9ff Feb 18 17:59:55 localhost kernel: [ 3.903271] x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000000 Feb 18 17:59:55 localhost kernel: [ 3.908533] x5 : 0000000000000000 x4 : 0000000000000000 Feb 18 17:59:55 localhost kernel: [ 3.913794] x3 : 0000000000000000 x2 : 0000000000000000 Feb 18 17:59:55 localhost kernel: [ 3.919055] x1 : ffffffc064c63800 x0 : 0000000000000001 Feb 18 17:59:55 localhost kernel: [ 3.924316] Call trace: Feb 18 17:59:55 localhost kernel: [ 3.926733] _regulator_put.part.12+0x118/0x120 Feb 18 17:59:55 localhost kernel: [ 3.931218] regulator_put+0x34/0x50 Feb 18 17:59:55 localhost kernel: [ 3.934754] regulator_bulk_free+0x34/0x50 Feb 18 17:59:55 localhost kernel: [ 3.938808] devm_regulator_bulk_release+0x18/0x20 Feb 18 17:59:55 localhost kernel: [ 3.943552] release_nodes+0x17c/0x2f8 Feb 18 17:59:55 localhost kernel: [ 3.947261] devres_release_all+0x58/0x88 Feb 18 17:59:55 localhost kernel: [ 3.951227] really_probe+0xc4/0x2c0 Feb 18 17:59:55 localhost kernel: [ 3.954764] driver_probe_device+0x58/0x100 Feb 18 17:59:55 localhost kernel: [ 3.958904] __device_attach_driver+0x9c/0xf8 Feb 18 17:59:55 localhost kernel: [ 3.963218] bus_for_each_drv+0x70/0xc8 Feb 18 17:59:55 localhost kernel: [ 3.967011] __device_attach+0xe0/0x140 Feb 18 17:59:55 localhost kernel: [ 3.970806] device_initial_probe+0x10/0x18 Feb 18 17:59:55 localhost kernel: [ 3.974946] bus_probe_device+0x94/0xa0 Feb 18 17:59:55 localhost kernel: [ 3.978741] deferred_probe_work_func+0x80/0xb8 Feb 18 17:59:55 localhost kernel: [ 3.983227] process_one_work+0x1b0/0x348 Feb 18 17:59:55 localhost kernel: [ 3.987194] worker_thread+0x224/0x448 Feb 18 17:59:55 localhost kernel: [ 3.990903] kthread+0xf8/0x128 Feb 18 17:59:55 localhost kernel: [ 3.994008] ret_from_fork+0x10/0x1c Feb 18 17:59:55 localhost kernel: [ 3.997543] ---[ end trace d139d5a470185e85 ]--- Feb 18 17:59:55 localhost kernel: [ 4.002170] dwc2: probe of c9000000.usb failed with error -22 Feb 18 17:59:55 localhost kernel: [ 4.008025] dwc2 c9100000.usb: c9100000.usb supply vusb_d not found, using dummy regulator Feb 18 17:59:55 localhost kernel: [ 4.016048] dwc2 c9100000.usb: Linked as a consumer to regulator.0 Feb 18 17:59:55 localhost kernel: [ 4.022135] dwc2 c9100000.usb: c9100000.usb supply vusb_a not found, using dummy regulator Feb 18 17:59:55 localhost kernel: [ 4.088103] dwc2 c9100000.usb: dwc2_check_params: Invalid parameter lpm=1 Feb 18 17:59:55 localhost kernel: [ 4.089237] dwc2 c9100000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1 Feb 18 17:59:55 localhost kernel: [ 4.097094] dwc2 c9100000.usb: dwc2_check_params: Invalid parameter besl=1 Feb 18 17:59:55 localhost kernel: [ 4.103905] dwc2 c9100000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1 Feb 18 17:59:55 localhost kernel: [ 4.112794] dwc2 c9100000.usb: DWC OTG Controller Feb 18 17:59:55 localhost kernel: [ 4.116514] dwc2 c9100000.usb: new USB bus registered, assigned bus number 1 Feb 18 17:59:55 localhost kernel: [ 4.123505] dwc2 c9100000.usb: irq 34, io mem 0xc9100000 Feb 18 17:59:55 localhost kernel: [ 4.129304] hub 1-0:1.0: USB hub found Feb 18 17:59:55 localhost kernel: [ 4.132477] hub 1-0:1.0: 1 port detected Feb 18 17:59:55 localhost kernel: [ 4.137029] meson-gx-mmc d0072000.mmc: Linked as a consumer to regulator.4 Feb 18 17:59:55 localhost kernel: [ 4.143189] meson-gx-mmc d0072000.mmc: Linked as a consumer to regulator.5 Feb 18 17:59:55 localhost kernel: [ 4.150006] meson-gx-mmc d0072000.mmc: Got CD GPIO Feb 18 17:59:55 localhost kernel: [ 4.182949] hctosys: unable to open rtc device (rtc0) Feb 18 17:59:55 localhost kernel: [ 4.183160] VCC3V3: disabling Feb 18 17:59:55 localhost kernel: [ 4.185396] ALSA device list: Feb 18 17:59:55 localhost kernel: [ 4.188230] No soundcards found. Feb 18 17:59:55 localhost kernel: [ 4.197290] Waiting for root device /dev/mmcblk1p2... Feb 18 17:59:55 localhost kernel: [ 4.262022] mmc1: new high speed SDHC card at address 0007 Feb 18 17:59:55 localhost kernel: [ 4.264022] mmcblk1: mmc1:0007 SL16G 14.5 GiB Feb 18 17:59:55 localhost kernel: [ 4.267751] mmcblk1: p1 p2 Feb 18 17:59:55 localhost kernel: [ 4.277863] EXT4-fs (mmcblk1p2): Mount option "data=writeback" incompatible with ext2 Feb 18 17:59:55 localhost kernel: [ 4.337210] EXT4-fs (mmcblk1p2): mounted filesystem with writeback data mode. Opts: data=writeback Feb 18 17:59:55 localhost kernel: [ 4.340552] VFS: Mounted root (ext4 filesystem) on device 179:2. Feb 18 17:59:55 localhost kernel: [ 4.354380] devtmpfs: mounted Feb 18 17:59:55 localhost kernel: [ 4.354679] Freeing unused kernel memory: 448K Feb 18 17:59:55 localhost kernel: [ 4.368669] Checked W+X mappings: passed, no W+X pages found Feb 18 17:59:55 localhost kernel: [ 4.368702] Run /sbin/init as init process Feb 18 17:59:55 localhost kernel: [ 4.532116] usb 1-1: new high-speed USB device number 2 using dwc2 Feb 18 17:59:55 localhost kernel: [ 4.661729] random: fast init done Feb 18 17:59:55 localhost kernel: [ 4.742039] hub 1-1:1.0: USB hub found Feb 18 17:59:55 localhost kernel: [ 4.742348] hub 1-1:1.0: 4 ports detected Feb 18 17:59:55 localhost kernel: [ 5.032130] usb 1-1.1: new high-speed USB device number 3 using dwc2 Feb 18 17:59:55 localhost kernel: [ 5.043062] random: systemd: uninitialized urandom read (16 bytes read) Feb 18 17:59:55 localhost kernel: [ 5.059577] random: systemd: uninitialized urandom read (16 bytes read) Feb 18 17:59:55 localhost kernel: [ 5.060601] random: systemd: uninitialized urandom read (16 bytes read) Feb 18 17:59:55 localhost kernel: [ 5.212131] usb 1-1.2: new high-speed USB device number 4 using dwc2 Feb 18 17:59:55 localhost kernel: [ 5.969604] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Feb 18 17:59:55 localhost kernel: [ 6.138323] RPC: Registered named UNIX socket transport module. Feb 18 17:59:55 localhost kernel: [ 6.138598] RPC: Registered udp transport module. Feb 18 17:59:55 localhost kernel: [ 6.143325] RPC: Registered tcp transport module. Feb 18 17:59:55 localhost kernel: [ 6.147962] RPC: Registered tcp NFSv4.1 backchannel transport module. Feb 18 17:59:55 localhost kernel: [ 6.206002] EXT4-fs (mmcblk1p2): re-mounted. Opts: commit=600,errors=remount-ro Feb 18 17:59:55 localhost kernel: [ 6.415907] random: crng init done Feb 18 17:59:55 localhost kernel: [ 6.417316] random: 7 urandom warning(s) missed due to ratelimiting Feb 18 17:59:55 localhost kernel: [ 6.463575] synth uevent: /devices/platform/soc/c8100000.bus/c8100580.ir/rc/rc0/input0: failed to send uevent Feb 18 17:59:55 localhost kernel: [ 6.463582] input input0: uevent: failed to send synthetic uevent Feb 18 17:59:55 localhost kernel: [ 6.875888] cfg80211: Loading compiled-in X.509 certificates for regulatory database Feb 18 17:59:55 localhost kernel: [ 6.888425] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' Feb 18 17:59:55 localhost kernel: [ 6.921727] Generic PHY stmmac-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=stmmac-0:00, irq=POLL) Feb 18 17:59:55 localhost kernel: [ 6.932505] meson8b-dwmac c9410000.ethernet eth0: No Safety Features support found Feb 18 17:59:55 localhost kernel: [ 6.932910] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 Feb 18 17:59:55 localhost kernel: [ 6.934435] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW Feb 18 17:59:55 localhost kernel: [ 6.936631] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off Feb 18 17:59:55 localhost kernel: [ 6.943089] cfg80211: failed to load regulatory.db Feb 18 17:59:55 localhost kernel: [ 7.192113] usb 1-1.2: reset high-speed USB device number 4 using dwc2 Feb 18 17:59:55 localhost kernel: [ 7.218345] br-lan: port 1(eth0.3) entered blocking state Feb 18 17:59:55 localhost kernel: [ 7.218814] br-lan: port 1(eth0.3) entered disabled state Feb 18 17:59:55 localhost kernel: [ 7.224445] device eth0.3 entered promiscuous mode Feb 18 17:59:55 localhost kernel: [ 7.232066] device eth0 entered promiscuous mode Feb 18 17:59:55 localhost kernel: [ 7.237269] br-lan: port 1(eth0.3) entered blocking state Feb 18 17:59:55 localhost kernel: [ 7.238824] br-lan: port 1(eth0.3) entered forwarding state Feb 18 17:59:55 localhost kernel: [ 7.241449] 88XXau: loading out-of-tree module taints kernel. Feb 18 17:59:55 localhost kernel: [ 7.305670] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 2872, rev 0202 detected Feb 18 17:59:55 localhost kernel: [ 7.362230] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0001 detected Feb 18 17:59:55 localhost kernel: [ 7.364003] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Feb 18 17:59:55 localhost kernel: [ 7.365596] usbcore: registered new interface driver rt2800usb Feb 18 17:59:55 localhost kernel: [ 7.809068] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin' Feb 18 17:59:55 localhost kernel: [ 7.826324] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 Feb 18 17:59:55 localhost kernel: [ 8.140162] usb 1-1.1: reset high-speed USB device number 3 using dwc2 Feb 18 17:59:55 localhost kernel: [ 8.240588] usb 1-1.1: device firmware changed Feb 18 17:59:55 localhost kernel: [ 8.242290] usbcore: registered new interface driver rtl88xxau Feb 18 17:59:55 localhost kernel: [ 8.243329] usb 1-1.1: USB disconnect, device number 3 Feb 18 17:59:55 localhost kernel: [ 8.328139] usb 1-1.1: new high-speed USB device number 5 using dwc2 Feb 18 17:59:55 localhost kernel: [ 8.514423] zram0: detected capacity change from 0 to 52428800 Feb 18 17:59:55 localhost kernel: [ 8.811641] rtl88xxau 1-1.1:1.0 wlan2: renamed from wlan1 Feb 18 17:59:55 localhost kernel: [ 8.907728] new mount options do not match the existing superblock, will be ignored Feb 18 17:59:55 localhost kernel: [ 9.022314] fuse init (API version 7.28) Feb 18 17:59:55 localhost kernel: [ 9.571880] br-dmz: port 1(eth0.2) entered blocking state Feb 18 17:59:55 localhost kernel: [ 9.571919] br-dmz: port 1(eth0.2) entered disabled state Feb 18 17:59:55 localhost kernel: [ 9.577524] device eth0.2 entered promiscuous mode Feb 18 17:59:55 localhost kernel: [ 9.588962] br-dmz: port 1(eth0.2) entered blocking state Feb 18 17:59:55 localhost kernel: [ 9.589003] br-dmz: port 1(eth0.2) entered forwarding state Feb 18 17:59:55 localhost kernel: [ 9.970330] br-iot: port 1(eth0.5) entered blocking state Feb 18 17:59:55 localhost kernel: [ 9.970375] br-iot: port 1(eth0.5) entered disabled state Feb 18 17:59:55 localhost kernel: [ 9.975834] device eth0.5 entered promiscuous mode Feb 18 17:59:55 localhost kernel: [ 9.986657] br-iot: port 1(eth0.5) entered blocking state Feb 18 17:59:55 localhost kernel: [ 9.986698] br-iot: port 1(eth0.5) entered forwarding state Feb 18 18:00:06 localhost kernel: [ 21.021783] CIFS: Attempting to mount //10.10.30.136/USBStick Feb 18 18:00:06 localhost kernel: [ 21.021968] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. Feb 18 18:00:06 localhost kernel: [ 21.022464] CIFS: Attempting to mount //10.10.30.136/Multimedia Feb 18 18:00:06 localhost kernel: [ 21.022797] CIFS: Attempting to mount //10.10.30.136/Public Feb 18 18:00:06 localhost kernel: [ 21.022856] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. Feb 18 18:00:07 localhost kernel: [ 21.078731] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. Feb 18 18:00:07 localhost kernel: [ 21.203783] cryptd: max_cpu_qlen set to 1000 Feb 18 18:00:07 localhost kernel: [ 21.206254] input: lircd-uinput as /devices/virtual/input/input1 Feb 18 18:00:07 localhost kernel: [ 21.596363] input: meson-ir (lircd bypass) as /devices/virtual/input/input2 Feb 18 18:00:07 localhost kernel: [ 21.669334] br-guest: port 1(wlan0) entered blocking state Feb 18 18:00:07 localhost kernel: [ 21.670122] br-guest: port 1(wlan0) entered disabled state Feb 18 18:00:07 localhost kernel: [ 21.675913] device wlan0 entered promiscuous mode Feb 18 18:00:07 localhost kernel: [ 21.825578] br-guest: port 1(wlan0) entered blocking state Feb 18 18:00:07 localhost kernel: [ 21.830103] br-guest: port 1(wlan0) entered forwarding state Feb 18 18:00:07 localhost kernel: [ 21.901449] br-lan: port 2(wlan0_1) entered blocking state Feb 18 18:00:07 localhost kernel: [ 21.901489] br-lan: port 2(wlan0_1) entered disabled state Feb 18 18:00:07 localhost kernel: [ 21.907035] device wlan0_1 entered promiscuous mode Feb 18 18:00:07 localhost kernel: [ 21.922534] br-lan: port 2(wlan0_1) entered blocking state Feb 18 18:00:07 localhost kernel: [ 21.922570] br-lan: port 2(wlan0_1) entered forwarding state Feb 18 18:00:08 localhost kernel: [ 22.921295] br-lan: port 3(wlan2) entered blocking state Feb 18 18:00:08 localhost kernel: [ 22.921344] br-lan: port 3(wlan2) entered disabled state Feb 18 18:00:08 localhost kernel: [ 22.926623] device wlan2 entered promiscuous mode Feb 18 18:00:08 localhost kernel: [ 22.931105] br-lan: port 3(wlan2) entered blocking state Feb 18 18:00:08 localhost kernel: [ 22.936230] br-lan: port 3(wlan2) entered forwarding state Feb 18 18:00:09 localhost kernel: [ 23.180963] ip_local_port_range: prefer different parity for start/end values. [-- Attachment #4: ethtool_test.txt --] [-- Type: text/plain, Size: 5360 bytes --] NIC statistics: mmc_tx_octetcount_gb: 0 mmc_tx_framecount_gb: 0 mmc_tx_broadcastframe_g: 0 mmc_tx_multicastframe_g: 0 mmc_tx_64_octets_gb: 0 mmc_tx_65_to_127_octets_gb: 0 mmc_tx_128_to_255_octets_gb: 0 mmc_tx_256_to_511_octets_gb: 0 mmc_tx_512_to_1023_octets_gb: 0 mmc_tx_1024_to_max_octets_gb: 0 mmc_tx_unicast_gb: 0 mmc_tx_multicast_gb: 0 mmc_tx_broadcast_gb: 0 mmc_tx_underflow_error: 0 mmc_tx_singlecol_g: 0 mmc_tx_multicol_g: 0 mmc_tx_deferred: 0 mmc_tx_latecol: 0 mmc_tx_exesscol: 0 mmc_tx_carrier_error: 0 mmc_tx_octetcount_g: 0 mmc_tx_framecount_g: 0 mmc_tx_excessdef: 0 mmc_tx_pause_frame: 0 mmc_tx_vlan_frame_g: 0 mmc_rx_framecount_gb: 210416 mmc_rx_octetcount_gb: 179141135 mmc_rx_octetcount_g: 179141135 mmc_rx_broadcastframe_g: 12969 mmc_rx_multicastframe_g: 62 mmc_rx_crc_error: 0 mmc_rx_align_error: 0 mmc_rx_run_error: 0 mmc_rx_jabber_error: 0 mmc_rx_undersize_g: 0 mmc_rx_oversize_g: 0 mmc_rx_64_octets_gb: 0 mmc_rx_65_to_127_octets_gb: 92779 mmc_rx_128_to_255_octets_gb: 3501 mmc_rx_256_to_511_octets_gb: 1242 mmc_rx_512_to_1023_octets_gb: 241 mmc_rx_1024_to_max_octets_gb: 112653 mmc_rx_unicast_g: 197385 mmc_rx_length_error: 0 mmc_rx_autofrangetype: 0 mmc_rx_pause_frames: 0 mmc_rx_fifo_overflow: 1837 mmc_rx_vlan_frames_gb: 210408 mmc_rx_watchdog_error: 0 mmc_rx_ipc_intr_mask: 3221078013 mmc_rx_ipc_intr: 0 mmc_rx_ipv4_gd: 197672 mmc_rx_ipv4_hderr: 0 mmc_rx_ipv4_nopay: 0 mmc_rx_ipv4_frag: 0 mmc_rx_ipv4_udsbl: 0 mmc_rx_ipv4_gd_octets: 173449744 mmc_rx_ipv4_hderr_octets: 0 mmc_rx_ipv4_nopay_octets: 0 mmc_rx_ipv4_frag_octets: 0 mmc_rx_ipv4_udsbl_octets: 0 mmc_rx_ipv6_gd_octets: 10629 mmc_rx_ipv6_hderr_octets: 0 mmc_rx_ipv6_nopay_octets: 0 mmc_rx_ipv6_gd: 26 mmc_rx_ipv6_hderr: 0 mmc_rx_ipv6_nopay: 0 mmc_rx_udp_gd: 5382 mmc_rx_udp_err: 0 mmc_rx_tcp_gd: 192230 mmc_rx_tcp_err: 0 mmc_rx_icmp_gd: 86 mmc_rx_icmp_err: 0 mmc_rx_udp_gd_octets: 1017976 mmc_rx_udp_err_octets: 0 mmc_rx_tcp_gd_octets: 168484207 mmc_rx_tcp_err_octets: 0 mmc_rx_icmp_gd_octets: 3710 mmc_rx_icmp_err_octets: 0 tx_underflow: 0 tx_carrier: 0 tx_losscarrier: 0 vlan_tag: 208571 tx_deferred: 0 tx_vlan: 517448 tx_jabber: 0 tx_frame_flushed: 0 tx_payload_error: 0 tx_ip_header_error: 0 rx_desc: 0 sa_filter_fail: 0 overflow_error: 0 ipc_csum_error: 0 rx_collision: 0 rx_crc_errors: 0 dribbling_bit: 0 rx_length: 0 rx_mii: 0 rx_multicast: 0 rx_gmac_overflow: 0 rx_watchdog: 0 da_rx_filter_fail: 0 sa_rx_filter_fail: 0 rx_missed_cntr: 0 rx_overflow_cntr: 0 rx_vlan: 0 tx_undeflow_irq: 0 tx_process_stopped_irq: 0 tx_jabber_irq: 0 rx_overflow_irq: 0 rx_buf_unav_irq: 0 rx_process_stopped_irq: 0 rx_watchdog_irq: 0 tx_early_irq: 0 fatal_bus_error_irq: 0 rx_early_irq: 14871 threshold: 1 tx_pkt_n: 517448 rx_pkt_n: 208579 normal_irq_n: 63099 rx_normal_irq_n: 38811 napi_poll: 65991 tx_normal_irq_n: 22368 tx_clean: 65991 tx_set_ic_bit: 20697 irq_receive_pmt_irq_n: 0 mmc_tx_irq_n: 0 mmc_rx_irq_n: 0 mmc_rx_csum_offload_irq_n: 0 irq_tx_path_in_lpi_mode_n: 18571 irq_tx_path_exit_lpi_mode_n: 18570 irq_rx_path_in_lpi_mode_n: 0 irq_rx_path_exit_lpi_mode_n: 0 phy_eee_wakeup_error_n: 0 ip_hdr_err: 0 ip_payload_err: 0 ip_csum_bypassed: 0 ipv4_pkt_rcvd: 0 ipv6_pkt_rcvd: 0 no_ptp_rx_msg_type_ext: 0 ptp_rx_msg_type_sync: 0 ptp_rx_msg_type_follow_up: 0 ptp_rx_msg_type_delay_req: 0 ptp_rx_msg_type_delay_resp: 0 ptp_rx_msg_type_pdelay_req: 0 ptp_rx_msg_type_pdelay_resp: 0 ptp_rx_msg_type_pdelay_follow_up: 0 ptp_rx_msg_type_announce: 0 ptp_rx_msg_type_management: 0 ptp_rx_msg_pkt_reserved_type: 0 ptp_frame_type: 0 ptp_ver: 0 timestamp_dropped: 0 av_pkt_rcvd: 0 av_tagged_pkt_rcvd: 0 vlan_tag_priority_val: 0 l3_filter_match: 0 l4_filter_match: 0 l3_l4_filter_no_match: 0 irq_pcs_ane_n: 0 irq_pcs_link_n: 0 irq_rgmii_n: 0 mtl_tx_status_fifo_full: 0 mtl_tx_fifo_not_empty: 0 mmtl_fifo_ctrl: 0 mtl_tx_fifo_read_ctrl_write: 0 mtl_tx_fifo_read_ctrl_wait: 0 mtl_tx_fifo_read_ctrl_read: 0 mtl_tx_fifo_read_ctrl_idle: 0 mac_tx_in_pause: 0 mac_tx_frame_ctrl_xfer: 0 mac_tx_frame_ctrl_idle: 0 mac_tx_frame_ctrl_wait: 0 mac_tx_frame_ctrl_pause: 0 mac_gmii_tx_proto_engine: 0 mtl_rx_fifo_fill_level_full: 0 mtl_rx_fifo_fill_above_thresh: 0 mtl_rx_fifo_fill_below_thresh: 0 mtl_rx_fifo_fill_level_empty: 0 mtl_rx_fifo_read_ctrl_flush: 0 mtl_rx_fifo_read_ctrl_read_data: 0 mtl_rx_fifo_read_ctrl_status: 0 mtl_rx_fifo_read_ctrl_idle: 0 mtl_rx_fifo_ctrl_active: 0 mac_rx_frame_ctrl_fifo: 0 mac_gmii_rx_proto_engine: 0 tx_tso_frames: 0 tx_tso_nfrags: 0 ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2019-05-22 14:02 UTC | newest] Thread overview: 48+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <a38e643c-ed9f-c306-cc95-84f70ebc1f10@gmx.de> [not found] ` <CAFBinCDebPOsmrhSXecx48nGWHh7g_OGPbr1Y0M+n_v9Ht91ew@mail.gmail.com> 2019-01-17 21:23 ` stmmac / meson8b-dwmac Simon Huelck 2019-02-04 14:34 ` Martin Blumenstingl 2019-02-06 10:36 ` Emiliano Ingrassia 2019-02-06 18:04 ` Simon Huelck 2019-02-06 21:21 ` Simon Huelck 2019-02-07 19:30 ` Simon Huelck 2019-02-09 1:09 ` Martin Blumenstingl 2019-02-11 13:44 ` Jose Abreu 2019-02-14 7:21 ` Simon Huelck 2019-02-17 14:48 ` Martin Blumenstingl 2019-02-17 19:13 ` Simon Huelck 2019-02-18 8:42 ` Jose Abreu 2019-02-18 8:45 ` Jose Abreu 2019-02-18 12:33 ` Simon Huelck 2019-02-18 12:41 ` Jose Abreu 2019-02-18 13:02 ` Jose Abreu 2019-02-18 15:29 ` Simon Huelck 2019-02-18 15:31 ` Jose Abreu 2019-02-18 15:53 ` Simon Huelck 2019-02-18 16:26 ` Jose Abreu 2019-02-18 16:40 ` Simon Huelck 2019-02-18 16:43 ` Jose Abreu 2019-02-18 16:51 ` Simon Huelck 2019-02-18 17:05 ` Jose Abreu 2019-02-18 18:05 ` Simon Huelck 2019-02-19 8:47 ` Jose Abreu 2019-02-19 19:41 ` Simon Huelck 2019-02-21 14:21 ` Jerome Brunet 2019-02-21 17:27 ` Simon Huelck 2019-02-21 17:46 ` Jerome Brunet 2019-02-21 19:34 ` Simon Huelck 2019-02-22 17:21 ` Anand Moon 2019-02-24 15:00 ` Simon Huelck 2019-02-24 15:02 ` Simon Huelck 2019-02-24 19:42 ` Sebastian Gottschall 2019-02-24 20:34 ` Simon Huelck 2019-02-27 11:09 ` Jose Abreu 2019-02-27 19:02 ` Simon Huelck 2019-03-01 9:23 ` Jose Abreu 2019-03-05 9:55 ` Simon Huelck 2019-03-06 11:35 ` Simon Huelck 2019-03-06 11:45 ` Simon Huelck 2019-05-11 14:53 ` Simon Huelck 2019-05-13 9:07 ` Jose Abreu 2019-05-22 12:48 ` Simon Huelck 2019-05-22 14:02 ` Neil Armstrong 2019-02-27 21:03 ` Simon Huelck 2019-02-18 17:05 ` Simon Huelck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).