[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Thomas Scheiblauer]

Since Kernel 3.16 (running on 3.16.0) the ethernet (fec) connection
stops working after exchanging very little data. Sometimes it comes back
again for some seconds and drops again. No clues in dmesg.

After increasing TX_RING_SIZE in "drivers/net/ethernet/freescale/fec.h"
from 512 to 1024 the connection seems to stay stable (judging after
about half an hour of testing) but I really don't have experience with
kernel driver hacking, so I'm not sure what I'm doing here.

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Russell King - ARM Linux]

On Fri, Aug 08, 2014 at 03:15:58PM +0200, Thomas Scheiblauer wrote:
> Since Kernel 3.16 (running on 3.16.0) the ethernet (fec) connection
> stops working after exchanging very little data. Sometimes it comes back
> again for some seconds and drops again. No clues in dmesg.
> 
> After increasing TX_RING_SIZE in "drivers/net/ethernet/freescale/fec.h"
> from 512 to 1024 the connection seems to stay stable (judging after
> about half an hour of testing) but I really don't have experience with
> kernel driver hacking, so I'm not sure what I'm doing here.

Interesting.  There have been some other reports of instability in a
similar manner to that which you report, and, like the wanboard, they
too have this:

        interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
                              <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;

Could it be that gpio1 6 doesn't actually work very well?  What happens
if you comment out the above property in
arch/arm/boot/dts/imx6qdl-wandboard.dtsi so you're using the standard
interrupt on GIC 150?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Thomas Scheiblauer]

On Fre, 2014-08-08 at 14:27 +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 08, 2014 at 03:15:58PM +0200, Thomas Scheiblauer wrote:
> > Since Kernel 3.16 (running on 3.16.0) the ethernet (fec) connection
> > stops working after exchanging very little data. Sometimes it comes back
> > again for some seconds and drops again. No clues in dmesg.
> > 
> > After increasing TX_RING_SIZE in "drivers/net/ethernet/freescale/fec.h"
> > from 512 to 1024 the connection seems to stay stable (judging after
> > about half an hour of testing) but I really don't have experience with
> > kernel driver hacking, so I'm not sure what I'm doing here.
> 
> Interesting.  There have been some other reports of instability in a
> similar manner to that which you report, and, like the wanboard, they
> too have this:
> 
>         interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
>                               <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
> 
> Could it be that gpio1 6 doesn't actually work very well?  What happens
> if you comment out the above property in
> arch/arm/boot/dts/imx6qdl-wandboard.dtsi so you're using the standard
> interrupt on GIC 150?
> 

These lines in arch/arm/boot/dts/imx6qdl-wandboard.dtsi already seem to
be a workaround for some hardware errata:
ERR006687 ?ENET: Only the ENET wake-up interrupt request can wake the
system from Wait mode?

See the original mail containing the patch:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/221204.html

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Fabio Estevam]

Thomas,

On Fri, Aug 8, 2014 at 11:10 AM, Thomas Scheiblauer <tom@sharkbay.at> wrote:

> These lines in arch/arm/boot/dts/imx6qdl-wandboard.dtsi already seem to
> be a workaround for some hardware errata:
> ERR006687 ?ENET: Only the ENET wake-up interrupt request can wake the
> system from Wait mode?
>
> See the original mail containing the patch:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/221204.html

This commit is also in 3.15 kernel. Do you have this instability issue in 3.15?

It would be helpful if you could revert commit 9fc77821b17155c6e0 with
3.16 and try again, just to make sure that the workaround is not
introducing issues.

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Thomas Scheiblauer]

Fabio,

On Fre, 2014-08-08 at 11:17 -0300, Fabio Estevam wrote:
> Thomas,
> 
> On Fri, Aug 8, 2014 at 11:10 AM, Thomas Scheiblauer <tom@sharkbay.at> wrote:
> 
> > These lines in arch/arm/boot/dts/imx6qdl-wandboard.dtsi already seem to
> > be a workaround for some hardware errata:
> > ERR006687 ?ENET: Only the ENET wake-up interrupt request can wake the
> > system from Wait mode?
> >
> > See the original mail containing the patch:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/221204.html
> 
> This commit is also in 3.15 kernel. Do you have this instability issue in 3.15?
> 
> It would be helpful if you could revert commit 9fc77821b17155c6e0 with
> 3.16 and try again, just to make sure that the workaround is not
> introducing issues.

