subject:"RE\: DPAA Ethernet traffice troubles with Linux kernel"

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-02-07 Thread Christian Zigotzky

Hi Andrew,

How can we fix the buffer problem?

Thanks,
Christian


On 7. Feb 2018, at 22:17, Andrew Lunn  wrote:

On Wed, Feb 07, 2018 at 10:00:45PM +0100, mad skateman wrote:
Hi,

I just found out that something goes wrong within the ARP table (well thats
what i think). I hope someone has a clue..

——

This looks like 'normal' behaviour. It has been reported that the
device runs out of buffers. That means it will fail to receive ARP
replies. So the ARP entry will time out and be removed, as it should.

Fix the buffer problem, and ARP will likely work properly.

   Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-02-07 Thread mad skateman

Hi,

I just found out that something goes wrong within the ARP table (well thats
what i think). I hope someone has a clue..

When i bootup the AmigaOne X5000 with the Ethernet cable connected, it just
never senses the presence of the UTP cable.
I must run the following command as root: mii-tool -R eth0 ... it Resets
the transceiver and the ethernet connection is ready to go.
But then... it randomly dies

After some digging i found that in a working situation the ARP table is
filled with the correct info. Router address, and corresponding MAC, C mask
and Interface.

(Working)
skateman@X5000LNX:~$ arp -n
Address  HWtype  HWaddress   Flags Mask
Iface
192.168.22.66ether   08:5b:0e:fd:db:6a   C
eth0

No more traffic..it just suddenly dies...
skateman@X5000LNX:~$ ping www.google.com
ping: unknown host www.google.com

Rechecked the ARP... and found out it has lost the necessary info.
skateman@X5000LNX:~$ arp -n
Address  HWtype  HWaddress   Flags Mask
Iface
192.168.22.66(incomplete)
eth0

Anyone??? :-)


On Tue, Feb 6, 2018 at 12:20 PM, Christian Zigotzky <chzigot...@xenosoft.de>
wrote:

> Hello,
>
> I have tried to figure out why there is a problem with the buffer space
> but unfortunately without any success. Any ideas? Could you please watch
> Skateman's video? [1]
>
> Thanks,
> Christian
>
> [1] https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
>
>
> On 03 February 2018 at 12:54PM, mad skateman wrote:
> >
> > For those interested... i have recorded a video of my X5000 DPAA
> Ethernet, and the weird problems..
> > In this Video i am also transfering hundereds of megabytes from my NAS
> to the X5000.
> > You will also see pings die... mostly after the 12th packet and giving
> the no buffer space error..
> > Hopefully someone might have a clue about what is happening.
> >
> > https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
> >
> > On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur <
> madalin.bu...@nxp.com> wrote:
> >
> > > -Original Message-
> > > From: Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:25 PM
> > > To: David S . Miller <da...@davemloft.net>
> > > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > > madskate...@gmail.com; 'Madalin-cristian Bucur' <
> madalin.bu...@nxp.com>;
> > > Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
> > > <joakim.tjernl...@infinera.com>
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > -Original Message-
> > > > From: netdev-ow...@vger.kernel.org [mailto:
> netdev-ow...@vger.kernel.org]
> > > > On Behalf Of Madalin-cristian Bucur
> > > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > > To: Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
> > > > <joakim.tjernl...@infinera.com>
> > > > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > > > madskate...@gmail.com; David S . Miller <da...@davemloft.net>
> > > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > -Original Message-
> > > > > From: Andrew Lunn [mailto:and...@lunn.ch]
> > > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > > To: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > > >
> > > > > > 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.
> > > > >
> > > > > The "someone else might though" is a big point of asking for
> it to
> > > > > added to stable. The other reason is it means one less patch
> you need
> > > > > to maintain in your build.
> > > >
> > > > I've sent that patch [1] for net but I guess the timing was
> wrong and
> > > > it was merged to net-next.
> > > >
> > > > > > I would be interested in bug fixes upstream which fixes:
> > > > >
> > > > > Did you try upstream? Does it give the same errors?
> > > > >
> > > > > Andrew
> > > >
> > > > [1] https://patchwork.kernel.org/patch/10146119/
> > > >
> > > > Madalin
> > >
> > > Hi Dave,
> > >
> > > Can you please add the fix [1] to stable?
> > >
> > > Thank you,
> > > Madalin
> >
> > Sorry,
> >
> > I've provided the wrong link towards the patch (v1 instead of v3),
> > here's the correct one:
> >
> > https://patchwork.kernel.org/patch/10151969/
> >
> > Madalin
> >
> >
>
>
>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-02-07 Thread Andrew Lunn

On Wed, Feb 07, 2018 at 10:00:45PM +0100, mad skateman wrote:
> Hi,
> 
> I just found out that something goes wrong within the ARP table (well thats
> what i think). I hope someone has a clue..

This looks like 'normal' behaviour. It has been reported that the
device runs out of buffers. That means it will fail to receive ARP
replies. So the ARP entry will time out and be removed, as it should.

Fix the buffer problem, and ARP will likely work properly.

Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-02-06 Thread Christian Zigotzky


Hello,

I have tried to figure out why there is a problem with the buffer space 
but unfortunately without any success. Any ideas? Could you please watch 
Skateman's video? [1]


Thanks,
Christian

[1] https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view


On 03 February 2018 at 12:54PM, mad skateman wrote:
>
> For those interested... i have recorded a video of my X5000 DPAA 
Ethernet, and the weird problems..
> In this Video i am also transfering hundereds of megabytes from my 
NAS to the X5000.
> You will also see pings die... mostly after the 12th packet and 
giving the no buffer space error..

> Hopefully someone might have a clue about what is happening.
>
> https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
>
> On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur 
<madalin.bu...@nxp.com> wrote:

>
> > -Original Message-
> > From: Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:25 PM
> > To: David S . Miller <da...@davemloft.net>
> > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > madskate...@gmail.com; 'Madalin-cristian Bucur' 
<madalin.bu...@nxp.com>;

> > Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
>     > <joakim.tjernl...@infinera.com>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -Original Message-
> > > From: netdev-ow...@vger.kernel.org 
[mailto:netdev-ow...@vger.kernel.org]

> > > On Behalf Of Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > To: Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
> > > <joakim.tjernl...@infinera.com>
> > > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > > madskate...@gmail.com; David S . Miller <da...@davemloft.net>
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
>     > > > -Original Message-
>     > > > From: Andrew Lunn [mailto:and...@lunn.ch]
> > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > To: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > 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.
> > > >
> > > > The "someone else might though" is a big point of asking 
for it to
> > > > added to stable. The other reason is it means one less 
patch you need

