netdev - Re: DSA mv88e6xxx RX frame errors and TCP/IP RX failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ+vNU0dq-ULUj3PbQH_biGviJURj2z5McCXx_vYxcB0k94WkA@mail.gmail.com>
Date:   Thu, 31 Aug 2017 08:37:47 -0700
From:   Tim Harvey <tharvey@...eworks.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev <netdev@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Fugang Duan <fugang.duan@....com>,
        Ilia Mirkin <imirkin@...m.mit.edu>
Subject: Re: DSA mv88e6xxx RX frame errors and TCP/IP RX failure

On Wed, Aug 30, 2017 at 6:46 PM, Andrew Lunn <andrew@...n.ch> wrote:
>> >                        /* Report late collisions as a frame error. */
>> >                         if (status & (BD_ENET_RX_NO | BD_ENET_RX_CL))
>> >                                 ndev->stats.rx_frame_errors++;
>> >
>> > I don't see anywhere else frame errors are counted, but it would be
>> > good to prove we are looking in the right place.
>> >
>>
>> Andrew,
>>
>> (adding IMX FEC driver maintainer to CC)
>>
>> Yes, that's one of them being hit. It looks like ifconfig reports
>> 'frame' as the accumulation of a few stats so here are some more
>> specifics from /sys/class/net/eth0/statistics:
>>
>> root@...ial:/sys/devices/soc0/soc/2100000.aips-bus/2188000.ethernet/net/eth0/statistics#
>> for i in `ls rx_*`; do echo $i:$(cat $i); done
>> rx_bytes:103229
>> rx_compressed:0
>> rx_crc_errors:22
>> rx_dropped:0
>> rx_errors:22
>> rx_fifo_errors:0
>> rx_frame_errors:22
>> rx_length_errors:22
>> rx_missed_errors:0
>> rx_nohandler:0
>> rx_over_errors:0
>> rx_packets:1174
>> root@...ial:/sys/devices/soc0/soc/2100000.aips-bus/2188000.ethernet/net/eth0/statistics#
>> ifconfig eth0
>> eth0      Link encap:Ethernet  HWaddr 00:D0:12:41:F3:E7
>>           inet6 addr: fe80::2d0:12ff:fe41:f3e7/64 Scope:Link
>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>           RX packets:1207 errors:22 dropped:0 overruns:0 frame:66
>>           TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:1000
>>           RX bytes:106009 (103.5 KiB)  TX bytes:4604 (4.4 KiB)
>>
>> Instrumenting fec driver I see the following getting hit:
>>
>> status & BD_ENET_RX_LG /* rx_length_errors: Frame too long */
>> status & BD_ENET_RX_CR  /* rx_crc_errors: CRC Error */
>> status & BD_ENET_RX_CL /* rx_frame_errors: Collision? */
>>
>> Is this a frame size issue where the MV88E6176 is sending frames down
>> that exceed the MTU because of headers added?
>
> I did fix an issue recently with that. See
>
> commit fbbeefdd21049fcf9437c809da3828b210577f36
> Author: Andrew Lunn <andrew@...n.ch>
> Date:   Sun Jul 30 19:36:05 2017 +0200
>
>     net: fec: Allow reception of frames bigger than 1522 bytes
>
>     The FEC Receive Control Register has a 14 bit field indicating the
>     longest frame that may be received. It is being set to 1522. Frames
>     longer than this are discarded, but counted as being in error.
>
>     When using DSA, frames from the switch has an additional header,
>     either 4 or 8 bytes if a Marvell switch is used. Thus a full MTU frame
>     of 1522 bytes received by the switch on a port becomes 1530 bytes when
>     passed to the host via the FEC interface.
>
>     Change the maximum receive size to 2048 - 64, where 64 is the maximum
>     rx_alignment applied on the receive buffer for AVB capable FEC
>     cores. Use this value also for the maximum receive buffer size. The
>     driver is already allocating a receive SKB of 2048 bytes, so this
>     change should not have any significant effects.
>
>     Tested on imx51, imx6, vf610.
>
>     Signed-off-by: Andrew Lunn <andrew@...n.ch>
>     Signed-off-by: David S. Miller <davem@...emloft.net>
>
>
> However, this is was of an all/nothing problem. All frames with the
> full MTU were getting dropped, where as i think you are only seeing a
> few dropped?
>

Andrew,

Indeed this does resolve the issue. I see a burst of FIFO overruns
initially when receiving an iperf bandwidth test but that would be
caused by the IMX6 errata and should be mitigated via pause frames.
After that short burst I see no other errors and iperf works fine.

Should we get this patch in the linux-stable tree for the 4.9 kernel?

Thanks!

Tim