in 3.15 and earlier I had similar issues. See the the original thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/202519.html
I increased TX_RING_SIZE from 16 to 64 as suggested by Duan Fugang from
Freescale to work around that problem. It didn't completely remedy it
but made it occur less often.
But probably that patch had already been applied to these kernels
because I usually patch my i.mx6 kernels with Robert C. Nelson's
patchset http://eewiki.net/display/linuxonarm/Wandboard which is
basically a collection of the patches found in this mailing list before
they are officially applied.

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Russell King - ARM Linux]

On Fri, Aug 08, 2014 at 04:10:23PM +0200, Thomas Scheiblauer wrote:
> On Fre, 2014-08-08 at 14:27 +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 08, 2014 at 03:15:58PM +0200, Thomas Scheiblauer wrote:
> > > Since Kernel 3.16 (running on 3.16.0) the ethernet (fec) connection
> > > stops working after exchanging very little data. Sometimes it comes back
> > > again for some seconds and drops again. No clues in dmesg.
> > > 
> > > After increasing TX_RING_SIZE in "drivers/net/ethernet/freescale/fec.h"
> > > from 512 to 1024 the connection seems to stay stable (judging after
> > > about half an hour of testing) but I really don't have experience with
> > > kernel driver hacking, so I'm not sure what I'm doing here.
> > 
> > Interesting.  There have been some other reports of instability in a
> > similar manner to that which you report, and, like the wanboard, they
> > too have this:
> > 
> >         interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
> >                               <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
> > 
> > Could it be that gpio1 6 doesn't actually work very well?  What happens
> > if you comment out the above property in
> > arch/arm/boot/dts/imx6qdl-wandboard.dtsi so you're using the standard
> > interrupt on GIC 150?
> > 
> 
> These lines in arch/arm/boot/dts/imx6qdl-wandboard.dtsi already seem to
> be a workaround for some hardware errata:
> ERR006687 ?ENET: Only the ENET wake-up interrupt request can wake the
> system from Wait mode?

Correct.  That's a workaround for wakeup.  That's not a workaround for
normal operation.

Two people (including yourself) have reported ethernet stability problems
with recent kernels.  Both reporters show that their platforms are using
GPIO1 6 being for the ethernet IRQ.

Meanwhile, I (and others) have the standard IRQ being used for it, and we
have yet to have any reports or see any instability resulting from that.

So, what I'm asking is to try without this workaround in case there is
some interaction there, thus testing the same interrupt configuration
that I've had here for the last 10 months without the kind of issues
you're reporting.  Sometimes, workarounds for one problem end up causing
other problem elsewhere.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Thomas Scheiblauer]

On Fre, 2014-08-08 at 15:30 +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 08, 2014 at 04:10:23PM +0200, Thomas Scheiblauer wrote:
> > On Fre, 2014-08-08 at 14:27 +0100, Russell King - ARM Linux wrote:
> > > On Fri, Aug 08, 2014 at 03:15:58PM +0200, Thomas Scheiblauer wrote:
> > > > Since Kernel 3.16 (running on 3.16.0) the ethernet (fec) connection
> > > > stops working after exchanging very little data. Sometimes it comes back
> > > > again for some seconds and drops again. No clues in dmesg.
> > > > 
> > > > After increasing TX_RING_SIZE in "drivers/net/ethernet/freescale/fec.h"
> > > > from 512 to 1024 the connection seems to stay stable (judging after
> > > > about half an hour of testing) but I really don't have experience with
> > > > kernel driver hacking, so I'm not sure what I'm doing here.
> > > 
> > > Interesting.  There have been some other reports of instability in a
> > > similar manner to that which you report, and, like the wanboard, they
> > > too have this:
> > > 
> > >         interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
> > >                               <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
> > > 
> > > Could it be that gpio1 6 doesn't actually work very well?  What happens
> > > if you comment out the above property in
> > > arch/arm/boot/dts/imx6qdl-wandboard.dtsi so you're using the standard
> > > interrupt on GIC 150?
> > > 
> > 
> > These lines in arch/arm/boot/dts/imx6qdl-wandboard.dtsi already seem to
> > be a workaround for some hardware errata:
> > ERR006687 ?ENET: Only the ENET wake-up interrupt request can wake the
> > system from Wait mode?
> 
> Correct.  That's a workaround for wakeup.  That's not a workaround for
> normal operation.
> 
> Two people (including yourself) have reported ethernet stability problems
> with recent kernels.  Both reporters show that their platforms are using
> GPIO1 6 being for the ethernet IRQ.
> 
> Meanwhile, I (and others) have the standard IRQ being used for it, and we
> have yet to have any reports or see any instability resulting from that.
> 
> So, what I'm asking is to try without this workaround in case there is
> some interaction there, thus testing the same interrupt configuration
> that I've had here for the last 10 months without the kind of issues
> you're reporting.  Sometimes, workarounds for one problem end up causing
> other problem elsewhere.
> 