> > > > to maintain in your build.
> > >
> > > I've sent that patch [1] for net but I guess the timing was 
wrong and

> > > it was merged to net-next.
> > >
> > > > > I would be interested in bug fixes upstream which fixes:
> > > >
> > > > Did you try upstream? Does it give the same errors?
> > > >
> > > > Andrew
> > >
> > > [1] https://patchwork.kernel.org/patch/10146119/
> > >
> > > Madalin
> >
> > Hi Dave,
> >
> > Can you please add the fix [1] to stable?
> >
> > Thank you,
> > Madalin
>
> Sorry,
>
> I've provided the wrong link towards the patch (v1 instead of v3),
> here's the correct one:
>
> https://patchwork.kernel.org/patch/10151969/
>
> Madalin
>
>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-02-03 Thread mad skateman

For those interested... i have recorded a video of my X5000 DPAA Ethernet,
and the weird problems..
In this Video i am also transfering hundereds of megabytes from my NAS to
the X5000.
You will also see pings die... mostly after the 12th packet and giving the
no buffer space error..
Hopefully someone might have a clue about what is happening.

https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view

On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur <
madalin.bu...@nxp.com> wrote:

> > -Original Message-
> > From: Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:25 PM
> > To: David S . Miller <da...@davemloft.net>
> > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > madskate...@gmail.com; 'Madalin-cristian Bucur' <madalin.bu...@nxp.com>;
> > Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
> > <joakim.tjernl...@infinera.com>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -Original Message-
> > > From: netdev-ow...@vger.kernel.org [mailto:netdev-owner@vger.
> kernel.org]
> > > On Behalf Of Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > To: Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
> > > <joakim.tjernl...@infinera.com>
> > > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > > madskate...@gmail.com; David S . Miller <da...@davemloft.net>
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > -Original Message-
> > > > From: Andrew Lunn [mailto:and...@lunn.ch]
> > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > To: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > 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.
> > > >
> > > > The "someone else might though" is a big point of asking for it to
> > > > added to stable. The other reason is it means one less patch you need
> > > > to maintain in your build.
> > >
> > > I've sent that patch [1] for net but I guess the timing was wrong and
> > > it was merged to net-next.
> > >
> > > > > I would be interested in bug fixes upstream which fixes:
> > > >
> > > > Did you try upstream? Does it give the same errors?
> > > >
> > > > Andrew
> > >
> > > [1] https://patchwork.kernel.org/patch/10146119/
> > >
> > > Madalin
> >
> > Hi Dave,
> >
> > Can you please add the fix [1] to stable?
> >
> > Thank you,
> > Madalin
>
> Sorry,
>
> I've provided the wrong link towards the patch (v1 instead of v3),
> here's the correct one:
>
> https://patchwork.kernel.org/patch/10151969/
>
> Madalin
>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-19 Thread Joakim Tjernlund

On Thu, 1970-01-01 at 00:00 +, 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.
> 
> 
> > > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > > Author: Florian Fainelli 
> > > Date: Tue Aug 22 15:24:47 2017 -0700
> > > fsl/man: Inherit parent device and of_node
> > > 
> > > and was later addressed by this patch set:
> > > 
> > > http://patchwork.ozlabs.org/project/netdev/list/?series=8462=*
> > > 
> > > Even with these errors printed, all is working fine, it's just the
> > > second probing that fails. Adding the latter patches or reverting
> > > the one above makes the errors prints dissapear.
> > 
> > Looking at the above patch seriers I see it is in state Accepted and has 
> > been there
> > since 2017-10-16
> > That seems like a awful long to wait in before getting into Linux, is there 
> > something
> > holding these patches back ?
> 
> They are in Linux, have been since October 16th. But at the moment,
> they are only in v4.15, not v4.14.

Now I see them in 4.15, must have looked in the wrong branch.

> 
> These patches probably don't fit the stable rules, for getting them
> added to v4.14.
> 
> https://github.com/torvalds/linux/blob/master/Documentation/process/stable-kernel-rules.rst

Stuff needs to work, whatever needed to make that happen is allowed. Even 
backporting
some new infra structure if need be to simplify fixing bugs.

> 
> What is needed is a minimal fix. Or just wait until Sunday, when there
> is a good chance v4.15 will be released.

You seem to think everyone always upgrade to linux latest but this is not so.
We do product development here and appreciate the stable kernels so we can work 
in
peace and not chasing the latest kernel.

 Jocke

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-19 Thread Andrew Lunn

> > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > Author: Florian Fainelli 
> > Date: Tue Aug 22 15:24:47 2017 -0700
> > fsl/man: Inherit parent device and of_node
> > 
> > and was later addressed by this patch set:
> > 
> > http://patchwork.ozlabs.org/project/netdev/list/?series=8462=*
> > 
> > Even with these errors printed, all is working fine, it's just the
> > second probing that fails. Adding the latter patches or reverting
> > the one above makes the errors prints dissapear.
> 
> Looking at the above patch seriers I see it is in state Accepted and has been 
> there
> since 2017-10-16
> That seems like a awful long to wait in before getting into Linux, is there 
> something
> holding these patches back ?

They are in Linux, have been since October 16th. But at the moment,
they are only in v4.15, not v4.14.

These patches probably don't fit the stable rules, for getting them
added to v4.14.

https://github.com/torvalds/linux/blob/master/Documentation/process/stable-kernel-rules.rst

What is needed is a minimal fix. Or just wait until Sunday, when there
is a good chance v4.15 will be released.

   Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-19 Thread Joakim Tjernlund

On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur wrote:
> 
> > -Original Message-
> > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > Sent: Tuesday, January 16, 2018 7:58 PM
> > To: and...@lunn.ch
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > 
> > On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote:
> > > 
> > > Hi Joakim
> > > 
> > > 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. Seems like
> > this
> > patch hasn't been sent to 4.14.x.
> > 
> > I wonder if I might be missing something else, we just moved to 4.14 and
> > notic that all
> > our fixed PHYs are non functioning:
> > 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
> > fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> > fsl_mac ffe4e8000.ethernet: FMan MEMAC
> > fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> > fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.3 failed with error -16
> > 
> > Feels like FMAN still think there are real PHYs there ?
> 
> Hi Joakim,
> 
> These errors are issued when trying to probe the second time the same
> MAC node. The issue was introduced by this commit:
> 
> commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> Author: Florian Fainelli <f.faine...@gmail.com>
> Date: Tue Aug 22 15:24:47 2017 -0700
> fsl/man: Inherit parent device and of_node
> 
> and was later addressed by this patch set:
> 
> http://patchwork.ozlabs.org/project/netdev/list/?series=8462=*
> 
> Even with these errors printed, all is working fine, it's just the
> second probing that fails. Adding the latter patches or reverting
> the one above makes the errors prints dissapear.

