<div dir="ltr">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.<div><br></div><div><div>I had to give the Eth0 a manual IP due to not responding on DHCP requests.</div><div><br></div><div>I can ping my Gateway, and even DNS queries work..</div><div><br></div><div>But when i start Netsurf (or generate to much packets)... all traffic dies.... due to No buffer space available..</div><div><br></div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=81 ttl=255 time=0.317 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=82 ttl=255 time=0.317 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=83 ttl=255 time=0.314 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=84 ttl=255 time=0.321 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=85 ttl=255 time=0.323 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=86 ttl=255 time=0.312 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=87 ttl=255 time=0.331 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=88 ttl=255 time=0.338 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=89 ttl=255 time=0.334 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=90 ttl=255 time=0.349 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=91 ttl=255 time=0.324 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=92 ttl=255 time=0.320 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=93 ttl=255 time=0.320 ms</div><div>64 bytes from <a href="http://192.168.22.66">192.168.22.66</a>: icmp_seq=94 ttl=255 time=0.338 ms</div><div>ping: sendmsg: No buffer space available</div><div>ping: sendmsg: No buffer space available</div><div>ping: sendmsg: No buffer space available</div><div>ping: sendmsg: No buffer space available</div><div>ping: sendmsg: No buffer space available</div><div>ping: sendmsg: No buffer space available</div><div>ping: sendmsg: No buffer space available</div><div>ping: sendmsg: No buffer space available</div></div><div><br></div><div><div>A workaround to keep Eth0 alive a bit longer.... is the following command </div><div><br></div><div>ip link set eth0 qlen 10000</div></div><div><br></div><div>We are making progress!!</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 17, 2018 at 12:47 PM, Joakim Tjernlund <span dir="ltr"><<a href="mailto:Joakim.Tjernlund@infinera.com" target="_blank">Joakim.Tjernlund@infinera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:<br>
> 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.<br>
><br>
><br>
> > > You appear to be using an old kernel. Take a look at:<br>
> ><br>
> > Not really, I am using 4.14.x and I don't think that is old.<br>
><br>
> Development for 4.14 stopped somewhere around the beginning of<br>
> September. So there has been over 4 months of work since then.  We are<br>
> clearly interested in fixing bugs in that kernel, since it is the<br>
> current stable version. But when reporting bugs, please let is know if<br>
> the latest version of the network kernel,<br>
> it://<a href="http://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git" rel="noreferrer" target="_blank">git.kernel.org/pub/scm/<wbr>linux/kernel/git/davem/net-<wbr>next.git</a> has<br>
> the issue.<br>
><br>
> > Seems like this patch hasn't been sent to 4.14.x.<br>
><br>
> If it fixes a bug for you, please request the fix is added to stable.<br>
<br>
That doesn't work really, having users to hit the bug, debug it, fix it and then<br>
find it fixed already in upstream, then specifically request it to be backported to stable.<br>
I don't need this fix to be backported, already got it. Someone else might though.<br>
<br>
I would be interested in bug fixes upstream which fixes:<br>
<br>
libphy: Freescale XGMAC MDIO Bus: probed<br>
iommu: Adding device ffe488000.port to group 10<br>
libphy: Freescale XGMAC MDIO Bus: probed<br>
mdio_bus ffe4e1000: Error while reading PHY0 reg at 3.3<br>
iommu: Adding device ffe489000.port to group 22<br>
libphy: Freescale XGMAC MDIO Bus: probed<br>
mdio_bus ffe4e3000: Error while reading PHY0 reg at 3.3<br>
iommu: Adding device ffe48a000.port to group 23<br>
libphy: Freescale XGMAC MDIO Bus: probed<br>
mdio_bus ffe4e5000: Error while reading PHY0 reg at 3.3<br>
iommu: Adding device ffe48b000.port to group 24<br>
libphy: Freescale XGMAC MDIO Bus: probed<br>
mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3<br>
iommu: Adding device ffe48c000.port to group 25<br>
libphy: Freescale XGMAC MDIO Bus: probed<br>
mdio_bus ffe4e9000: Error while reading PHY0 reg at 3.3<br>
fsl_mac ffe4e2000.ethernet: FMan MEMAC<br>
fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20<br>
fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed<br>
fsl_mac: probe of dpaa-ethernet.0 failed with error -16<br>
fsl_mac ffe4e4000.ethernet: FMan MEMAC<br>
fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21<br>
fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed<br>
fsl_mac: probe of dpaa-ethernet.1 failed with error -16<br>
fsl_mac ffe4e6000.ethernet: FMan MEMAC<br>
fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22<br>
fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed<br>
<br>
Every FMAN eth I/F with a fixed link fails mysteriously.<br>
Custom board based on t1040rdb, been over the device tree and I cannot find any significant<br>
changes.<br>
<br>
 Jocke</blockquote></div><br></div>