Indeed, commenting out these 2 lines in
arch/arm/boot/dts/imx6qdl-wandboard.dtsi fixes my problem without having
to increase TX_RING_SIZE.
Thank you very much!

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Fabio Estevam]

Hi Thomas,

On Fri, Aug 8, 2014 at 11:58 AM, Thomas Scheiblauer <tom@sharkbay.at> wrote:

>> So, what I'm asking is to try without this workaround in case there is
>> some interaction there, thus testing the same interrupt configuration
>> that I've had here for the last 10 months without the kind of issues
>> you're reporting.  Sometimes, workarounds for one problem end up causing
>> other problem elsewhere.
>>
>
> Indeed, commenting out these 2 lines in
> arch/arm/boot/dts/imx6qdl-wandboard.dtsi fixes my problem without having
> to increase TX_RING_SIZE.
> Thank you very much!

Could you please send a patch for imx6qdl-wandboard.dtsi? Please
provide the details of the problem in the commit log.

Thanks

[PATCH 1/1] undo workaround for i.mx6 silicon errata ERR006687 which resulted in an unstable ethernet connection (lost interrupts?)

[Thomas Scheiblauer]

> > 
> > On Fre, 2014-08-08 at 12:46 -0300, Fabio Estevam wrote:
> > Hi Thomas,
> > 
> > On Fri, Aug 8, 2014 at 11:58 AM, Thomas Scheiblauer <tom@sharkbay.at> wrote:
> > 
> > >> So, what I'm asking is to try without this workaround in case there is
> > >> some interaction there, thus testing the same interrupt configuration
> > >> that I've had here for the last 10 months without the kind of issues
> > >> you're reporting.  Sometimes, workarounds for one problem end up causing
> > >> other problem elsewhere.
> > >>
> > >
> > > Indeed, commenting out these 2 lines in
> > > arch/arm/boot/dts/imx6qdl-wandboard.dtsi fixes my problem without having
> > > to increase TX_RING_SIZE.
> > > Thank you very much!
> > 
> > Could you please send a patch for imx6qdl-wandboard.dtsi? Please
> > provide the details of the problem in the commit log.
> > 
> > Thanks

Ok, here is my attempt on the patch. I've also removed the respective lines from all the other imx6qdl-*.dtsi files.

Signed-off-by: Thomas Scheiblauer <tom@sharkbay.at>
---
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 2 --
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi  | 2 --
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi  | 2 --
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi  | 2 --
 4 files changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 42ff525..cf4e6db 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -169,8 +169,6 @@
 	txd1-skew-ps = <0>;
 	txd2-skew-ps = <0>;
 	txd3-skew-ps = <0>;
-	interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
-			      <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 009abd6..f47e82f 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -65,8 +65,6 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_enet>;
 	phy-mode = "rgmii";
-	interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
-			      <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 0a36129..ebfcab4 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -168,8 +168,6 @@
 	txd1-skew-ps = <0>;
 	txd2-skew-ps = <0>;
 	txd3-skew-ps = <0>;
-	interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
-			      <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index 6461f66..3b61c9a 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -257,8 +257,6 @@
 	pinctrl-0 = <&pinctrl_enet>;
 	phy-mode = "rgmii";
 	phy-reset-gpios = <&gpio3 29 0>;
-	interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
-			      <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
 	status = "okay";
 };
 
-- 
2.0.2

[PATCH 1/1] undo workaround for i.mx6 silicon errata ERR006687 which resulted in an unstable ethernet connection (lost interrupts?)

[Fabio Estevam]

Hi Thomas,

On Fri, Aug 8, 2014 at 1:33 PM, Thomas Scheiblauer <tom@sharkbay.at> wrote:

> Ok, here is my attempt on the patch. I've also removed the respective lines from all the other imx6qdl-*.dtsi files.

Please create a clean patch and submit it via git send-mail instead of
sending it inside this thread.

