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

[Thomas Scheiblauer]

On 11. August 2014 00:36:45 MESZ, Iain Paton <ipaton0 at 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 at boundarydevices.com
>>> <mailto:troy.kisky at 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 at 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