Looking at the above patch seriers I see it is in state Accepted and has been 
there
since 2017-10-16
That seems like a awful long to wait in before getting into Linux, is there 
something
holding these patches back ?

 Jocke

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-18 Thread Joakim Tjernlund

On Thu, 1970-01-01 at 00:00 +, Joakim Tjernlund wrote:
> On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur 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.
> > 
> > 
> > > -Original Message-
> > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > > Sent: Tuesday, January 16, 2018 7:58 PM
> > > To: and...@lunn.ch
> > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > 
> > > On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote:
> > > > 
> > > > Hi Joakim
> > > > 
> > > > 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. Seems like
> > > this
> > > patch hasn't been sent to 4.14.x.
> > > 
> > > I wonder if I might be missing something else, we just moved to 4.14 and
> > > notic that all
> > > our fixed PHYs are non functioning:
> > > 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
> > > fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> > > fsl_mac ffe4e8000.ethernet: FMan MEMAC
> > > fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> > > fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> > > fsl_mac: probe of dpaa-ethernet.3 failed with error -16
> > > 
> > > Feels like FMAN still think there are real PHYs there ?
> > 
> > Hi Joakim,
> > 
> > These errors are issued when trying to probe the second time the same
> > MAC node. The issue was introduced by this commit:
> > 
> > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > Author: Florian Fainelli <f.faine...@gmail.com>
> > Date: Tue Aug 22 15:24:47 2017 -0700
> > fsl/man: Inherit parent device and of_node
> > 
> > and was later addressed by this patch set:
> > 
> > http://patchwork.ozlabs.org/project/netdev/list/?series=8462=*
> > 
> > Even with these errors printed, all is working fine, it's just the
> > second probing that fails. Adding the latter patches or reverting
> > the one above makes the errors prints dissapear.
> > 
> > Madalin
> 
> Ahh, now it starts to look better, reverting "fsl/man: Inherit parent device 
> and of_node" on 4.14 gives:
> libphy: Fixed MDIO Bus: probed
> tun: Universal TUN/TAP device driver, 1.6
> 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 ffe4e4000.ethernet: FMan MEMAC
> fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
> fsl_mac ffe4e6000.ethernet: FMan MEMAC
> fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac ffe4e.ethernet: FMan MEMAC
> fsl_mac ffe4e.ethernet: FMan MAC address: 00:06:9c:0b:06:1f
> fsl_dpa dpaa-ethernet.0 eth0: Probed interface eth0
> fsl_dpa dpaa-ethernet.1 eth1: Probed i

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-17 Thread Joakim Tjernlund

On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur 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.
> 
> 
> > -Original Message-
> > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > Sent: Tuesday, January 16, 2018 7:58 PM
> > To: and...@lunn.ch
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > 
> > On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote:
> > > 
> > > Hi Joakim
> > > 
> > > 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. Seems like
> > this
> > patch hasn't been sent to 4.14.x.
> > 
> > I wonder if I might be missing something else, we just moved to 4.14 and
> > notic that all
> > our fixed PHYs are non functioning:
> > 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
> > fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> > fsl_mac ffe4e8000.ethernet: FMan MEMAC
> > fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> > fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> > fsl_mac: probe of dpaa-ethernet.3 failed with error -16
> > 
> > Feels like FMAN still think there are real PHYs there ?
> 
> Hi Joakim,
> 
> These errors are issued when trying to probe the second time the same
> MAC node. The issue was introduced by this commit:
> 
> commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> Author: Florian Fainelli <f.faine...@gmail.com>
> Date: Tue Aug 22 15:24:47 2017 -0700
> fsl/man: Inherit parent device and of_node
> 
> and was later addressed by this patch set:
> 
> http://patchwork.ozlabs.org/project/netdev/list/?series=8462=*
> 
> Even with these errors printed, all is working fine, it's just the
> second probing that fails. Adding the latter patches or reverting
> the one above makes the errors prints dissapear.
> 
> Madalin

Ahh, now it starts to look better, reverting "fsl/man: Inherit parent device 
and of_node" on 4.14 gives:
libphy: Fixed MDIO Bus: probed
tun: Universal TUN/TAP device driver, 1.6
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 ffe4e4000.ethernet: FMan MEMAC
fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21
fsl_mac ffe4e6000.ethernet: FMan MEMAC
fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22
fsl_mac ffe4e8000.ethernet: FMan MEMAC
fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
fsl_mac ffe4e.ethernet: FMan MEMAC
fsl_mac ffe4e.ethernet: FMan MAC address: 00:06:9c:0b:06:1f
fsl_dpa dpaa-ethernet.0 eth0: Probed interface eth0
fsl_dpa dpaa-ethernet.1 eth1: Probed interface eth1
fsl_dpa dpaa-ethernet.2 eth2: Probed interface eth2
fsl_dpa dpaa-ethernet.3 eth3: Probed interface eth3
fsl_dpa dpaa-ethernet.4 eth4: Probed interface eth4

Still some minor errors: mdio_bus ffe4e7000: Error while reading PHY0 reg at 3.3
but this is going the right way(I have not had a chance to try if they work due
to external modules not ported/ready yet)

The other patch series is still to be tested though but I already now wanted 
to stress the importance of getting all upstream fixes into stable, ASAP.
You now what they are, I have no idea.

Thanks 
   Jocke

RE: DPAA Ethernet traffice troubles with Linux kernel

2018-01-17 Thread Madalin-cristian Bucur

> -Original Message-
> From: Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:25 PM
> To: David S . Miller <da...@davemloft.net>
> Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> madskate...@gmail.com; 'Madalin-cristian Bucur' <madalin.bu...@nxp.com>;
> Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
> <joakim.tjernl...@infinera.com>
> Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> 
> > -Original Message-
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> > On Behalf Of Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:16 PM
> > To: Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
> > <joakim.tjernl...@infinera.com>
> > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > madskate...@gmail.com; David S . Miller <da...@davemloft.net>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -Original Message-
> > > From: Andrew Lunn [mailto:and...@lunn.ch]
> > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > To: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > 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.
> > >
> > > The "someone else might though" is a big point of asking for it to
> > > added to stable. The other reason is it means one less patch you need
> > > to maintain in your build.
> >
> > I've sent that patch [1] for net but I guess the timing was wrong and
> > it was merged to net-next.
> >
> > > > I would be interested in bug fixes upstream which fixes:
> > >
> > > Did you try upstream? Does it give the same errors?
> > >
> > > Andrew
> >
> > [1] https://patchwork.kernel.org/patch/10146119/
> >
> > Madalin
> 
> Hi Dave,
> 
> Can you please add the fix [1] to stable?
> 
> Thank you,
> Madalin