Also, please check the style of the Subject. It should be "ARM: dts:
imx6qdl-wandboard: ....."

You need to copy the imx maintainer Shawn Guo and it would be nice to
also copy commit Sascha Silbe, who introduced this patch for
wandboard:

9fc77821b17155c6e0ab50b1e1dd80c2b0e63e98
Author: Sascha Silbe <x-linux@infra-silbe.de>
Date:   Thu Feb 6 23:24:13 2014 +0100

    ARM: dts: imx6qdl-wandboard: use GPIO_6 for FEC interrupt

, and also Troy Kisky to get their inputs.

>
> Signed-off-by: Thomas Scheiblauer <tom@sharkbay.at>
> ---
>  arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 2 --
>  arch/arm/boot/dts/imx6qdl-sabreauto.dtsi  | 2 --
>  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi  | 2 --
>  arch/arm/boot/dts/imx6qdl-wandboard.dtsi  | 2 --
>  4 files changed, 8 deletions(-)

I would suggest by starting only with
arch/arm/boot/dts/imx6qdl-wandboard.dtsi as this is the one you have
really tested.

> diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
> b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
> index 6461f66..3b61c9a 100644
> --- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
> @@ -257,8 +257,6 @@
>         pinctrl-0 = <&pinctrl_enet>;
>         phy-mode = "rgmii";
>         phy-reset-gpios = <&gpio3 29 0>;
> -       interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
> -                             <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;

You should also remove the MX6QDL_PAD_GPIO_6__ENET_IRQ.

Actually it would easier if you just send a patch reverting 9fc77821b17.

You need to put a detailed commit log explaining what are the tests
you are running that show an unstable ethernet connection, add the
logs, command line tests, etc.

Thanks

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Troy Kisky]

On 8/8/2014 7:58 AM, Thomas Scheiblauer wrote:
> 
> 
> Indeed, commenting out these 2 lines in
> arch/arm/boot/dts/imx6qdl-wandboard.dtsi fixes my problem without having
> to increase TX_RING_SIZE.
> Thank you very much!
> 
Could you also please checkout commit

commit 9fc77821b17155c6e0ab50b1e1dd80c2b0e63e98
Author: Sascha Silbe <x-linux@infra-silbe.de>
Date:   Thu Feb 6 23:24:13 2014 +0100

    ARM: dts: imx6qdl-wandboard: use GPIO_6 for FEC interrupt


and see if it also shows ethernet instabilities?


Thanks
Troy

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Troy Kisky]

On 8/8/2014 3:51 PM, George Joseph wrote:
> On Fri, Aug 8, 2014 at 4:02 PM, Troy Kisky <troy.kisky@boundarydevices.com
> <mailto:troy.kisky@boundarydevices.com>> wrote:
> 
>     On 8/8/2014 7:58 AM, Thomas Scheiblauer wrote:
>     >
>     >
>     > Indeed, commenting out these 2 lines in
>     > arch/arm/boot/dts/imx6qdl-wandboard.dtsi fixes my problem without having
>     > to increase TX_RING_SIZE.
>     > Thank you very much!
>     >
>     Could you also please checkout commit
> 
>     commit 9fc77821b17155c6e0ab50b1e1dd80c2b0e63e98
>     Author: Sascha Silbe <x-linux at infra-silbe.de <mailto:x-linux@infra-silbe.de>>
>     Date:   Thu Feb 6 23:24:13 2014 +0100
> 
>         ARM: dts: imx6qdl-wandboard: use GPIO_6 for FEC interrupt
> 
> 
>     and see if it also shows ethernet instabilities?
> 
> 
> I'm confused by the references to GPIO_6 and GPIO1_IO06 as it relates to the wandboard.   According
> to the schematic for both the rev B1 and C1, the GPIO_6 PAD is physically connected to pin 30 on the
> camera interface and according to the dtb tree, GPIO1_IO06 isn't mapped to any PAD.
> 
> This kinda fits with my own observation which is that Ethernet is working fine (40MB/s sustained)
> regardless of whether fec is using "gpio1 6" and "intc 0 119" for extended interrupts or the default
> "intc 0 118" and "intc 0 119".   Otherwise stock 3.16.0 on WB Quad C1.
> 
Are you using a wandboard also?   With or without camera plugged in?


Same question for Thomas. Do you have a camera?


Troy

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[George Joseph]

