Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176

[Rafa Corvillo <rafael.corvillo@aoifes.com>]

On 08/05/17 14:38, Andrew Lunn wrote:
>>> 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.
>>>
>>
>> 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.

Hi 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).

The polling function of sky2 driver (sky2_poll) calls to the function 
sky2_status_intr (with the parameter struct sky2_hw *hw). The 
sky2_status_intr function gets the status of the list elements (struct 
sky2_status_le) from the sky2_hw parameter and, from the sky2_status_le, 
gets the maximum length (1518) and the status code (0x5f20010). When the 
latter function (sky2_status_intr) calls to the sky2_receive function 
with the parameters length and status, it reports about the error (rx 
error, status 0x5f20010
length 1518).

I don't know who sets the maximum length (1518) and the status code 
(0x5f20010) of the packets. Is it possible that these values to be set 
outside the sky2 code?

Thanks,

Rafa

>
>> 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
>>
>
> 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
>
>