Sorry,

I've provided the wrong link towards the patch (v1 instead of v3),
here's the correct one:

https://patchwork.kernel.org/patch/10151969/

Madalin

RE: DPAA Ethernet traffice troubles with Linux kernel

2018-01-17 Thread Madalin-cristian Bucur

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:16 PM
> To: Andrew Lunn <and...@lunn.ch>; Joakim Tjernlund
> <joakim.tjernl...@infinera.com>
> Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> madskate...@gmail.com; David S . Miller <da...@davemloft.net>
> Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> 
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Wednesday, January 17, 2018 3:44 PM
> > To: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > 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.
> >
> > The "someone else might though" is a big point of asking for it to
> > added to stable. The other reason is it means one less patch you need
> > to maintain in your build.
> 
> I've sent that patch [1] for net but I guess the timing was wrong and
> it was merged to net-next.
> 
> > > I would be interested in bug fixes upstream which fixes:
> >
> > Did you try upstream? Does it give the same errors?
> >
> > Andrew
> 
> [1] https://patchwork.kernel.org/patch/10146119/
> 
> Madalin

Hi Dave,

Can you please add the fix [1] to stable?

Thank you,
Madalin

RE: DPAA Ethernet traffice troubles with Linux kernel

2018-01-17 Thread Madalin-cristian Bucur

> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Wednesday, January 17, 2018 3:44 PM
> To: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> 
> > 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.
> 
> The "someone else might though" is a big point of asking for it to
> added to stable. The other reason is it means one less patch you need
> to maintain in your build.

I've sent that patch [1] for net but I guess the timing was wrong and
it was merged to net-next.

> > I would be interested in bug fixes upstream which fixes:
> 
> Did you try upstream? Does it give the same errors?
> 
> Andrew

[1] https://patchwork.kernel.org/patch/10146119/

Madalin

RE: DPAA Ethernet traffice troubles with Linux kernel

2018-01-17 Thread Madalin-cristian Bucur

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Tuesday, January 16, 2018 7:58 PM
> To: and...@lunn.ch
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> 
> On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote:
> >
> > Hi Joakim
> >
> > 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. Seems like
> this
> patch hasn't been sent to 4.14.x.
> 
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> 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
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
> 
> Feels like FMAN still think there are real PHYs there ?

Hi Joakim,

These errors are issued when trying to probe the second time the same
MAC node. The issue was introduced by this commit:

commit 4d8ee1935bcd666360311dfdadeee235d682d69a
Author: Florian Fainelli <f.faine...@gmail.com>
Date: Tue Aug 22 15:24:47 2017 -0700
fsl/man: Inherit parent device and of_node

and was later addressed by this patch set:

http://patchwork.ozlabs.org/project/netdev/list/?series=8462=*

Even with these errors printed, all is working fine, it's just the
second probing that fails. Adding the latter patches or reverting
the one above makes the errors prints dissapear.

Madalin

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-17 Thread Andrew Lunn

> 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.

The "someone else might though" is a big point of asking for it to
added to stable. The other reason is it means one less patch you need
to maintain in your build.

> I would be interested in bug fixes upstream which fixes:

Did you try upstream? Does it give the same errors?

Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-17 Thread mad skateman

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 1

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 +, 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

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-17 Thread Joakim Tjernlund

On Thu, 1970-01-01 at 00:00 +, 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

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread Christian Zigotzky

FYI

Sent from my iPhone

> On 17. Jan 2018, at 06:50, Christian Zigotzky  wrote:
> 
> Hi Skateman,
> 
> Fantastic! Many thanks for testing the RC8 of kernel 4.15 without PAMU 
> support.
> 
> @All
> Further information: 
> http://forum.hyperion-entertainment.biz/viewtopic.php?f=58=43706#p43706
> 
> Cheers,
> Christian
> 
> Sent from my iPhone
> 
>> On 16. Jan 2018, at 23:05, mad skateman  wrote:
>> 
>> Fantastic Christian.. 
>> 
>> Your latest kernel makes the NIC work!!!
>> 
>> Few tweaks to be done... like the buffer space 
>> 
>> Brilliant!
> 
> 
> 
>> On 16. Jan 2018, at 21:46, Christian Zigotzky  wrote:
>> 
>> FYI
>> 
>>> On 16 January 2018 at 9:42PM, Christian Zigotzky wrote:
>>> Hi All,
>>> 
>>> I compiled the RC8 of kernel 4.15 for the X5000 without PAMU support today.
>>> 
>>> Download: http://www.xenosoft.de/uImage_without_pamu.tar.gz
>>> 
>>> Please test it on your AmigaOne X5000.
>>> 
>>> Thanks,
>>> Christian
>>> 
>>> 
>>> On 16 January 2018 at 6:33PM, Madalin-cristian Bucur wrote:
> The PAMU related errors may be relevant to the issue, if you have 
> incorrect
> settings you may have no traffic passing through. The PAMU configuration
> should be made by the bootloader. Can you try to disable CONFIG_FSL_PAMU?
> 
> Madalin
> 
> 
>>>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread mad skateman

