Link stops working under heavy traffic load connected to a mv88e6176

    can0 = &can1;
    ethernet0 = &fec;

    sky2 = &eth1;

    usdhc2 = &usdhc3;
    mdio-gpio0 = &mdio0;

  mdio0: mdio {
    compatible = "virtual,mdio-gpio";
    #address-cells = <1>;
    #size-cells = <0>;
    /* MDC = gpio-17, MDIO = gpio-20 */
    gpios =  <&gpio1 17 1
        &gpio1 20 0>;
                ethernet-phy@0  {
          compatible = "marvell,dsa";
                };
  };

  dsa {
    compatible = "marvell,dsa";
    #address-cells = <2>;
    #size-cells = <0>;

    interrupts = <10>;
    dsa,ethernet = <&eth1>;
    dsa,mii-bus = <&mdio0>;

    switch@0 {
      #address-cells = <1>;
      #size-cells = <0>;
      reg = <0 0>;  /* MDIO address 0, switch 0 in tree */

      port@0 {
        reg = <0>;
        label = "cpu";
      };

      port@1 {
        reg = <1>;
        label = "eth1";
      };

      port@2 {
        reg = <2>;
        label = "eth2";
      };

      port@3 {
        reg = <3>;
        label = "eth3";
      };

      port@4 {
        reg = <4>;
        label = "eth4";
      };
    };

};

&mdio0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mdio>;
status = "okay";
};

  imx6qdl-gw53xx-mdio {

      >;
    };

    pinctrl_mdio: mdiogrp {
      fsl,pins = <
        MX6QDL_PAD_SD1_DAT1__GPIO1_IO17   0x1b0b9
        MX6QDL_PAD_SD1_CLK__GPIO1_IO20    0x1b0b9

    can0 = &can1;
    ethernet0 = &fec;

    sky2 = &eth1;

    usdhc2 = &usdhc3;
    mdio-gpio0 = &mdio0;

  mdio0: mdio {
    compatible = "virtual,mdio-gpio";
    #address-cells = <1>;
    #size-cells = <0>;
    /* MDC = gpio-17, MDIO = gpio-20 */
    gpios =  <&gpio1 17 1
        &gpio1 20 0>;
                ethernet-phy@0  {
          compatible = "marvell,dsa";
                };
  };

  dsa {
    compatible = "marvell,dsa";
    #address-cells = <2>;
    #size-cells = <0>;

    interrupts = <10>;
    dsa,ethernet = <&eth1>;
    dsa,mii-bus = <&mdio0>;

    switch@0 {
      #address-cells = <1>;
      #size-cells = <0>;
      reg = <0 0>;  /* MDIO address 0, switch 0 in tree */

      port@0 {
        reg = <0>;
        label = "cpu";
      };

      port@1 {
        reg = <1>;
        label = "eth1";
      };

      port@2 {
        reg = <2>;
        label = "eth2";
      };

      port@3 {
        reg = <3>;
        label = "eth3";
      };

      port@4 {
        reg = <4>;
        label = "eth4";
      };
    };

};

&mdio0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mdio>;
status = "okay";
};

  imx6qdl-gw53xx-mdio {

      >;
    };

    pinctrl_mdio: mdiogrp {
      fsl,pins = <
        MX6QDL_PAD_SD1_DAT1__GPIO1_IO17   0x1b0b9
        MX6QDL_PAD_SD1_CLK__GPIO1_IO20    0x1b0b9

We are working in an ARMv7 embedded system running kernel 4.9 (LEDE build). It is an imx6 board with 2 ethernet interfaces. One of them is connected to a Marvell switch.

The schema of the system is the following:

  +-------------------+ eth0
  |                   +--+
  |                   |  |
  | Embedded system   +--+
  |                   |
  |      ARMv7        |
  |                   | Marvell 88E8057(sky2) +-------------+
  |                   +--+ +--+             +--+ eth1
  |                   |  +---------------------+ |             |  +------+
  |                   +--+      CPU port       +--+ mv88e6176  +--+
  +------+--+---------+ |             |
emulated|  | |             |
GPIO    +--+ +--+             +--+ eth2
MDIO      +-----------------------------------+ |             |  +------+
                               MDIO +--+             +--+
+-------------+

There is a bridge (br-lan) which includes eth0/eth1/eth2

If I connect the eth1/eth2, the link is up and I can do ping through it. But, once
I start sending a heavy traffic load the link fails and the kernel sends the following messages:

[   48.557140] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 
length 1518
[   48.564964] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 
length 1518
[   48.572110] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 
length 1518
[   48.579263] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 
length 1518
[   48.586417] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 
length 1518
[   48.593573] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 
length 1518
[   48.600718] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 
length 1518
[   54.877567] net_ratelimit: 6 callbacks suppressed
[   54.882293] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 
length 1518
[   61.413552] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010 

length 1518

Quoted 48 lines · On Fri, 21 Apr 2017 14:39:00 +0200 Rafa Corvillo <[email protected]>…

We are working in an ARMv7 embedded system running kernel 4.9 (LEDE build). It is an imx6 board with 2 ethernet interfaces. One of them is connected to a Marvell switch.

The schema of the system is the following:

   +-------------------+ eth0
   |                   +--+
   |                   |  |
   | Embedded system   +--+
   |                   |
   |      ARMv7        |
   |                   | Marvell 88E8057(sky2) +-------------+
   |                   +--+ +--+             +--+ eth1
   |                   |  +---------------------+ |             |  +------+
   |                   +--+      CPU port       +--+ mv88e6176  +--+
   +------+--+---------+ |             |
emulated|  | |             |
GPIO    +--+ +--+             +--+ eth2
MDIO      +-----------------------------------+ |             |  +------+
                                MDIO +--+             +--+
+-------------+

There is a bridge (br-lan) which includes eth0/eth1/eth2

If I connect the eth1/eth2, the link is up and I can do ping through it. But, once
I start sending a heavy traffic load the link fails and the kernel sends the following messages:

[   48.557140] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.564964] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.572110] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.579263] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.586417] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.593573] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.600718] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   54.877567] net_ratelimit: 6 callbacks suppressed
[   54.882293] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   61.413552] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010

