Hello,
We decided to upgrade the Linux kernel of our ppc64 product from 3.12.19 to 4.14 using sources taken from Freescale/linux-fscl repository:
https://github.com/Freescale/linux-fslc/tree/4.14.x+fslc
Communication works only partially i.e. packets bigger than certain size do not come through:
ping 10.12.50.122 -s 25153
PING 10.12.50.122 (10.12.50.122) 25153(25181) bytes of data.
--- 10.12.50.122 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6144ms
While adjusting device tree I used example .dts files from linux-fslc and made sure that reserved-memory node is present in order to satisfy driver's external memory requirements.
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
bman_fbpr: bman-fbpr {
size = <0 0x1000000>;
alignment = <0 0x1000000>;
};
qman_fqd: qman-fqd {
size = <0 0x400000>;
alignment = <0 0x400000>;
};
qman_pfdr: qman-pfdr {
size = <0 0x2000000>;
alignment = <0 0x2000000>;
};
};
I also increased FSL_FM_MAX_FRAME_SIZE from 1522 to 1550 because initially even smaller packets were not reaching the destination. Increasing that value helped, but only partially. Further increasing the MTU does not change the behavior.
I added some logs so I can verify on how many fragments packet is fragmented and with smaller values, the number of fragments is OK (packet size/MTU). For bigger packets I can see a really big burst of fragments and then ICMP request stop showing up (I can verify if packet type == ICMP using sk_buff 'type' field which is 8 for ICMP request)
Also, even when I do not ping, some packets are constantly being dropped on the eth1 interface
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1528
inet6 fe80::280:eaff:feb0:2952 prefixlen 64 scopeid 0x20<link>
ether 00:80:ea:b0:29:52 txqueuelen 1000 (Ethernet)
RX packets 349813 bytes 37890813 (36.1 MiB)
RX errors 0 dropped 71985 overruns 0 frame 0
TX packets 228585 bytes 27237102 (25.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xffe4e4000-ffe4e4fff
I added some debug logs and noticed that in the latter case rx_dropped counter is increased in dpaa_eth.c in
function named rx_default_dqrr after calling netif_receive_skb(skb), which goes deep into Linux network internals:
__netif_receive_skb_core, then ip_rcv_finish
Can you help with this?
Arkadiusz Lis
