DPAA Ethernet traffice troubles with Linux kernel

[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&fp=1&p=2

On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <
Joakim.Tjernlund at 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.
> >
> >
> > > 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 <joakim.tjernlund at infinera.com>
> > > 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 <joakim.tjernlund at infinera.com>
> >
> > 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 <madalin.bucur at nxp.com>
> > 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 <madalin.bucur at nxp.com>
> >     Reviewed-by: Andrew Lunn <andrew at lunn.ch>
> >     Signed-off-by: David S. Miller <davem at davemloft.net>
> >
> >
> >     Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20180116/b63a8994/attachment-0001.html>