Quoted 1 line

length 1518

The status error bits are in sky2.h
0x5f20010 is
05f2 frame length => 1522
0010 Too long err

That means the packet was longer than the configured MTU. You are probably getting packets with VLAN tag but have not configured a VLAN.

Quoted 9 lines · Stephen Hemminger

Quoted 6 lines · On Fri, 21 Apr 2017 14:39:00 +0200 Rafa Corvillo <[email protected]>…

We are working in an ARMv7 embedded system running kernel 4.9 (LEDE build). It is an imx6 board with 2 ethernet interfaces. One of them is connected to a Marvell switch.

The schema of the system is the following:

Quoted 25 lines

Quoted 24 lines

If I connect the eth1/eth2, the link is up and I can do ping through it. But, once
I start sending a heavy traffic load the link fails and the kernel sends the following messages:

[   48.557140] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.564964] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.572110] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.579263] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.586417] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.593573] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.600718] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   54.877567] net_ratelimit: 6 callbacks suppressed
[   54.882293] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   61.413552] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010

length 1518

Quoted 8 lines

The status error bits are in sky2.h
0x5f20010 is
05f2 frame length => 1522
0010 Too long err

That means the packet was longer than the configured MTU. You are probably getting packets with VLAN tag but have not configured a VLAN.

Thanks for the information. I have increased the MTU value to 1550 (workaround) and it works if sends traffic (with iperf) from my computer to the unit. But, if I send traffic outside the unit, I get a new error message and link goes down:

[ 4901.032989] sky2 0000:04:00.0 marvell: tx timeout
[ 4904.722670] sky2 0000:04:00.0 marvell: Link is up at 1000 Mbps,

full duplex, flow control both

Quoted 8 lines · Rafa Corvillo

Quoted 7 lines · Stephen Hemminger

Quoted 4 lines · On Fri, 21 Apr 2017 14:39:00 +0200 Rafa Corvillo <[email protected]>…

We are working in an ARMv7 embedded system running kernel 4.9 (LEDE build). It is an imx6 board with 2 ethernet interfaces. One of them is connected to a Marvell switch.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