On Fri, Aug 8, 2014 at 6:33 PM, Troy Kisky
<troy.kisky@boundarydevices.com> wrote:
> On 8/8/2014 3:51 PM, George Joseph wrote:
>> On Fri, Aug 8, 2014 at 4:02 PM, Troy Kisky <troy.kisky@boundarydevices.com
>> <mailto:troy.kisky@boundarydevices.com>> wrote:
>>
>>     On 8/8/2014 7:58 AM, Thomas Scheiblauer wrote:
>>     >
>>     >
>>     > Indeed, commenting out these 2 lines in
>>     > arch/arm/boot/dts/imx6qdl-wandboard.dtsi fixes my problem without having
>>     > to increase TX_RING_SIZE.
>>     > Thank you very much!
>>     >
>>     Could you also please checkout commit
>>
>>     commit 9fc77821b17155c6e0ab50b1e1dd80c2b0e63e98
>>     Author: Sascha Silbe <x-linux at infra-silbe.de <mailto:x-linux@infra-silbe.de>>
>>     Date:   Thu Feb 6 23:24:13 2014 +0100
>>
>>         ARM: dts: imx6qdl-wandboard: use GPIO_6 for FEC interrupt
>>
>>
>>     and see if it also shows ethernet instabilities?
>>
>>
>> I'm confused by the references to GPIO_6 and GPIO1_IO06 as it relates to the wandboard.   According
>> to the schematic for both the rev B1 and C1, the GPIO_6 PAD is physically connected to pin 30 on the
>> camera interface and according to the dtb tree, GPIO1_IO06 isn't mapped to any PAD.
>>
>> This kinda fits with my own observation which is that Ethernet is working fine (40MB/s sustained)
>> regardless of whether fec is using "gpio1 6" and "intc 0 119" for extended interrupts or the default
>> "intc 0 118" and "intc 0 119".   Otherwise stock 3.16.0 on WB Quad C1.
>>
> Are you using a wandboard also?   With or without camera plugged in?

Wandboard Quad rev C1 with nothing connected to the camera connector.
I have 4 of them without problems.

>
>
> Same question for Thomas. Do you have a camera?
>
>
> Troy

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Iain Paton]

On 09/08/14 01:33, Troy Kisky wrote:
> On 8/8/2014 3:51 PM, George Joseph wrote:
>> On Fri, Aug 8, 2014 at 4:02 PM, Troy Kisky <troy.kisky@boundarydevices.com
>> <mailto:troy.kisky@boundarydevices.com>> wrote:
>>
>>     On 8/8/2014 7:58 AM, Thomas Scheiblauer wrote:
>>     >
>>     >
>>     > Indeed, commenting out these 2 lines in
>>     > arch/arm/boot/dts/imx6qdl-wandboard.dtsi fixes my problem without having
>>     > to increase TX_RING_SIZE.
>>     > Thank you very much!
>>     >
>>     Could you also please checkout commit
>>
>>     commit 9fc77821b17155c6e0ab50b1e1dd80c2b0e63e98
>>     Author: Sascha Silbe <x-linux at infra-silbe.de <mailto:x-linux@infra-silbe.de>>
>>     Date:   Thu Feb 6 23:24:13 2014 +0100
>>
>>         ARM: dts: imx6qdl-wandboard: use GPIO_6 for FEC interrupt
>>
>>
>>     and see if it also shows ethernet instabilities?
>>
>>
>> I'm confused by the references to GPIO_6 and GPIO1_IO06 as it relates to the wandboard.   According
>> to the schematic for both the rev B1 and C1, the GPIO_6 PAD is physically connected to pin 30 on the
>> camera interface and according to the dtb tree, GPIO1_IO06 isn't mapped to any PAD.
>>
>> This kinda fits with my own observation which is that Ethernet is working fine (40MB/s sustained)
>> regardless of whether fec is using "gpio1 6" and "intc 0 119" for extended interrupts or the default
>> "intc 0 118" and "intc 0 119".   Otherwise stock 3.16.0 on WB Quad C1.
>>
> Are you using a wandboard also?   With or without camera plugged in?

I have:

