<div dir="ltr"><span style="font-size:12.8px">Hi,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I have been looking deeper into my wireshark packet captures and found something that could be helpfull.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I can see using wireshark that the Ethernet NIC at least does something. ARP BROADCAST traffic is seen.</div><div style="font-size:12.8px">But i also found some packets...which have LG BITs set to 1 .. when i think 0 should be the correct value..</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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..</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">These types of Logs also apear in my Wireshark Capture files... ( these are not my org. logs) </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div style="font-size:12.8px">Ethernet II, Src: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8), Dst: Broadcast (ff:ff:ff:ff:ff:ff)</div><div style="font-size:12.8px">Destination: Broadcast (ff:ff:ff:ff:ff:ff)</div><div style="font-size:12.8px">Address: Broadcast (ff:ff:ff:ff:ff:ff)</div><div style="font-size:12.8px">.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)</div><div style="font-size:12.8px">.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)</div><div style="font-size:12.8px">Source: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)</div><div style="font-size:12.8px">Address: Microchi_8f:c6:a8 (d8:80:39:8f:c6:a8)</div><div style="font-size:12.8px">.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)</div><div style="font-size:12.8px">.... ...0 .... .... .... .... = IG bit: Individual address (unicast)</div><div style="font-size:12.8px">Type: IP (0x0800)</div><div style="font-size:12.8px">Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)</div></div><div><br></div><div>In the link below some similair Logs and problems regarding DHCP for example.</div><div><br></div><div>Dave</div><div><br></div><div><a href="https://www.microchip.com/forums/m/tm.aspx?m=956881&fp=1&p=2" target="_blank">https://www.microchip.com/<wbr>forums/m/tm.aspx?m=956881&fp=<wbr>1&p=2</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 6:57 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>
> > Hi, just saw this and thought of a small patch I just wrote for mdio bus, o idea<br>
> > if it is relevant but here goes:<br>
> ><br>
> > From fe0b98d54a79779482700676331b4d<wbr>10a0f3cada Mon Sep 17 00:00:00 2001<br>
> > From: Joakim Tjernlund <<a href="mailto:joakim.tjernlund@infinera.com">joakim.tjernlund@infinera.com</a><wbr>><br>
> > Date: Sun, 14 Jan 2018 21:27:20 +0100<br>
> > Subject: [PATCH] of_mdiobus_register: Continue after error<br>
> ><br>
> > of_mdiobus_register unregister itself if one phy fails to register<br>
> > which is bad for system having all its PHYs on the same MDIO bus.<br>
> > Just log the error and continue with the remaining PHYs instead.<br>
> ><br>
> > Signed-off-by: Joakim Tjernlund <<a href="mailto:joakim.tjernlund@infinera.com">joakim.tjernlund@infinera.com</a><wbr>><br>
><br>
> Hi Joakim<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. Seems like this<br>
patch hasn't been sent to 4.14.x.<br>
<br>
I wonder if I might be missing something else, we just moved to 4.14 and notic that all<br>
our fixed PHYs are non functioning:<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>
fsl_mac: probe of dpaa-ethernet.2 failed with error -16<br>
fsl_mac ffe4e8000.ethernet: FMan MEMAC<br>
fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23<br>
fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed<br>
fsl_mac: probe of dpaa-ethernet.3 failed with error -16<br>
<br>
Feels like FMAN still think there are real PHYs there ?<br>
><br>
> commit 95f566de0269a0c59fd6a737a14773<wbr>1302136429<br>
> Author: Madalin Bucur <<a href="mailto:madalin.bucur@nxp.com">madalin.bucur@nxp.com</a>><br>
> Date: Tue Jan 9 14:43:34 2018 +0200<br>
><br>
> of_mdio: avoid MDIO bus removal when a PHY is missing<br>
><br>
> If one of the child devices is missing the of_mdiobus_register_phy()<br>
> call will return -ENODEV. When a missing device is encountered the<br>
> registration of the remaining PHYs is stopped and the MDIO bus will<br>
> fail to register. Propagate all errors except ENODEV to avoid it.<br>
><br>
> Signed-off-by: Madalin Bucur <<a href="mailto:madalin.bucur@nxp.com">madalin.bucur@nxp.com</a>><br>
> Reviewed-by: Andrew Lunn <<a href="mailto:andrew@lunn.ch">andrew@lunn.ch</a>><br>
> Signed-off-by: David S. Miller <<a href="mailto:davem@davemloft.net">davem@davemloft.net</a>><br>
><br>
><br>
> Andrew<br>
</blockquote></div><br></div></div>