The schema of the system is the following:

Hi Rafa

Your ASCII art got messed up somewhere. Is this the correct reconstruction?

    +-------------------+ eth0
    |                   +--+
    |                   |  |
    | Embedded system   +--+
    |                   |
    |      ARMv7        |
    |                   | Marvell 88E8057(sky2)     +-------------+
    |                   +--+                     +--+             +--+ eth1
    |                   |  +---------------------+  |             |  +------+
    |                   +--+      CPU port       +--+ mv88e6176   +--+
    +------+--+---------+                           |             |
emulated  |  |                                     |             |
GPIO      +--+                                  +--+             +--+ eth2
MDIO       +-----------------------------------+   |             |  +------+
                                 MDIO            +--+             +--+
                                                    +-------------+

I assume you are using DSA? Since this is LEDE, it could be swconfig, but the bridge configuration you mentioned would not make sense for swconfig.

Quoted 31 lines

Quoted 31 lines

Quoted 24 lines

If I connect the eth1/eth2, the link is up and I can do ping through it. But, once
I start sending a heavy traffic load the link fails and the kernel sends the following messages:

[   48.557140] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.564964] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.572110] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.579263] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.586417] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.593573] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   48.600718] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   54.877567] net_ratelimit: 6 callbacks suppressed
[   54.882293] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010
length 1518
[   61.413552] sky2 0000:04:00.0 marvell: rx error, status 0x5f20010

Quoted 1 line

length 1518

The status error bits are in sky2.h
0x5f20010 is
05f2 frame length => 1522
0010 Too long err

Quoted 3 lines

Quoted 3 lines

That means the packet was longer than the configured MTU. You are probably getting packets with VLAN tag but have not configured a VLAN.

Since you are using DSA, you will have DSA tags enabled on frames to/from the switch. This adds an extra 8 byte header in the frame. My guess is, it is this header, not the VLAN tag which is causing you MTU issues.

I think this is the first time i've seen sky2 used in a DSA setup. mv643xx or mvneta is generally what is used, when using Marvell chipsets. These drivers are more lenient about MTU, and are happy to pass frames with additional headers.

Quoted 4 lines

Thanks for the information. I have increased the MTU value to 1550 (workaround) and it works if sends traffic (with iperf) from my computer to the unit. But, if I send traffic outside the unit, I get a new error message and link goes down:

Changing the MTU like this is not a good fix. It will allow you to receive frames which are bigger, but it also means the local network stack will generate bigger frames to be transmitted. You probably need to modify the sky2 driver to allow it to receive frames bigger than the interface MTU, by about 8 bytes.

Quoted 4 lines

[ 4901.032989] sky2 0000:04:00.0 marvell: tx timeout
[ 4904.722670] sky2 0000:04:00.0 marvell: Link is up at 1000 Mbps,

full duplex, flow control both

Between the sky2 and the switch, do you have two back-to-back PHYs or are you connecting the RGMII interfaces together?

Andrew

Quoted 4 lines

Since you are using DSA, you will have DSA tags enabled on frames to/from the switch. This adds an extra 8 byte header in the frame. My guess is, it is this header, not the VLAN tag which is causing you MTU issues.

But it is strange because, as I have said above, we have the same configuration working properly on a kernel 4.1 (with OpenWrt), and we have the MTU set to 1500.

Quoted 5 lines

I think this is the first time i've seen sky2 used in a DSA setup. mv643xx or mvneta is generally what is used, when using Marvell chipsets. These drivers are more lenient about MTU, and are happy to pass frames with additional headers.

