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.tjernl...@infinera.com> wrote: > On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote: > > 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. > > > > > > > > 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. > > > > > 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