2x WBQUAD (B1)  i.MX6Q, silicon rev 1.2
1x Sabre-Lite   i.MX6Q, silicon rev 1.0
2x Sabre-Lite   i.MX6Q, silicon rev 1.2
2x RIoTboard i.MX6Solo, silicon rev 1.1
1x MarSBoard i.MX6Dual, silicon rev 1.2 (I haven't posted the dts for this yet)

all with the GPIO_6 interrupt patch in place, no cameras or anything else 
connected to that pad, no issues seen on 3.15 or 3.16 

I had seen problems on earlier kernels, before the GPIO_6 workaround was 
implemented, where one of my Sabre-Lite boards (only one, and always the 
same one) would vanish off the network for a few minutes. I'd even had it 
happen while in the middle of typing something over an ssh connection.
Connectivity usually seemed to recover on it's own eventually, or I 
could log in over a serial connection and ping something else on the 
network which would restore the connection immediately.
After the GPIO_6 workaround was implemented I've never had the problem 
re-occur.

I use the two wandboards and the three sabre-lites as builders with 
distcc and nfs in the mix, so network issues usually show up fairly 
quickly.

Iain

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Thomas Scheiblauer]

On 11. August 2014 00:36:45 MESZ, Iain Paton <ipaton0@gmail.com> wrote:
>On 09/08/14 01:33, Troy Kisky wrote:
>> On 8/8/2014 3:51 PM, George Joseph wrote:
>>> On Fri, Aug 8, 2014 at 4:02 PM, Troy Kisky
><troy.kisky@boundarydevices.com
>>> <mailto:troy.kisky@boundarydevices.com>> wrote:
>>>
>>>     On 8/8/2014 7:58 AM, Thomas Scheiblauer wrote:
>>>     >
>>>     >
>>>     > Indeed, commenting out these 2 lines in
>>>     > arch/arm/boot/dts/imx6qdl-wandboard.dtsi fixes my problem
>without having
>>>     > to increase TX_RING_SIZE.
>>>     > Thank you very much!
>>>     >
>>>     Could you also please checkout commit
>>>
>>>     commit 9fc77821b17155c6e0ab50b1e1dd80c2b0e63e98
>>>     Author: Sascha Silbe <x-linux@infra-silbe.de
><mailto:x-linux@infra-silbe.de>>
>>>     Date:   Thu Feb 6 23:24:13 2014 +0100
>>>
>>>         ARM: dts: imx6qdl-wandboard: use GPIO_6 for FEC interrupt
>>>
>>>
>>>     and see if it also shows ethernet instabilities?
>>>
>>>
>>> I'm confused by the references to GPIO_6 and GPIO1_IO06 as it
>relates to the wandboard.   According
>>> to the schematic for both the rev B1 and C1, the GPIO_6 PAD is
>physically connected to pin 30 on the
>>> camera interface and according to the dtb tree, GPIO1_IO06 isn't
>mapped to any PAD.
>>>
>>> This kinda fits with my own observation which is that Ethernet is
>working fine (40MB/s sustained)
>>> regardless of whether fec is using "gpio1 6" and "intc 0 119" for
>extended interrupts or the default
>>> "intc 0 118" and "intc 0 119".   Otherwise stock 3.16.0 on WB Quad
>C1.
>>>
>> Are you using a wandboard also?   With or without camera plugged in?
>
>I have:
>
>2x WBQUAD (B1)  i.MX6Q, silicon rev 1.2
>1x Sabre-Lite   i.MX6Q, silicon rev 1.0
>2x Sabre-Lite   i.MX6Q, silicon rev 1.2
>2x RIoTboard i.MX6Solo, silicon rev 1.1
>1x MarSBoard i.MX6Dual, silicon rev 1.2 (I haven't posted the dts for
>this yet)
>
>all with the GPIO_6 interrupt patch in place, no cameras or anything
>else 
>connected to that pad, no issues seen on 3.15 or 3.16 
>
>I had seen problems on earlier kernels, before the GPIO_6 workaround
>was 
>implemented, where one of my Sabre-Lite boards (only one, and always
>the 
>same one) would vanish off the network for a few minutes. I'd even had
>it 
>happen while in the middle of typing something over an ssh connection.
>Connectivity usually seemed to recover on it's own eventually, or I 
>could log in over a serial connection and ping something else on the 
>network which would restore the connection immediately.
>After the GPIO_6 workaround was implemented I've never had the problem 
>re-occur.
>
>I use the two wandboards and the three sabre-lites as builders with 
>distcc and nfs in the mix, so network issues usually show up fairly 
>quickly.
>
>Iain