We use the mv88e6xxx (as our switch is mv88e6176) and it depends on DSA driver in the kernel (isn't it?).

Quoted 5 lines

Changing the MTU like this is not a good fix. It will allow you to receive frames which are bigger, but it also means the local network stack will generate bigger frames to be transmitted. You probably need to modify the sky2 driver to allow it to receive frames bigger than the interface MTU, by about 8 bytes.

Should the DSA driver remove the DSA tags before pass the frames to sky2 interface?

Quoted 6 lines

Quoted 3 lines

[ 4901.032989] sky2 0000:04:00.0 marvell: tx timeout
[ 4904.722670] sky2 0000:04:00.0 marvell: Link is up at 1000 Mbps,

full duplex, flow control both

Between the sky2 and the switch, do you have two back-to-back PHYs or are you connecting the RGMII interfaces together?

I think that we have two back-to-back PHYs, but I am going to double check this with the hardware team.

Quoted 8 lines

Quoted 4 lines

Since you are using DSA, you will have DSA tags enabled on frames to/from the switch. This adds an extra 8 byte header in the frame. My guess is, it is this header, not the VLAN tag which is causing you MTU issues.

But it is strange because, as I have said above, we have the same configuration working properly on a kernel 4.1 (with OpenWrt), and we have the MTU set to 1500.

If you look at sky2.c:

static unsigned sky2_get_rx_threshold(struct sky2_port *sky2)

{
         unsigned size;

         /* Space needed for frame data + headers rounded up */
         size = roundup(sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN, 8);

         /* Stopping point for hardware truncation */
         return (size - 8) / sizeof(u32);
}

This is not going to be big enough for a frame with a DSA header.

Quoted 8 lines

Quoted 5 lines

I think this is the first time i've seen sky2 used in a DSA setup. mv643xx or mvneta is generally what is used, when using Marvell chipsets. These drivers are more lenient about MTU, and are happy to pass frames with additional headers.

We use the mv88e6xxx (as our switch is mv88e6176) and it depends on DSA driver in the kernel (isn't it?).

That is correct. But i was talking about the Ethernet interface. All the designs i've seen use an mv643xxx Ethernet interface, or an mvneta interface. This is the first time i've seen a sky2 used, which is why i'm not too surprised you have issues.

Quoted 8 lines

Quoted 5 lines

Changing the MTU like this is not a good fix. It will allow you to receive frames which are bigger, but it also means the local network stack will generate bigger frames to be transmitted. You probably need to modify the sky2 driver to allow it to receive frames bigger than the interface MTU, by about 8 bytes.

Should the DSA driver remove the DSA tags before pass the frames to sky2 interface?

The DSA driver is adding the DSA tags to the frame and passing these tagged frames to the sky2 interface. Frames going to/from the switch will always have such tags.

Quoted 9 lines

Quoted 6 lines

Quoted 3 lines

[ 4901.032989] sky2 0000:04:00.0 marvell: tx timeout
[ 4904.722670] sky2 0000:04:00.0 marvell: Link is up at 1000 Mbps,

full duplex, flow control both

Between the sky2 and the switch, do you have two back-to-back PHYs or are you connecting the RGMII interfaces together?

I think that we have two back-to-back PHYs, but I am going to double check this with the hardware team.

This could be your problem them. The mv88e6xxx switch driver assumes there is a straight rgmii-rgmii connection, no PHYs. So it hard configures the 'CPU' port to its fastest speed, with the link forced up. If you actually have a PHY there, this might not work so well. I don't know if the switch PHY is going to do autoneg correctly. Try using ethtool to look at the sky2 PHY and see what state it is in.

Andrew

Quoted 7 lines

static unsigned sky2_get_rx_threshold(struct sky2_port *sky2)

{
        unsigned size;

        /* Space needed for frame data + headers rounded up */
        size = roundup(sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN, 8);

Quoted 6 lines

        /* Stopping point for hardware truncation */
        return (size - 8) / sizeof(u32);
}

This is not going to be big enough for a frame with a DSA header.

Then, would be a good fix add 8 bytes to the size variable in this function?

Settings for marvell:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal

Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: d
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup
rx_err tx_err
Link detected: yes

Quoted 11 lines

Quoted 11 lines

static unsigned sky2_get_rx_threshold(struct sky2_port *sky2)

{
         unsigned size;

         /* Space needed for frame data + headers rounded up */
         size = roundup(sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN, 8);

         /* Stopping point for hardware truncation */
         return (size - 8) / sizeof(u32);
}

Quoted 4 lines

Quoted 2 lines

This is not going to be big enough for a frame with a DSA header.

Then, would be a good fix add 8 bytes to the size variable in this function?

Yes. Also look at the transmit code, is there again a limit based on the MTU.

Quoted 18 lines

Settings for marvell:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal

Quoted 9 lines

Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: d
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup
rx_err tx_err
Link detected: yes

So this suggests there is a real PHY there, and it is auto-negotiating.

What we cannot see is the status for the PHY it connects to. But since this PHY has established a link, the other PHY is probably O.K. It is just a bit unsafe, since you are relying on reset behaviour. There is nothing in software configuring the second PHY to make it auto-negotiate.

Andrew

Adding 8 bytes (sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN + 8 (EDSA_HLEN)) does not fix the error, because the interface keep having a maximum length of 1518 bytes (sky2->netdev->mtu + ETH_HLEN
+ VLAN_HLEN).

Quoted 4 lines

Adding 8 bytes (sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN + 8 (EDSA_HLEN)) does not fix the error, because the interface keep having a maximum length of 1518 bytes (sky2->netdev->mtu + ETH_HLEN
+ VLAN_HLEN).

Did you check the value being written to here:

         /*
          * The receiver hangs if it receives frames larger than the
          * packet buffer. As a workaround, truncate oversize frames, but
          * the register is limited to 9 bits, so if you do frames > 2052
          * you better get the MTU right!
          */
         thresh = sky2_get_rx_threshold(sky2);
         if (thresh > 0x1ff)
                 sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_OFF);
         else {
                 sky2_write16(hw, SK_REG(sky2->port, RX_GMF_TR_THR), thresh);
                 sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_ON);
         }

