Thread (42 messages) 42 messages, 6 authors, 2018-02-07

Re: DPAA Ethernet traffice troubles with Linux kernel

flat view

From: mad skateman <hidden>
Date: 2018-01-17 12:06:45
Also in: netdev

After using the new compiled 4.14 rc8 kernel without PAMU support posted by
Christian Zigotzky the X5000 can use the Network interface with some minor
issues.

I had to give the Eth0 a manual IP due to not responding on DHCP requests.

I can ping my Gateway, and even DNS queries work..

But when i start Netsurf (or generate to much packets)... all traffic
dies.... due to No buffer space available..

64 bytes from 192.168.22.66: icmp_seq=81 ttl=255 time=0.317 ms
64 bytes from 192.168.22.66: icmp_seq=82 ttl=255 time=0.317 ms
64 bytes from 192.168.22.66: icmp_seq=83 ttl=255 time=0.314 ms
64 bytes from 192.168.22.66: icmp_seq=84 ttl=255 time=0.321 ms
64 bytes from 192.168.22.66: icmp_seq=85 ttl=255 time=0.323 ms
64 bytes from 192.168.22.66: icmp_seq=86 ttl=255 time=0.312 ms
64 bytes from 192.168.22.66: icmp_seq=87 ttl=255 time=0.331 ms
64 bytes from 192.168.22.66: icmp_seq=88 ttl=255 time=0.338 ms
64 bytes from 192.168.22.66: icmp_seq=89 ttl=255 time=0.334 ms
64 bytes from 192.168.22.66: icmp_seq=90 ttl=255 time=0.349 ms
64 bytes from 192.168.22.66: icmp_seq=91 ttl=255 time=0.324 ms
64 bytes from 192.168.22.66: icmp_seq=92 ttl=255 time=0.320 ms
64 bytes from 192.168.22.66: icmp_seq=93 ttl=255 time=0.320 ms
64 bytes from 192.168.22.66: icmp_seq=94 ttl=255 time=0.338 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

A workaround to keep Eth0 alive a bit longer.... is the following command

ip link set eth0 qlen 10000

We are making progress!!


On Wed, Jan 17, 2018 at 12:47 PM, Joakim Tjernlund <
Joakim.Tjernlund@infinera.com> wrote:
On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:
quoted
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe.
quoted
quoted
quoted
You appear to be using an old kernel. Take a look at:
Not really, I am using 4.14.x and I don't think that is old.
Development for 4.14 stopped somewhere around the beginning of
September. So there has been over 4 months of work since then.  We are
clearly interested in fixing bugs in that kernel, since it is the
current stable version. But when reporting bugs, please let is know if
the latest version of the network kernel,
it://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git has
the issue.
quoted
Seems like this patch hasn't been sent to 4.14.x.
If it fixes a bug for you, please request the fix is added to stable.
That doesn't work really, having users to hit the bug, debug it, fix it
and then
find it fixed already in upstream, then specifically request it to be
backported to stable.
I don't need this fix to be backported, already got it. Someone else might
though.

I would be interested in bug fixes upstream which fixes:

libphy: Freescale XGMAC MDIO Bus: probed
iommu: Adding device ffe488000.port to group 10
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e1000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe489000.port to group 22
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e3000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48a000.port to group 23
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e5000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48b000.port to group 24
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
iommu: Adding device ffe48c000.port to group 25
libphy: Freescale XGMAC MDIO Bus: probed
mdio_bus ffe4e9000: Error while reading PHY0 reg at 3.3
fsl_mac ffe4e2000.ethernet: FMan MEMAC
fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20
fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
fsl_mac: probe of dpaa-ethernet.0 failed with error -16
fsl_mac ffe4e4000.ethernet: FMan MEMAC
fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed
fsl_mac: probe of dpaa-ethernet.1 failed with error -16
fsl_mac ffe4e6000.ethernet: FMan MEMAC
fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed

Every FMAN eth I/F with a fixed link fails mysteriously.
Custom board based on t1040rdb, been over the device tree and I cannot
find any significant
changes.

 Jocke
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help