This makes me really start to wonder if the mainboard producer Varisys/AEON
has Purchased MAC`s for these boards at IEEE

Uboot system info gives for both MAC adresses the value NULL ... and i have
checked the mainboard for any stickers regarding the MAC adresses but there
is none..

I also tried to just create a ethaddr, eth1addr and eth2addr as mention on
the Wiki..but no luck

http://wiki.amiga.org/index.php?title=AmigaONE_X5000



On Tue, Jan 16, 2018 at 10:00 PM, Andrew Lunn  wrote:

> > *Given this if we disable that bit, we get the matching "Universally
> > Administered Address" 0100 (Binary), 04 (Hex) -> "04:00:00", hence my
> > question:"*
> >
> > This has something to do with the MAC adresses being locally administered
> > .. and since whe can use Uboot and choose any Mac addr we want, this
> could
> > make sense..
>
> You cannot just flip this bit. Universally administered addresses are
> allocated by the IEEE. You need to purchase them from the IEEE.
> Locally administered MAC addresses you can use, and any sane DHCP
> server should work with them.
>
> This also does not fit with mii-tool -R observation.
>
>  Andrew
>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread mad skateman

Hi,

I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.

I can see that the Ethernet NIC at least does something. ARP BROADCAST
traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..something with Octets.

*"the first 3 octets/first-half of a MAC-48/EUI-48 Address, correspond to
the OUI (e.g.: MAC = 06:00:00:xx:xx:xx, OUI = 06:00:00), and the 2nd least
significant bit of its first octet is used to differentiate "Universally"
and "Locally" administered addresses). In other words, if we convert 06
(Hex) to 0110 (Binary), we can see that the U/L bit is set to one,
which means that it a locally administered address.*

*Given this if we disable that bit, we get the matching "Universally
Administered Address" 0100 (Binary), 04 (Hex) -> "04:00:00", hence my
question:"*

This has something to do with the MAC adresses being locally administered
.. and since whe can use Uboot and choose any Mac addr we want, this could
make sense..

These types of Logs also apear in my Wireshark Capture files... ( these are
not my org. logs)

Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
 ..1.     = LG bit: Locally administered address (this
is NOT the factory default)
 ...1     = IG bit: Group address (multicast/broadcast)
Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
 ..0.     = LG bit: Globally unique address (factory
default)
 ...0     = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)

In the link below some similair Logs and problems regarding DHCP for
example.

Dave

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread mad skateman

Hi,

I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.

I can see using wireshark that the Ethernet NIC at least does something.
ARP BROADCAST traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..

This has something to do with the MAC adresses being locally administered
.. and since whe can use Uboot and choose any Mac addr we want, this could
make sense..

These types of Logs also apear in my Wireshark Capture files... ( these are
not my org. logs)

Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
 ..1.     = LG bit: Locally administered address (this
is NOT the factory default)
 ...1     = IG bit: Group address (multicast/broadcast)
Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
 ..0.     = LG bit: Globally unique address (factory
default)
 ...0     = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)

In the link below some similair Logs and problems regarding DHCP for
example.

Dave

On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
joakim.tjernl...@infinera.com> wrote:

> On Thu, 1970-01-01 at 00:00 +, 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.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund 
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund 
> >
> > Hi Joakim
> >
> > 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. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> 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
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur 
> > Date:   Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur 
> > Reviewed-by: Andrew Lunn 
> > Signed-off-by: David S. Miller 
> >
> >
> > Andrew
>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread mad skateman

Hi,

I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.

I can see using wireshark that the Ethernet NIC at least does something.
ARP BROADCAST traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..

This has something to do with the MAC adresses being locally administered
.. and since whe can use Uboot and choose any Mac addr we want, this could
make sense..

These types of Logs also apear in my Wireshark Capture files... ( these are
not my org. logs)

Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
 ..1.     = LG bit: Locally administered address (this
is NOT the factory default)
 ...1     = IG bit: Group address (multicast/broadcast)
Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)
 ..0.     = LG bit: Globally unique address (factory
default)
 ...0     = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)

In the link below some similair Logs and problems regarding DHCP for
example.

Dave

https://www.microchip.com/forums/m/tm.aspx?m=956881=1=2

On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
joakim.tjernl...@infinera.com> wrote:

> On Thu, 1970-01-01 at 00:00 +, 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.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund 
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund 
> >
> > Hi Joakim
> >
> > 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. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> 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
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur 
> > Date:   Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur 
> > Reviewed-by: Andrew Lunn 
> > Signed-off-by: David S. Miller 
> >
> >
> > Andrew
>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread mad skateman

Hi,

I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.

I can see that the Ethernet NICS at least do something. ARP BROADCAST
traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct value..

This has something to do with the MAC adresses being non Authorative.. and
since whe can use Uboot and choose any Mac addr we want, this could make
sense.. More info about this
https://osqa-ask.wireshark.org/questions/59761/oui-lookup-tool-does-not-recognize-local-addresses

Logs like these appear: not the original.

Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
 ..1.     = LG bit: Locally administered address (this
is NOT the factory default)
 ...1     = IG bit: Group address (multicast/broadcast)


Will try to get the picture more clear... but think about this..



On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
joakim.tjernl...@infinera.com> wrote:

> On Thu, 1970-01-01 at 00:00 +, 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.
> >
> >
> > > Hi, just saw this and thought of a small patch I just wrote for mdio
> bus, o idea
> > > if it is relevant but here goes:
> > >
> > > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > > From: Joakim Tjernlund 
> > > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > > Subject: [PATCH] of_mdiobus_register: Continue after error
> > >
> > > of_mdiobus_register unregister itself if one phy fails to register
> > > which is bad for system having all its PHYs on the same MDIO bus.
> > > Just log the error and continue with the remaining PHYs instead.
> > >
> > > Signed-off-by: Joakim Tjernlund 
> >
> > Hi Joakim
> >
> > 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. Seems like
> this
> patch hasn't been sent to 4.14.x.
>
> I wonder if I might be missing something else, we just moved to 4.14 and
> notic that all
> our fixed PHYs are non functioning:
> 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
> fsl_mac: probe of dpaa-ethernet.2 failed with error -16
> fsl_mac ffe4e8000.ethernet: FMan MEMAC
> fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
> fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
> fsl_mac: probe of dpaa-ethernet.3 failed with error -16
>
> Feels like FMAN still think there are real PHYs there ?
> >
> > commit 95f566de0269a0c59fd6a737a147731302136429
> > Author: Madalin Bucur 
> > Date:   Tue Jan 9 14:43:34 2018 +0200
> >
> > of_mdio: avoid MDIO bus removal when a PHY is missing
> >
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
> >
> > Signed-off-by: Madalin Bucur 
> > Reviewed-by: Andrew Lunn 
> > Signed-off-by: David S. Miller 
> >
> >
> > Andrew
>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread Andrew Lunn

> *Given this if we disable that bit, we get the matching "Universally
> Administered Address" 0100 (Binary), 04 (Hex) -> "04:00:00", hence my
> question:"*
> 
> This has something to do with the MAC adresses being locally administered
> .. and since whe can use Uboot and choose any Mac addr we want, this could
> make sense..

You cannot just flip this bit. Universally administered addresses are
allocated by the IEEE. You need to purchase them from the IEEE.
Locally administered MAC addresses you can use, and any sane DHCP
server should work with them.

This also does not fit with mii-tool -R observation.

 Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread Andrew Lunn

> > 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.

   Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread Joakim Tjernlund

On Thu, 1970-01-01 at 00:00 +, 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.
> 
> 
> > Hi, just saw this and thought of a small patch I just wrote for mdio bus, o 
> > idea
> > if it is relevant but here goes:
> > 
> > From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> > From: Joakim Tjernlund 
> > Date: Sun, 14 Jan 2018 21:27:20 +0100
> > Subject: [PATCH] of_mdiobus_register: Continue after error
> > 
> > of_mdiobus_register unregister itself if one phy fails to register
> > which is bad for system having all its PHYs on the same MDIO bus.
> > Just log the error and continue with the remaining PHYs instead.
> > 
> > Signed-off-by: Joakim Tjernlund 
> 
> Hi Joakim
> 
> 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. Seems like this
patch hasn't been sent to 4.14.x.

I wonder if I might be missing something else, we just moved to 4.14 and notic 
that all
our fixed PHYs are non functioning:
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
fsl_mac: probe of dpaa-ethernet.2 failed with error -16
fsl_mac ffe4e8000.ethernet: FMan MEMAC
fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23
fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed
fsl_mac: probe of dpaa-ethernet.3 failed with error -16

Feels like FMAN still think there are real PHYs there ?
> 
> commit 95f566de0269a0c59fd6a737a147731302136429
> Author: Madalin Bucur 
> Date:   Tue Jan 9 14:43:34 2018 +0200
> 
> of_mdio: avoid MDIO bus removal when a PHY is missing
> 
> If one of the child devices is missing the of_mdiobus_register_phy()
> call will return -ENODEV. When a missing device is encountered the
> registration of the remaining PHYs is stopped and the MDIO bus will
> fail to register. Propagate all errors except ENODEV to avoid it.
> 
> Signed-off-by: Madalin Bucur 
> Reviewed-by: Andrew Lunn 
> Signed-off-by: David S. Miller 
> 
> 
> Andrew

RE: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread Madalin-cristian Bucur

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Andrew Lunn
> Sent: Tuesday, January 16, 2018 5:04 PM
> To: mad skateman <madskate...@gmail.com>
> Cc: Christian Zigotzky <chzigot...@xenosoft.de>; Joakim Tjernlund
> <joakim.tjernl...@infinera.com>; linuxppc-dev@lists.ozlabs.org; Madalin-
> cristian Bucur <madalin.bu...@nxp.com>; net...@vger.kernel.org
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> 
> > When i use mii-tool too Kick the tranceiver... it comes alive.. i can
> > ping the eth0 itself
> >
> > root@X5000LNX:/home/skateman# mii-tool -R eth0
> > resetting the transceiver...
> > root@X5000LNX:/home/skateman# ping 192.168.22.44
> > PING 192.168.22.44 (192.168.22.44) 56(84) bytes of data.
> > 64 bytes from 192.168.22.44: icmp_seq=1 ttl=64 time=0.045 ms
> > 64 bytes from 192.168.22.44: icmp_seq=2 ttl=64 time=0.046 ms
> > 64 bytes from 192.168.22.44: icmp_seq=3 ttl=64 time=0.047 ms
> > 64 bytes from 192.168.22.44: icmp_seq=4 ttl=64 time=0.048 ms
> 
> What PHY driver are you using?
> 
> This smells a bit like an RGMII-ID problem.
> 
>  Andrew

Hi Andrew,

>From another thread[1] on the same topic:

> I am not sure what PHY hardware/configuration you are using on the
> DS and RDB platforms, but I can confirm that AmigaONE X5000/20
> (Cyrus Motherboard with p5020 SoC), has dTSEC 4 and dTSEC 5
> wired to two Micrel KSZ9021RN Gigabit Ethernet PHYs, using the
> RGMII protocol.

[1] https://www.spinics.net/lists/netdev/msg478062.html

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread Andrew Lunn

> Hi, just saw this and thought of a small patch I just wrote for mdio bus, o 
> idea
> if it is relevant but here goes:
> 
> From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund 
> Date: Sun, 14 Jan 2018 21:27:20 +0100
> Subject: [PATCH] of_mdiobus_register: Continue after error
> 
> of_mdiobus_register unregister itself if one phy fails to register
> which is bad for system having all its PHYs on the same MDIO bus.
> Just log the error and continue with the remaining PHYs instead.
> 
> Signed-off-by: Joakim Tjernlund 

Hi Joakim

You appear to be using an old kernel. Take a look at:

commit 95f566de0269a0c59fd6a737a147731302136429
Author: Madalin Bucur 
Date:   Tue Jan 9 14:43:34 2018 +0200

of_mdio: avoid MDIO bus removal when a PHY is missing

If one of the child devices is missing the of_mdiobus_register_phy()
call will return -ENODEV. When a missing device is encountered the
registration of the remaining PHYs is stopped and the MDIO bus will
fail to register. Propagate all errors except ENODEV to avoid it.

Signed-off-by: Madalin Bucur 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 


Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-16 Thread Andrew Lunn

> When i use mii-tool too Kick the tranceiver... it comes alive.. i can
> ping the eth0 itself
> 
> root@X5000LNX:/home/skateman# mii-tool -R eth0
> resetting the transceiver...
> root@X5000LNX:/home/skateman# ping 192.168.22.44
> PING 192.168.22.44 (192.168.22.44) 56(84) bytes of data.
> 64 bytes from 192.168.22.44: icmp_seq=1 ttl=64 time=0.045 ms
> 64 bytes from 192.168.22.44: icmp_seq=2 ttl=64 time=0.046 ms
> 64 bytes from 192.168.22.44: icmp_seq=3 ttl=64 time=0.047 ms
> 64 bytes from 192.168.22.44: icmp_seq=4 ttl=64 time=0.048 ms

What PHY driver are you using?

This smells a bit like an RGMII-ID problem.

 Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-15 Thread mad skateman

Some extra info:

When Ubuntu boots, Eth0 (192.168.22.44) is not brought up automaticly..

When i bring up eth0 by hand, its still not active..

root@X5000LNX:/home/skateman# ifconfig eth0 up
root@X5000LNX:/home/skateman# ping 192.168.22.44
connect: Network is unreachable

When i use mii-tool too Kick the tranceiver... it comes alive.. i can
ping the eth0 itself

root@X5000LNX:/home/skateman# mii-tool -R eth0
resetting the transceiver...
root@X5000LNX:/home/skateman# ping 192.168.22.44
PING 192.168.22.44 (192.168.22.44) 56(84) bytes of data.
64 bytes from 192.168.22.44: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from 192.168.22.44: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 192.168.22.44: icmp_seq=3 ttl=64 time=0.047 ms
64 bytes from 192.168.22.44: icmp_seq=4 ttl=64 time=0.048 ms

eth0  Link encap:Ethernet  HWaddr 00:04:9f:01:02:03
  inet addr:192.168.22.44  Bcast:192.168.22.255  Mask:255.255.255.0
  inet6 addr: fe80::c84b:9f6b:f2f6:8933/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:7600 (7.6 KB)
  Memory:fe4e6000-fe4e6fff

Not realy sure why the Tranceiver is not brought up directly when linux starts..



On 1/15/18, Christian Zigotzky  wrote:
> Sorry, I have forgotten the download link. Please test it with the DPAA
> Ethernet.
>> Hi All,
>>
>> I compiled the RC8 of kernel 4.15 with Joakim's patch for the AmigaOne
>> X5000 today. Many thanks to Joakim for the mdio patch.
>>
>> Download: http://www.xenosoft.de/uImage-4.15-rc8_with_mdio_patch.tar.gz
>>
>> Please test it on your X5000.
>>
>> Thanks,
>> Christian
>>
>>
>> On 15 January 2018 at 5:59PM, Joakim Tjernlund wrote:

 Hi,

 Please use text logs instead of pictures next time, it's easier to
 read.
 The errors you see are related to missing MAC addresses for the unused
 interfaces, you can ignore these are they are not relevant for the
 issue
 you encounter. Normally the unused interfaces should have status
 disabled
 in the device tree but there is not a big deal if they fail like that.
 As I've advised Jamie on the other thread, please try to connect the
 device
 back 2 back to a known good machine and determine what is broken -
 Rx/Tx?
 Is there another software version that does work on these machines?
>>> Hi, just saw this and thought of a small patch I just wrote for mdio
>>> bus, o idea
>>> if it is relevant but here goes:
>>>
>>>  From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
>>> From: Joakim Tjernlund 
>>> Date: Sun, 14 Jan 2018 21:27:20 +0100
>>> Subject: [PATCH] of_mdiobus_register: Continue after error
>>>
>>> of_mdiobus_register unregister itself if one phy fails to register
>>> which is bad for system having all its PHYs on the same MDIO bus.
>>> Just log the error and continue with the remaining PHYs instead.
>>>
>>> Signed-off-by: Joakim Tjernlund 
>>> ---
>>>   drivers/of/of_mdio.c | 6 --
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
>>> index 98258583abb0..76ff28a41dad 100644
>>> --- a/drivers/of/of_mdio.c
>>> +++ b/drivers/of/of_mdio.c
>>> @@ -229,7 +229,8 @@ int of_mdiobus_register(struct mii_bus *mdio,
>>> struct device_node *np)
>>>   else
>>>   rc = of_mdiobus_register_device(mdio, child, addr);
>>>   if (rc)
>>> -    goto unregister;
>>> +    pr_warn(FW_WARN
>>> +    "%pOF: Failed to register MDIO device.\n", child);
>>>   }
>>>     if (!scanphys)
>>> @@ -253,7 +254,8 @@ int of_mdiobus_register(struct mii_bus *mdio,
>>> struct device_node *np)
>>>   if (of_mdiobus_child_is_phy(child)) {
>>>   rc = of_mdiobus_register_phy(mdio, child, addr);
>>>   if (rc)
>>> -    goto unregister;
>>> +    pr_warn(FW_WARN
>>> +    "%pOF: Failed to register MDIO PHY.\n", child);
>>>   }
>>>   }
>>>   }
>>
>>
>
>

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-15 Thread mad skateman

Hi All,

I have been testing with the rc8 kernel as Christian sugested.

At this moment still the same issues..

Here some of my finding...

A dump of dmesg regarding the FSL_DPAA:

[4.597949] libphy: Fixed MDIO Bus: probed
[4.599095] libphy: Freescale PowerQUICC MII Bus: probed
[4.609108] libphy: Freescale PowerQUICC MII Bus: probed
[4.609995] libphy: Freescale PowerQUICC MII Bus: probed
[4.610689] libphy: Freescale PowerQUICC MII Bus: probed
[4.611623] libphy: Freescale PowerQUICC MII Bus: probed
[4.612470] libphy: Freescale XGMAC MDIO Bus: probed
[4.617710] fsl_dpaa_mac ffe4e6000.ethernet: FMan dTSEC version: 0x08240101
[4.618335] fsl_dpaa_mac ffe4e6000.ethernet: FMan MAC address:
00:04:9f:01:02:03
[4.618653] fsl_dpaa_mac ffe4e8000.ethernet: FMan dTSEC version: 0x08240101
[4.619042] fsl_dpaa_mac ffe4e8000.ethernet: FMan MAC address:
00:04:9f:01:02:04
[4.619294] fsl_dpaa_mac ffe4e.ethernet:
of_get_mac_address(/soc@ffe00/fman@40/ethernet@e) failed
[4.619505] fsl_dpaa_mac: probe of ffe4e.ethernet failed with error -22
[4.619673] fsl_dpaa_mac ffe4e2000.ethernet:
of_get_mac_address(/soc@ffe00/fman@40/ethernet@e2000) failed
[4.619878] fsl_dpaa_mac: probe of ffe4e2000.ethernet failed with error -22
[4.620048] fsl_dpaa_mac ffe4e4000.ethernet:
of_get_mac_address(/soc@ffe00/fman@40/ethernet@e4000) failed
[4.620258] fsl_dpaa_mac: probe of ffe4e4000.ethernet failed with error -22
[4.625078] fsl_dpaa_mac ffe4f.ethernet:
of_get_mac_address(/soc@ffe00/fman@40/ethernet@f) failed
[4.630001] fsl_dpaa_mac: probe of ffe4f.ethernet failed with error -22
[4.637015] fsl_dpaa_mac ffe4e6000.ethernet eth0: Probed interface eth0
[4.643933] fsl_dpaa_mac ffe4e8000.ethernet eth1: Probed interface eth1

This all seems correct! The probed mac`s are the one`s as put in Uboot:
Ethaddr and Eth1addr

The Eth0 and Eth1 are also probed.

When eth0 is brought up... it is unable to get an ip adress from the
dhcp server.

eth0  Link encap:Ethernet  HWaddr 00:04:9f:01:02:03
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:510 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:102556 (102.5 KB)
  Memory:fe4e6000-fe4e6fff

When using mii-tool for a double check:

mii-tool -l eth0
eth0: negotiated 1000baseT-FD flow-control, link ok

and when using ethtool

ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes:  10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
 1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 3
Transceiver: external
Auto-negotiation: on
Current message level: 0x0037 (55)
   drv probe link ifdown ifup
Link detected: yes

RX packets always stay 0 ?

Will continiue to get more info...







On 1/15/18, Christian Zigotzky  wrote:
> Sorry, I have forgotten the download link. Please test it with the DPAA
> Ethernet.
>> Hi All,
>>
>> I compiled the RC8 of kernel 4.15 with Joakim's patch for the AmigaOne
>> X5000 today. Many thanks to Joakim for the mdio patch.
>>
>> Download: http://www.xenosoft.de/uImage-4.15-rc8_with_mdio_patch.tar.gz
>>
>> Please test it on your X5000.
>>
>> Thanks,
>> Christian
>>
>>
>> On 15 January 2018 at 5:59PM, Joakim Tjernlund wrote:

 Hi,

 Please use text logs instead of pictures next time, it's easier to
 read.
 The errors you see are related to missing MAC addresses for the unused
 interfaces, you can ignore these are they are not relevant for the
 issue
 you encounter. Normally the unused interfaces should have status
 disabled
 in the device tree but there is not a big deal if they fail like that.
 As I've advised Jamie on the other thread, please try to connect the
 device
 back 2 back to a known good machine and determine what is broken -
 Rx/Tx?
 Is there another software version that does work on

Re: DPAA Ethernet traffice troubles with Linux kernel

2018-01-15 Thread Joakim Tjernlund

On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur 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.
> 
> 
> > -Original Message-
> > From: Linuxppc-dev [mailto:linuxppc-dev-
> > bounces+madalin.bucur=nxp@lists.ozlabs.org] On Behalf Of mad skateman
> > Sent: Wednesday, January 10, 2018 10:39 PM
> > To: linuxppc-dev@lists.ozlabs.org
> > Subject: DPAA Ethernet traffice troubles with Linux kernel
> > 
> > Hi linux devs,
> > 
> > Like mentioned in this thread
> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-January/167630.html
> > i also experience the exact same issues.
> > I am also trying to find out why the network traffic is not flowing
> > the way it should (out for example ).
> > 
> > My linux knowledge is very basic but i hope i can contribute anyway.
> > 
> > I am using the AmigaOne X5000 with a P5020
> > Most detailed technical information regarding this issue can be found
> > in the Thread by Jamie Krueger mentioned above.
> > 
> > In this screenshot, the ETH0 and ETH1 seem up and running (probed) ..
> > even due to the FSL_DPAA_MAC error messages that DMESG shows.
> > http://www.skateman.nl/wp-content/uploads/2018/01/Screenshot-at-2018-01-08-21_22_06_ETH_NIC_ERROR.png
> > 
> > http://www.skateman.nl/wp-content/uploads/2018/01/Screenshot-at-2018-01-08-22_16_28.png
> > 
> > I was able to use some tooling like ETHTOOL to adjust some settings
> > and check if the interface responded. This all seems fine.
> > 
> > Hope that someone can find a fix, so the Ethernet adapter can be used.
> > 
> > Thanks!!
> 
> Hi,
> 
> Please use text logs instead of pictures next time, it's easier to read.
> The errors you see are related to missing MAC addresses for the unused
> interfaces, you can ignore these are they are not relevant for the issue
> you encounter. Normally the unused interfaces should have status disabled
> in the device tree but there is not a big deal if they fail like that.
> As I've advised Jamie on the other thread, please try to connect the device
> back 2 back to a known good machine and determine what is broken - Rx/Tx?
> Is there another software version that does work on these machines?

Hi, just saw this and thought of a small patch I just wrote for mdio bus, o idea
if it is relevant but here goes:

From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund 
Date: Sun, 14 Jan 2018 21:27:20 +0100
Subject: [PATCH] of_mdiobus_register: Continue after error

of_mdiobus_register unregister itself if one phy fails to register
which is bad for system having all its PHYs on the same MDIO bus.
Just log the error and continue with the remaining PHYs instead.

Signed-off-by: Joakim Tjernlund 
---
 drivers/of/of_mdio.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 98258583abb0..76ff28a41dad 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -229,7 +229,8 @@ int of_mdiobus_register(struct mii_bus *mdio, struct 
device_node *np)
else
rc = of_mdiobus_register_device(mdio, child, addr);
if (rc)
-   goto unregister;
+   pr_warn(FW_WARN
+   "%pOF: Failed to register MDIO device.\n", 
child);
}
 
if (!scanphys)
@@ -253,7 +254,8 @@ int of_mdiobus_register(struct mii_bus *mdio, struct 
device_node *np)
if (of_mdiobus_child_is_phy(child)) {
rc = of_mdiobus_register_phy(mdio, child, addr);
if (rc)
-   goto unregister;
+   pr_warn(FW_WARN
+   "%pOF: Failed to register MDIO 
PHY.\n", child);
}
}
}
-- 
2.13.6

RE: DPAA Ethernet traffice troubles with Linux kernel

2018-01-15 Thread Madalin-cristian Bucur

> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+madalin.bucur=nxp@lists.ozlabs.org] On Behalf Of mad skateman
> Sent: Wednesday, January 10, 2018 10:39 PM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: DPAA Ethernet traffice troubles with Linux kernel
> 
> Hi linux devs,
> 
> Like mentioned in this thread
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-January/167630.html
> i also experience the exact same issues.
> I am also trying to find out why the network traffic is not flowing
> the way it should (out for example ).
> 
> My linux knowledge is very basic but i hope i can contribute anyway.
> 
> I am using the AmigaOne X5000 with a P5020
> Most detailed technical information regarding this issue can be found
> in the Thread by Jamie Krueger mentioned above.
> 
> In this screenshot, the ETH0 and ETH1 seem up and running (probed) ..
> even due to the FSL_DPAA_MAC error messages that DMESG shows.
> http://www.skateman.nl/wp-content/uploads/2018/01/Screenshot-at-2018-01-08-21_22_06_ETH_NIC_ERROR.png
> 
> http://www.skateman.nl/wp-content/uploads/2018/01/Screenshot-at-2018-01-08-22_16_28.png
> 
> I was able to use some tooling like ETHTOOL to adjust some settings
> and check if the interface responded. This all seems fine.
> 
> Hope that someone can find a fix, so the Ethernet adapter can be used.
> 
> Thanks!!

Hi,

Please use text logs instead of pictures next time, it's easier to read.
The errors you see are related to missing MAC addresses for the unused
interfaces, you can ignore these are they are not relevant for the issue
you encounter. Normally the unused interfaces should have status disabled
in the device tree but there is not a big deal if they fail like that.
As I've advised Jamie on the other thread, please try to connect the device
back 2 back to a known good machine and determine what is broken - Rx/Tx?
Is there another software version that does work on these machines?

Madalin

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

RE: DPAA Ethernet traffice troubles with Linux kernel

RE: DPAA Ethernet traffice troubles with Linux kernel

RE: DPAA Ethernet traffice troubles with Linux kernel

RE: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

RE: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

Re: DPAA Ethernet traffice troubles with Linux kernel

RE: DPAA Ethernet traffice troubles with Linux kernel

33 matches

Site Navigation

Mail list logo

Footer information