This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/DP83867E: RX symbol&CRC errors reported by ifconfig/ethtool

Part Number: DP83867E

Tool/software: Linux

Using custom board with:
Zynq-7000

Cadence macb driver

TI DP83867 chip/driver

Linux 4.9.0

The TX packets are getting out, but no RX packets received by the operating system.  I am working with playing with the timing delays in the device tree.....ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>

Anyone have issues receiving packets?  Below is output from my device tree and linux commandline displaying rx errors.

/*&adc{*/
/* status="disabled";*/
/*};*/
&gem0 {
phy-handle = <&ethernet_phy>;

status = "okay";
phy-mode = "rgmii-id";

pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gem0_default>;
phy-reset-gpio = <&gpio0 11 0>;
phy-reset-active-low;

xlnx,eth-mode = <0x1>;
fixed-link {
max-speed = <1000>;
ull-duplex;
};

/delete-node/ ethernet-phy@7;

mdio {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
ethernet_phy: ethernet-phy@c {
compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
reg = <0xc>;
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0x8>;
ti,fifo-depth = <0x01>;
ti,min-output-impedance;
ti,dp83867-rxctrl-strap-quirk;
status = "okay";
};
};
};

eth0 Link encap:Ethernet HWaddr 00:0a:35:00:1e:29
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::20a:35ff:fe00:1e29/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:2242 dropped:0 overruns:0 frame:2242
TX packets:2024 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:223326 (218.0 KiB)
Interrupt:29 Base address:0xb000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:1032 (1.0 KiB) TX bytes:1032 (1.0 KiB)

root@xilinx-zc706-2017_2:~# ethtool -S eth0
NIC statistics:
tx_octets: 6018415
tx_frames: 92441
tx_broadcast_frames: 136
tx_multicast_frames: 14
tx_pause_frames: 0
tx_64_byte_frames: 90410
tx_65_127_byte_frames: 1897
tx_128_255_byte_frames: 0
tx_256_511_byte_frames: 134
tx_512_1023_byte_frames: 0
tx_1024_1518_byte_frames: 0
tx_greater_than_1518_byte_frames: 0
tx_underrun: 0
tx_single_collision_frames: 0
tx_multiple_collision_frames: 0
tx_excessive_collisions: 0
tx_late_collisions: 0
tx_deferred_frames: 0
tx_carrier_sense_errors: 0
rx_octets: 50851228
rx_frames: 90624
rx_broadcast_frames: 215
rx_multicast_frames: 0
rx_pause_frames: 0
rx_64_byte_frames: 85
rx_65_127_byte_frames: 50
rx_128_255_byte_frames: 8
rx_256_511_byte_frames: 45
rx_512_1023_byte_frames: 90436
rx_1024_1518_byte_frames: 0
rx_greater_than_1518_byte_frames: 0
rx_undersized_frames: 0
rx_oversize_frames: 0
rx_jabbers: 0
rx_frame_check_sequence_errors: 2249
rx_length_field_frame_errors: 0
rx_symbol_errors: 2249
rx_alignment_errors: 0
rx_resource_errors: 0
rx_overruns: 0
rx_ip_header_checksum_errors: 0
rx_tcp_checksum_errors: 0
rx_udp_checksum_errors: 0

  • Hi Derek,

    I am not sure how ethtool is counting rx_symbol_errors, but if this is pulled from the PHY register address 0x15. If that is this case, this usually indicates your reference clock has high jitter, or the attached link partner has high jitter.

    You mentioned you are not receiving any packets, but ethtool is indicating you received a total of 90624 frames, and 2249 had errors. Is this correct? If you are missing only some packets, and it is related to the RGMII delays, then adjusting the delays should make this error percentage go up.

    Can you provide a schematic of your board?

    Best Regards,
  • , I did misspoke about not receiving packets.   We are definitely receiving them, just not getting them into Linux properly.  We found out that 1) 100Mbps works and 2) we have a bad switch, so for now we are going to use 100M and kick the 1Gbps can down the road.  I'll jot down the high jitter comment in our internal notes.  I'll have to ask around about the schematics, but we plan on moving on.  Still open to any other suggestions.

    Thanks for the support.

    - Derek

  • Hi Derek,

    Glad to hear you found your issue. Another clue that RGMII delays may not be optimal is that 100M works and 1000M does not. The setup and hold time margin with 1000M is very thin due to the DDR nature of the interface. Good luck with the design.

    Best Regards,