I've always had ethernet problems with my Wandboards. Especially when I hadn't increased the TX_RING_SIZE in the fec driver. I'm pretty sure I've been using the GPIO_6 patch for a long time since I always patch my kernels with Robert C. Nelson's ARM patch collection. Now that I've removed the patch (on Kernel 3.16.0) the problems seem to have an end.

I've also experienced your special case with one of my Wandboard quads where it would loose the connection every minute or so but would restore it when sending some data by itself, e.g. a ping. I worked around this by installing a systemd timer which did exactly that.

Tom

[BUG]: imx6q (wandboard): Very unstable ethernet since kernel 3.16

[Alexander Holler]

Am 11.08.2014 07:24, schrieb Thomas Scheiblauer:
> On 11. August 2014 00:36:45 MESZ, Iain Paton <ipaton0@gmail.com> wrote:
>> On 09/08/14 01:33, Troy Kisky wrote:
>>> On 8/8/2014 3:51 PM, George Joseph wrote:
>>>> On Fri, Aug 8, 2014 at 4:02 PM, Troy Kisky

>>>> I'm confused by the references to GPIO_6 and GPIO1_IO06 as it
>> relates to the wandboard.   According
>>>> to the schematic for both the rev B1 and C1, the GPIO_6 PAD is
>> physically connected to pin 30 on the
>>>> camera interface and according to the dtb tree, GPIO1_IO06 isn't
>> mapped to any PAD.

I was confused by that too. Unfortunately the patch didn't include some 
comment in the .dts itself, just the commit message. Something I see 
very often. Maybe it helps to tell people that a commit message is no 
replacement for usefull comments in the source. Escpecially for things 
like this one very it isn't obvious why a not connect (and unrelated) 
pin does get some pinmux-settings.

>>>> This kinda fits with my own observation which is that Ethernet is
>> working fine (40MB/s sustained)
>>>> regardless of whether fec is using "gpio1 6" and "intc 0 119" for
>> extended interrupts or the default
>>>> "intc 0 118" and "intc 0 119".   Otherwise stock 3.16.0 on WB Quad
>> C1.
>>>>
>>> Are you using a wandboard also?   With or without camera plugged in?
>>
>> I have:
>>
>> 2x WBQUAD (B1)  i.MX6Q, silicon rev 1.2
>> 1x Sabre-Lite   i.MX6Q, silicon rev 1.0
>> 2x Sabre-Lite   i.MX6Q, silicon rev 1.2
>> 2x RIoTboard i.MX6Solo, silicon rev 1.1
>> 1x MarSBoard i.MX6Dual, silicon rev 1.2 (I haven't posted the dts for
>> this yet)
>>
>> all with the GPIO_6 interrupt patch in place, no cameras or anything
>> else
>> connected to that pad, no issues seen on 3.15 or 3.16
>>
>> I had seen problems on earlier kernels, before the GPIO_6 workaround
>> was
>> implemented, where one of my Sabre-Lite boards (only one, and always
>> the
>> same one) would vanish off the network for a few minutes. I'd even had
>> it
>> happen while in the middle of typing something over an ssh connection.
>> Connectivity usually seemed to recover on it's own eventually, or I
>> could log in over a serial connection and ping something else on the
>> network which would restore the connection immediately.
>> After the GPIO_6 workaround was implemented I've never had the problem
>> re-occur.
>>
>> I use the two wandboards and the three sabre-lites as builders with
>> distcc and nfs in the mix, so network issues usually show up fairly
>> quickly.
>>
>> Iain
>
> I've always had ethernet problems with my Wandboards. Especially when I hadn't increased the TX_RING_SIZE in the fec driver. I'm pretty sure I've been using the GPIO_6 patch for a long time since I always patch my kernels with Robert C. Nelson's ARM patch collection. Now that I've removed the patch (on Kernel 3.16.0) the problems seem to have an end.
>
> I've also experienced your special case with one of my Wandboard quads where it would loose the connection every minute or so but would restore it when sending some data by itself, e.g. a ping. I worked around this by installing a systemd timer which did exactly that.

I've just reverted commit 9fc77821b17155c6e0ab50b1e1dd80c2b0e63e98 in 
3.16.1 and experienced the mentioned stability problem with a Wandboard 
Quad C1.

But I don't know if it's related to that commit at all. I just own this 
board since a few weeks and I'm still just playing with it, trying to 
get all bits together to use it 24/7. That means I'm unsure if it was 
stable without reverting that commit.

Regards,

Alexander Holler