What is thresh?

Andrew

Quoted 22 lines

Quoted 4 lines

Adding 8 bytes (sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN + 8 (EDSA_HLEN)) does not fix the error, because the interface keep having a maximum length of 1518 bytes (sky2->netdev->mtu + ETH_HLEN
+ VLAN_HLEN).

Did you check the value being written to here:

        /*
         * The receiver hangs if it receives frames larger than the
         * packet buffer. As a workaround, truncate oversize frames, but
         * the register is limited to 9 bits, so if you do frames > 2052
         * you better get the MTU right!
         */
        thresh = sky2_get_rx_threshold(sky2);
        if (thresh > 0x1ff)
                sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_OFF);
        else {
                sky2_write16(hw, SK_REG(sky2->port, RX_GMF_TR_THR), thresh);
                sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_ON);
        }

Quoted 1 line

What is thresh?

The value of thresh is 380.

Quoted 22 lines

Quoted 22 lines

Quoted 4 lines

Adding 8 bytes (sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN + 8 (EDSA_HLEN)) does not fix the error, because the interface keep having a maximum length of 1518 bytes (sky2->netdev->mtu + ETH_HLEN
+ VLAN_HLEN).

Did you check the value being written to here:

         /*
          * The receiver hangs if it receives frames larger than the
          * packet buffer. As a workaround, truncate oversize frames, but
          * the register is limited to 9 bits, so if you do frames > 2052
          * you better get the MTU right!
          */
         thresh = sky2_get_rx_threshold(sky2);
         if (thresh > 0x1ff)
                 sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_OFF);
         else {
                 sky2_write16(hw, SK_REG(sky2->port, RX_GMF_TR_THR), thresh);
                 sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_ON);
         }

Quoted 3 lines

Quoted 1 line

What is thresh?

The value of thresh is 380.

So that is 1528.

You could hack it and try 0x1ff.

Also, check that in sky2_rx_add(), le->length is set to 4K.

Quoted 2 lines

Also, check that in sky2_rx_add(), le->length is set to 4K.

The value of le->length is set to 1520.

Rafa

Quoted 4 lines

Quoted 2 lines

Also, check that in sky2_rx_add(), le->length is set to 4K.

The value of le->length is set to 1520.

Quoted 1 line

Rafa

Ah.

You probably need to change sky2_get_rx_data_size() as well, to add in the extra 8 bytes.

Andrew

As modifying sky2 code I have not could get any solution, then I have modified some parameters on the ethernet interface and using a MTU = 1503 and disabling TSO (TCP Segmentation Offload) mechanism all communication errors disappear, both the rx errors due to too long packets and tx timeout errors.